May 26

Is software a zero-sum game?

Glen Alleman says yes, I say absolutely, positively not.

First, his key points:

  • Everything interacts with everything else – a project is a “system.” All the elements of the project – cost, schedule, scope, risk, resources, etc. – all interact with each other in know and possibly unknown ways. Most of these interactions are non-linear as well.
  • Everything goes somewhere – projects are closed systems – all the elements of the project have to go somewhere. There are no left over parts in terms of cost, schedule, performance, risk, resources, etc.
  • There is no such thing as a free lunch – the net effort to deliver the project is the same no matter what the methodology used. The seemingly extra effort of higher ceremony project methods must be paid by someone when using agile methods.

Everything interacts with everything else.

I totally agree with this.  Complexity is a fundamental aspect of software development.  There is no silver bullet.

Everything goes somewhere.

Totally disagree, and I’ll explain why in a moment.

There is no such thing as a free lunch.

Totally agree, but no one has ever said that agile represents a free lunch.  It represents a discounted lunch.

My Take

Glen, IMO, has a couple of very serious “big project” filters that are misleading him:

  • Not every project is delivered
    • I have personally been a part of many projects that were never actually finished.  In “high ceremony” projects, a massive amount of documentation was produced, then a small amount of code, then the project was cancelled.  In agile projects, a small amount of doc was produced, a small amount of code, and then the project was cancelled.  Clearly, agile represents a significant savings over high ceremony in this case.
  • Not every project, once delivered is maintained
    • I have also gone through the effort of producing systems that, for a variety of reasons were never used.  All of that time spent on producing extensive system documentation was wasted.
  • Not every project, once delivered, requires significant maintenance
    • If you deliver a project, and it is well-used, but for a variety of reasons requires very little ongoing maintenance, the value of a comprehensive technical documentation suite is very suspect.

But even more fundamentally, I disagree with Glen’s assertion in the general case.  Even if a project is delivered, and used, and requires significant maintenance, doesn’t mean that the costs are the same.  For example:

  • It can be (and IMO usually is) much easier to write comprehensive documentation for a working system than a theoretically working one.
    • It is also easier to train developers/maintainers on a working system than a theoretical one
    • It is also easier to gauge the impact of infrastructure changes on working software than theoretical software
  • Many (most?) risks are more easily mitigated when they are found earlier than when they are found later.  High Ceremony projects often fail to detect risks as early as agile projects.


Glen is absolutely right to point out that agile methodologies “move the problem around” instead of “getting rid of the problem.”  There are always drawbacks to every approach.  But I think the key here is to realize that costs change over time.  Some things are expensive at the beginning, and cheaper later on. Others are cheap at the beginning, and more expensive over time.   If you can do the cheaper-at-the-beginning things earlier, and the cheaper-later-on things afterwards, you, and your project win.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>