Over a million developers have joined DZone.

Where is the Constraint in Software Development?

I just had a thought about the relationship between software development and the Theory of Constraints. How can we exploit bottlenecks?

· Agile Zone

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

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 EXPLOIT it by creating feedback loops based on small increments; 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?

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.

Topics:
agile ,feedback ,code design ,analysis

Published at DZone with permission of Kevin Rutherford, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}