Software Externalities

0 comments suggest edit

If you’re a manufacturing plant, one way to maximize profit is to keep costs as low as possible. One way to do that is to cut corners. Go ahead and dump that toxic waste into the river and pollute the heck out of the air with your smoke stacks. These options are much cheaper than installing smoke scrubbers or trucking waste to proper disposal sites.


Of course, economists have long known that this does not paint the entire picture. Taking these shortcuts incur other costs, it’s just that these costs are not borne by the manufacturing plant. The term externalities describes such spillover costs.

In economics an externality or spillover of an economic transaction is an impact on a party that is not directly involved in the transaction. In such a case, prices do not reflect the full costs or benefits in production or consumption of a product or service.

Thus the full cost of manufacturing includes the hospital bills of those who get sick by drinking the tainted water, the cost of the crops damaged by the acid rain, etc.

Software is the same way. I got to thinking about this after reading Ted’s latest post that Agile is treating the symptoms not the disease where the complexity that Agile introduces is disparaged and Access is held up as one example of a great “simple” way to develop applications.

I agree that Access is great when you’re building a little database to track Billy’s baseball cards. However, the real world doesn’t stay that simple. As the second law of thermodynamics states (paraphrasing here), entropy tends to increase over time, which is something that Ted doesn’t address in his discussion.

I’m all for simplicity in our tools and methodologies as I think we still have a lot of room for improvement in reducing accidental complexity. Unfortunately, the business processes for which we build software are not simple at all and full of inherent complexity. Oh sure, they may start off as a simple Access database, but they never stay that simple. Every business I’ve ever interacted had very complex sets of business processes, some seemingly cargo cultish in origin, which led to major complexity in business processes.

Ted mentions friends of his who’ve made a healthy living using simple tools to build simple line-of-business apps for customers. And I’m sure they did a fine job of it. But I also made a healthy living in the past coming in to clean up the externalities left by such applications.

I remember one rescue operation for a company drowning in the complexity of a “simple” Access application they used to run their business. It was simple until they started adding new business processes they needed to track. It was simple until they started emailing copies aroundand were unsure which was the “master copy”. Not to mention all the data integrity issues and difficulty in changing the monolithic procedural application code.

I also remember helping a teachers union who started off with a simple attendance tracker style app (to use an example Ted mentions) and just scaled it up to an atrociously complex Access database with stranded data and manual processes where they printed excel spreadsheets to paper, then manually entered it into another application. I have to wonder, why is that little school district in western Pennsylvania engaging in custom software development in the first place? I don’t engage in developing custom school curricula. An even simpler option is to buy some off the shelf software or simply use a Wiki, but I digress. 

These were apps that would make The Daily WTF look like paragons of good software development in comparison.

The core problem here is that while it’s fine to push for simpler tools to reduce accidental complexity, at one point or another we are going to have to deal with inherent complexity caused by entropy. Business processes are inherently complex, usually more than they need to be, and this is not a problem that will be solved by any software. Most are not only inherently complex, but chock-full of accidental complexity as well. Your line of business app won’t solve that. It takes systemic change in the organization to make that happen.

Not only that, but business processes get more complex over time as entropy sets in. The applications I mentioned dealt with this entropy and reached a point where the current solution could not scale to meet that new level of complexity (a different sort of scaling up), so they started to drown in it, the original authors of the applications long gone off to create new apps with new externalities.

Fortunately, the externalities of these applications didn’t cause cancer, but rather kept guys like me employed. Of course, it was a negative externality for the company who kept pumping cash to fix these applications.

Ted paraphrases Billy suggesting that Agile requires even more complex tools, story cards, continuous integration servers, etc. This is an unfair characterization and misses the point of Agile. Agile is less about managing the complexity of an application itself and more about managing the complexity of building an application.

A higher principle of agile is YAGNI (You ain’t gonna need it) until you need it. For example, the 1 to 2 guys in a garage probably don’t need a continuous integration server, stand up meetings, etc and any real agilist worth his or her salt would recognize that and not try to force unnecessary procedures on a team that didn’t need it.

However, as the two garage dwellers start to grow the business and need to coordinate with more developers, such tools come in handy. As you grow a team beyond two people, the lines of communication start to grow exponentially, thus creating inherent complexity.  Looking at the cost of developing and maintaining an application over time is where you start to get a full picture of the true cost of building an application.

As Robert Glass pointed out in Facts and Fallacies of Software Engineering, research shows that maintenance typically consumes from 40 to 80 percent of software costs, typically making it the dominant life cycle phase of a software project. Thus these so called “simple” solutions need to factor that in, or the customers will continually be left with the clean-up duty while the polluters have long since moved on.

Found a typo or error? Suggest an edit! If accepted, your contribution is listed automatically here.



24 responses

  1. Avatar for Aaron G
    Aaron G October 13th, 2009

    I agree with you Phil. I have been presented without countless projects where I was told to get it out as quickly as possible and not worry about "tomorrow" because it is an app that will only be used for a short time. Those apps are still running today.
    I think that project managers are under such pressure to deliver more for less. It is easy for them to cut out things that add hours even though those same "things" will save the company down the line.

  2. Avatar for Daniel
    Daniel October 13th, 2009

    Nice response. After reading his post, I'm not clear why he picks on Agile. In my understanding of Agile - especially Lean - it's part of the process to weed out those things that cause waste - be they meetings, CI, or (heaven forbid) unit tests. I think people that argue against these things tend to exagerate how difficult they are. A single developer can very easily and cheaply set up shop with a very rich agile process. I would agree with the general concept that there needs to be a modern solution for people to solve business problems very easily with little or no programming. I do think software will eventually address the issues, but I disagree that Access is it. SalesForce and similar come close, but are still too complex to really meet the need. Enterprise suites like K2 also come close, but are too costly. Pretty much anybody who says "no programming required" today really means "learn to program our way".

  3. Avatar for Eric Duncan
    Eric Duncan October 13th, 2009

    Exactly Phil. This is why me and my team have learned the ways of IoC w/D.I. even to the point of writing stub interfaces to 'reserve that possibility in the future'. Something that agile gurus would cringe at.
    Taking the existing client I am working with, about 20% of the specs are left "undefined", dependant on whichever 3rd party he gets to sign a partner deal with. So far, I have about 9 stub interfaces for things like IAlertService with a single method. It does not do anything yet, but BDD is being used (MSpec actually), software is getting written against the tests, and we have the stub for when the client signs the deal with the 3rd party.

  4. Avatar for Jeremy B.
    Jeremy B. October 13th, 2009

    I had an Information Systems professor at LSU, Andy Schwarz, that beat into my head the most important phrase I've learned for development. He said, "There is no such thing as a technology problem, only business problems involving technology."
    He taught me to always look at development from a business standpoint first, then from a technical one.

  5. Avatar for Freddy Rios
    Freddy Rios October 13th, 2009

    "and not worry about "tomorrow" because it is an app that will only be used for a short time"
    You usually can tell which those are i.e. if that app "will be replaced" i.e. if its to be replaced by something else "later"
    That said, I can only recall 1 that was a 1 time app for real - was there to help with a very specific change the company was doing and the application helped managers with that. Everyone happy and the app did it job well and there was nothing left to maintain once the change period of the company was over :).

  6. Avatar for Michael Washington
    Michael Washington October 13th, 2009

    Ok I'm gonna bite. I agree with his core question and that is where is the simplicity? For example, Linq to SQL works. You open it, drop your database tables on it, save and then write some queries. I can show it to a developer and he is able to rock and roll in 15 minutes.
    We need more stuff like that :)
    But then there is stuff that I could spend an entire day and I could not explain it to an advanced developer.

  7. Avatar for Stephane
    Stephane October 13th, 2009

    I so agree with this blog post. I see that lately your blog is getting more "political".
    Anyways, I remember few years ago when doing an internship at some big company in France. They asked me to update a VBA "tool" that grew and grew into an unmaintainable application with 10 spreadsheets. They suddenly wanted this tool to be used in different call centers (it was a support calls routing helper) and even accross different continents. They never thought that having different Excel versions or just language packs would make the application obsolete.
    As you say "Fortunately, the externalities of these applications didn’t cause cancer". but they do cause headaches and a lot of WTF.
    They also discredit our profession sometimes.

  8. Avatar for CBP
    CBP October 13th, 2009

    I believe a lot of the perceived complexity of agile and agile tools is due to their immaturity and the complexity and inconsistency of the language surrounding its various components.
    This will get better over time. The tools, books, computer science courses etc. will all improve and become simpler to grasp. Compare the simplicity of the latest versions of LINQ, Moq, JUnit etc. versus their predecessors. Now imagine where they will be in another 3-4 years time.
    A lot of people want to rush in, but forget that many agile tools and processes have only been standard practice for a few years.

  9. Avatar for Haacked
    Haacked October 13th, 2009

    BTW, Ted has posted a rebuttal to my post and I posted a rebuttal rebuttal :). I definitely agree I may be missing his point. Perhaps I don't agree with his premise. We should define, what exactly is the real disease.
    This is definitely an interesting discussion and I love that we can have it in a respectful non-hostile manner. Perhaps our arguments come from different experiences.
    @Stephane I don't see this post as being "political" as much as "experiental". I'm writing this from my own experience. I think it's quite a common experience. :)

  10. Avatar for jdn
    jdn October 13th, 2009

    I'm glad to see you admit you might have missed the point. For instance, I fail to see how you got to this:
    "I got to thinking about this after reading Ted’s latest post that Agile is treating the symptoms not the disease where the complexity that Agile introduces is disparaged"
    At no point does he say that Agile introduces the complexity that I can see. Instead, he says explicitly:
    "The problem is the complexity of the tools we have available to us today preclude that kind of software development."

  11. Avatar for lynn
    lynn October 13th, 2009

    I think that 'agile' is kind of a lost tangent on this point. The main thrust of what you guys seem to be about managing complexity in software systems. I get the Access argument – it was a single stop development/deployment tool. And while IDE’s do a much better job these days, I think the ‘single stop’ metaphor is mostly done. However, Azure is impressive and would do a lot for this, but I’m not sure how long until you guys realize that’s what’s next for Windows in general and ship it to the masses. Suggestion – don’t wait too long.

  12. Avatar for Jack
    Jack October 13th, 2009

    Quite agree, "Agile is less about managing the complexity of an application itself and more about managing the complexity of building an application."

  13. Avatar for John
    John October 13th, 2009

    I have to be honest, I read Ted's blog, then yours, then had to flip back to Ted's, because it seemed like you were responding to a different blog than the one that Ted wrote.
    I took Ted's point to mean that the problems of complexity are larger than the sphere that Agile solves. Agile solves some project management problems that waterfall had, but Agile is not the be all, end all of all good programming practices. In fact, one of the interesting things that I read by Grady Booch was that one downside of the Agile community is the lack of historical perspective -- many Agile programmers seem to believe that there weren't any good programming practices before Agile, which was most decidedly not the case.
    I actually think that the answer to Ted's complexity problem has nothing to do with Agile. Sharepoint and other CMS tools (Joomla, Sitefinity, etc.) are useful tools for creating quick, decent sites. Best of all (for the company), they can be maintained by people making 1/2 what programmers make.
    On the other hand, things will get even more complex for the professionsal software engineer, but so what. To be an engineer in most states, you have to become certified. Actuaries are required to pass a number of tests to continue to advance in their profession and their companies typically set aside time for recent college grads to study for the exams. Why should the profession of building software be any different than other mature professions?

  14. Avatar for anirudha gupta
    anirudha gupta October 13th, 2009

    Hello Haccked Brother
    send me a answer
    how can i became a successful web Developer in Asp.Net MVC
    give me suggestion

  15. Avatar for nappisite
    nappisite October 13th, 2009

    I think you missed the point of Ted's article he wasn't suggesting that Agile added complexity, but rather masked it rather than treated the underlying problem.

  16. Avatar for Craig
    Craig October 13th, 2009

    An app will NEVER be better than the business process it assists. And companies are starting to realize that through 6-sigma, lean & DFSS, but it's slow going. I worked for a F500 company with 70000 employees, and they were starting to train 3000 people per year in this stuff. That's 23 years to train everyone. But turnover rate is a significant problem, especially when 40000 of those employees were call-center employees who turned over almost 100% in a year.
    But now, as a consultant/contractor, I always insist that a business process analysis be completed before I begin app design. (And often this naturally leads to a DMAIC/DMADV process, which cleans up a lot of the mess.) My customers have been hugely pleased. The apps have been easier to use yet far more functional, and they meet the needs a lot better. I'm telling you, if you haven't employed Lean/DFSS, you need to. It makes all the difference in your reputation and in customer satisfaction, both internally and externally.
    Nice post, Phil. I'm with you.

  17. Avatar for Haacked
    Haacked October 14th, 2009

    @John, @lynn I think part of the problem in this discussion is I agree with lynn that Agile is tangential to the point. If that's the case, why was it brought in the first place. It feels like a strawman to me. "Let me point out another thing Agile doesn't address, which it doesn't even try to address nor should it.".
    If agile is tangential to the point, then why even mention it in the first place?

  18. Avatar for Tim Shakarian
    Tim Shakarian October 14th, 2009
    Agile is less about managing the complexity of an application itself and more about managing the complexity of building an application.

    +1. Agile software development principles are orthogonal to the many diseases that plague business processes.

  19. Avatar for lynn
    lynn October 14th, 2009

    The tough things about blog entries that rarely is there a thesis upfront and/or a strict series arguments. Blog entries tend to be more of a narrative and higly introspecitive, with points enmeshed along the way. Therefore it can often be tough to elucidate the author's singluar thrust, if there is one.
    I had to read his blog entry 3-4 times before before I could really get at the heart of what he was talking about. His thesis is in the third from the last sentence - that agile cannot manage software system complexity, only the design process. So agile serves as a current frame of reference, and not much more, in his narative.
    You both make a lot of really good points of equal consideration.

  20. Avatar for tvanfosson
    tvanfosson October 15th, 2009

    I think part of the problem is that Ted may be conflating Agile with particular Agile methodologies. It may be entirely correct to say that XP, for instance, insists that I do TDD, pair-programming, etc. and thus it is too prescriptive for my small, 1-2 developer problem. But that's a complaint about XP, not Agile.
    The best description of Agile, in the large, that I ever heard was from Brian Marick at Agile 2005: Just Enough, Just in Time, and Just Because -- though, strictly speaking only the first two describe Agile itself while the latter describes the reality of using Agile in a non-Agile world. Just Enough applies to process, tools, and features. We want just barely enough process appropriate to the job at hand and no more. We want to use just enough tools and techniques. We want to develop just enough features. Is XP too much? -- don't do it, do something simpler.
    The thing is, though, that there are techniques or tools that have proven to be so valuable that there is almost no situation in which you could responsibly omit them from your tool belt. You would have too little instead of just barely enough. Things like source code control, testing, some sort of process introspection (Am I still doing just enough? Should I add more? Should I remove?), ... It's hard for a non-practioner or amateur to see the value in the core pratices, but they have proven themselves over time.
    It's a bit like teaching your kid how to drive. You say, "Make sure to look behind you before you start to back out of the drive." Now, 95% of the time it probably doesn't make a difference whether you do or you don't -- at least on my quiet street. The problem is that you must always do it because the consequences of the 5% could be catastrophic. This is a tool you can't live without in your driving "tool belt" even if you have never run over the neighbor's dog (or child) because you forgot to look.
    Note, though, that it isn't Agile per se that prescribes these practices. These core practices are ones that you would want to follow regardless of your process -- except maybe introspection if you're following a highly regimented process that doesn't allow for process change. Agile merely gives you permission to not to include any practice that doesn't add value (for example, no daily stand up for solo developers) or encourages you to add practices when they do (using small, frequent releases to get immediate customer feedback).

  21. Avatar for Matteo
    Matteo October 26th, 2009

    This post hits me at the heart. You talk about problems I live with everyday at work. Working in a small SH (boss + 2 employees) and having to face the "we don't have time, code fast, we won't reuse that" etc.
    I hate that kind of approach. Why waste 1 hour today, when we can SPEND 2 or 3 hours to make something good, reusable, with a solid architecture, and (almost) future proof?
    Someday my boss will tell me. In the mean time, I'll keep on fighting against the spaghetti code produced by my co-worker...

  22. Avatar for Calvin
    Calvin November 8th, 2009

    >> Not only that, but business processes get more complex over time as entropy sets in. The applications I mentioned dealt with this entropy and reached a point where the current solution could not scale to meet that new level of complexity (a different sort of scaling up), so they started to drown in it, the original authors of the applications long gone off to create new apps with new externalities.
    You make it sound like it's the fault of the original programmers. IMO, they gave the customer what was required - no more, no less. After all, if the customer asked for an application to be used by 15 people at irregular intervals of time spread out over the week, then that is what I would give them. If I offered more (with a correspondingly higher price tag), they would only reject my proposal and take their business elsewhere. It certainly doesn't make business sense to me to absorb the cost of my customer's externalities.
    As for those who say code for the future and that the bulk of an IT project's lifespan is spent in the maintenance phase. I'll agree up to this point, but from my experience, many applications, or at least many features of an application are never used after deployment. That means it is futile to make an overly complicated design up front. Not to say you should write spaghetti code, but best to keep it simple. You can always refactor the 10% of the application that is actually used later on, if necessary.

  23. Avatar for Julius
    Julius November 9th, 2009

    I still do not understand everything but it sounds like something in which case I could probably deal

  24. Avatar for Aaron
    Aaron January 14th, 2010

    I'm not really sure why there is a feeling that Agile looks down on amateur developers as Ted states. Agile is not trying to turn all amateurs into professionals. The real issue is that there are too many amateurs acting as professionals. I like embedded development. I do it at home as a hobby. I am an amateur embedded developer. I wouldn't attempt to sell my services to an organization, or pretend that I know what it would take to build even a simple hardware device that would, for instance, control the flow of fuel to an engine for a consumer vehicle, but I have seen and will continue to see developers posing as professionals that have amateur skill sets. They slam something together without the slightest thought given to maintainability, correctness (that it actually works), or readability. It's not Agile that is creating this tension, it is those that joined an industry that changes rapidly, and yet have no desire to continuously learn and improve their skill set. We were all amateurs once, but some of us have sacrificed and continually climb up the learning curve for our careers. So, I don't blame Agile for not making things so simple an amateur can jump right in, the same way I don't expect becoming a surgeon to require reading a 100 page book and a few rounds with the Operation game, before I can start cutting someone open.