Where is the constraint in software development?

I just had a thought about the relationship between software development and the Theory of Constraints. It probably isn’t a new thought, although it seems to differ from some of the analyses I’ve seen elsewhere. Also, I probably won’t be able to express it in any coherent way; but here goes…

I’ve read articles suggesting that the constraint in software development is the writing of the code; indeed I’ve written some of them myself. If it were true, then our first concern should be to EXPLOIT the bottleneck, by making sure we only write code for things that matter. This includes not working on buggy starting code, but it also includes only spending our precious time on developing those features that the customer actually needs.

So how can we ensure that we only work on features that represent real value?  One way would be to analyse the requirements deeply and thoroughly before we begin coding. But if that worked, there would never have been any need to seek an alternative to the waterfall approach. Up-front analysis doesn’t work (most of the time); I suggest that this implies that the writing of code cannot be the constraint.

XP says we should value feedback. One reason is that without it we would work on the wrong stuff. We write code partly in order to deliver value, and also partly in order to find out what the customer really wants. We run a small batch through the whole system in order to find out whether we guessed the requirements correctly, and to discover what to do next.


The constraint is our limited understanding of what is valuable. We can EXPLOIT it by creating feedback loops based on small increments. Because smaller increments create more opportunities to understand where the value lies, which in turn limits wasted programming effort. Then we SUBORDINATE to it by not planning or designing too much in advance; that would build up WIP — not of plans or design per se, but of guesses.

I feel I ought to be able to express the above analysis using TOC thinking tools. Can anyone help out with that?

5 thoughts on “Where is the constraint in software development?

  1. Is it possible that as we iterate, the constraint shifts from needing to know what you want next (value) and the ability to realise it (write the code)?

  2. I can’t help with the ToC thinking tools but I find this very interesting. I thought I had a different perspective regarding the purpose of the code but I’m now thinking that I was possibly considering it too mechanically and I’m ending up in the same place you seem to be.
    I think that this revolves around what The Goal is perceived to be. Many organisations would see the goal as being the delivery of business value embodied in the software, and hence by the delivery of the software itself which, as you indicate, leads the organisations to focus on how to optimise the delivery pipeline. However, this is on the assumption that what is being built does actually deliver business value to customers which is often completely unproven. Many organisations don’t seem to be able to measure whether the delivered business value inherent in the software is actually considered to be valuable to customers. It is often fire-and-forget and in many cases does not seem to deliver the anticipated business value. In lean terms, most of what is being delivered ought to be considered as waste since it is either not used or, if it is used, it delivers a poor level of experience and hence low value to the customer.
    If the goal is the delivery of true business value to the customer then software may not even be needed for some of it, so software creation cannot be the bottleneck in those cases. As you say, the bottleneck seems to be determining what may be of value, defining an experiment to prove this value to the customer and determining how the success of the experiment will be measured. I think the key is how you can get everyone in the delivery process (both the more business focused people and the technical people) to think in this way and work on improving that broader delivery cycle.
    Will be interested in how this discussion goes.

  3. I think that a Software Application delivering business value to the user orgainisation, though correct, is still worded a little complex. Because then we have to first define what is ‘value’ . Rather as Goldratt says, that purpose of any IT application ought to be to help the user organisation do something that was previously not possible or make it easier or more efficient to do than before. Simplicity is key in Theory of Constraints!

  4. I think you nail it in this post. First the requirement analysis phase is very important and very few companies or projects value this stage because of the priority in trying to deliver on schedule. A thorough analysis on requirements, working closely with the customer is critical in the success of the project.

    Continuous feedback or continuous improvement is another very important phase. Continuous feedback part is left out by many in software engineering due to cost and time.

    By fully understand the purpose of agile methodology, we can find ways to remove these two constraints.

Leave a Reply

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

WordPress.com Logo

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

Google photo

You are commenting using your Google 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 )

Connecting to %s