Soon, good or cheap. Pick two.

I get this question periodically: “Why does it take so long for you to make bug-free software?” I reach for a marker and a whiteboard and start explaining this diagram:
Law of scope for programming

With software development, there are four things that can affect a timeline

  1. Features – The richness or complexity of the features of the program. Lots of features=lots of work. This means lots of time, money and probably bugs.
  2. Bugs – How many bugs can you stand? Or rather, how “bug-free” or perfect do you want the finished software to be?
  3. Time – How quickly do you want the software completed?
  4. Cost – How much you are willing to spend on the software? In other words, how many programmers and how skilled will they need to be?

Increasing or reducing any of these will have a big impact on the other three. Specifically, reducing any of the edges (Bugs, Cost, Time) means that the triangle gets smaller, meaning: less room for features. Get rid of some. However, if you can’t live without any of the features, then you need to increase one or two of the other edges.

For instance:

  • You can have the program really soon, if you add people (or get some ninjas) or allow bugs or cut enough features.
  • You can get a lot done with the same team if you allow bugs or lots of time
  • If you want a program that is bug-free, you need to allow lots of time, or add experienced (well-paid) testers
  • You can get all of these (bug free program, in no-time) if the program has almost no features (like notepad.exe or HelloWorld.exe).

Less time, same features, expands something else

This is pretty-much a law of physics for programming. Every dev team that I have ever met, has seen this formula in action. Every time that I have seen a customer, who would not budge on the cost and timeline while demanding more features from a dev team, saw the same outcome: The program was delivered late, with lots of bugs.


Probably the most common occurrence of this law, is with quality. I cannot count the number of times where I have seen a customer with an expectation that a team (any team), can deliver bug-free software and still meet an aggressive timeline, without being allowed to cut features.

Exercise: Complete the following formula:
less time + less bugs + unchanged features = more ___

The only way that this could be possible would be to add more people (expensive ones). Still, there are laws of momentum, that come into play. There is a limit to how much money you can throw at a late project, and still affect the outcome. (Law of programming #10: adding resources to a late project, makes the problem worse).

Realistically, when a project is running out of time and it is still buggy, the only possible outcomes (realistically) are:

  1. There will be more bugs
  2. It will take more time

If the software must be bug-free, then it will be done when it is bug-free (however long that takes).

If the software must be delivered by a specific date, then no one can be certain how clean the program will be by then.

Bending the Law

Perhaps you think you are clever and you have beaten this formula before. Rest assured, you only made someone else pay for it. If you insist on being firm with any of these, there will be trade-offs or outright concessions from somebody. A shrewd business person, might be able to get somebody else to eat the cost, and add time without extending the timeline, but there is only so much that can be swallowed or buffered. If you squeeze this model, something is going to shift. I’m telling you: it is a law.

Anyone who can seemingly defy this law of programming is really only pulling a trick, where the cost is absorbed or deferred. The following are examples of absorbing or deferring the outcome of this law:

  • Work more hours without being paid – The programmers absorb the cost. Therefore the cost is hidden.
  • Deliver buggy code – Less time spent on testing, defers the cost to the end-user, who will find the bugs eventually. The programming will be finished once the end users report all of the flaws and they are fixed.
  • Corner cutting – This allows the code to be precariously completed, while accumulating technical debt. Each developer that encounters such code, will pay tax on this technical debt, as it reduces the efficiency of each developer that comes in-contact with it. This can only be mitigated by resolving the technical debt. Usually, this comes at a five-fold cost, over creating the technical debt, in the first place.

Real Efficiency

There are a few RARE exceptions, where the productivity of a team is honestly and actually improved, to increase the efficiency and throughput. I must declare that these conditions are quite rare and take a significant effort to produce environments that allow these phenomena. They will not happen naturally. They must be planned and designed by someone who understands the calculus of how they work. They must be implemented to fit the conditions of a team and the environment. They will not work everywhere:

  • Effective use of methodology to increase efficiency – Increased efficiency will eventually require equivalent compensation. However, there is a period where the cost will lag behind the efficiency. Usually, this is preceded by an investment in the process. Overall, it usually equates to a break-even.
  • Effective use of testing process to quickly or accurately identify flaws in software – This sounds like such a simple thing, but it requires a rare mind-set, skill-set and processes (i.e. A “skilled tester”). Finding, training or arranging it can be quite challenging.
  • Working with staff to optimize their skill sets – It is possible to train staff to do things beyond their natural abilities. When this happens, the staff will (effectively) be underpaid, and therefore, the cost is concealed. Eventually, this lagging cost will catch-up. (You either pay, or the underpaid employees will leave).

It would be great for business if this law could be circumvented, but as I have said, it can only be deferred, concealed or postponed. So, when you come in contact with someone who is asking for a miraculous value or outcome, help that person out, by drawing this diagram and take five minutes to explain this law of programming.


About Tim Golisch

I'm a geek. I do geeky things.
This entry was posted in Lessons Learned, Methodology, Testing. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s