DevOps Zone is brought to you in partnership with:

I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 638 posts at DZone. You can read more from them at their website. View Full User Profile

The Goal of software development

10.04.2011
| 9644 views |
  • submit to reddit

The Goal by Eli Goldratt is a business book in the form of a novel, where the protagonist must save his factory from closing due to very low productivity.

The Goal is not limited to the management of a large organization (not even to for-profit companies): you simply have to define different units of measurement, like goal units instead of making money, the default goal. In fact, from the applications of the Theory of Constraints in our field I think it applies to software development too. What follows is my translation of the themes of The Goal to our field.

The Goal is...

Mking money, of course. For the ones of you with knowledge in accounting, the original goal is:

  • raising throghput, the amounts of items sold (not produced) in the unit of time.
  • Lowering investment/inventory, all the money tied up in the system in the form of assets that could be sold or products that stay in a warehouse.
  • Lowering operational expense, all the money that we have spent as support and that cannot be recovered.

How does these measurements apply to software development? A team does not always have an impact on contract negotiation, so often talking about money is far from everyday reality (kudos to you if you can apply that point of the Agile Manifesto.)

The goal for software development can be translated, in my opinion, to:

  • raising the throughput, the amount of features delivered (deployed, not implemented or tested) in the unit of time. You can measure this amount in story points, since feature vary in size.
  • lowering investment/inventory, all the time tied up in the system in the form of undeployed or untested features that clutter the code base. In a minor part, also investment in the form of hardware, but that's by far less important than the team's time.
  • lower operational expense, the time spent by developers every day in order to support the development. Automation is a kind of time investment that will bring more time (and quality) in the future, lowering operational expense.
Like for material products, WIP has storage and opportunity costs which goes into the operational expense. Kanban is a tool that tries to reduce WIP in order to foster the two latter points.

Throughput accounting

This kind of throughput accounting is emphasized in the novel, over the use of cost accounting, where each developer (ehm, factory worker) has to be occupied all the time, even if the work he is doing isn't moving towards the goal:

  • neverending refactoring.
  • Specification of a feature which cannot be implemented until two months are gone, and will have to be rewritten.
  • Implementation of features which won't be merged with the main branch any time soon.

With Test-Driven Development, we are getting good at moving a feature from implemented to tested directly in the same commit. Yet the missing step is getting the feature to the users: maybe that's also what Continuous Deployment is all about...

Dependent events

Dependent events and statistical fluctuations are production systems topics that make a balanced plant close to bankruptcy: however, we're not at the point in which we can model our team as precisely as a factory.

The basic point is that a plant in which everyone is working all the time is inefficient: when an early stage (like defining a specification or implementing a feature) gets delayed, downstream step such as deployment are dalayed too. Converely, when an upstream step finish earlier, the downstream stage is already at maximum efficiency and cannot process the intermediate result faster.

I wonder if this applies to software development too. In a factory, workers are specialized and can do just a few jobs across the plant. Since workers and machines have different production rates, there will be just one bottleneck: the slowest one. If products have to pass from the bottleneck, anyone producing faster than the bottleneck will just accumulate WIP in front of him.

Continuing with our example, if the analyst or domain expert is churning out specifications for new features every day, most of them are just WIP in front of the development team. Once there is an established buffer, any additional specification won't raise throughput any faster; instead, it will raise the inventory (partial features) and the time spent in managing it.

I think this is not always true in the most technical phases of development instead. For example, in a small team a developer may be moved to testing or refactoring, or setting up Continuous Integration or evaluation of a new library. Unless you have a DBA which can just manage databases, your developer is not fixed into a stage of the system.

The bottleneck

The previous example featured a bottleneck, the most famous concept of the Theory of Constraints introduced in the book. This translation to the software development case is mine and could be incomplete.

A feature (or a user story) has to pass in a series of stations where different people will work on it to make it real: specification from a domain expert, implementation from a technical team, extended testing with optional customer validation, deployment which should be fast but at the same time must not kill the current version of the application.

Each station has an average velocity. By definition, there is a station which is the slowest and can process fewest story points in the unit of time. This is the bottleneck.

(This is not always true, as velocity may vary greatly in time with the addition of new people or hidden lines discovered in a feature. Becoming good at estimation and stabilizing a team are two objectives that help reach the assumption.)

You can identify a bottleneck by looking at where is the WIP: it will accumulate in front of it. If you already have a kanban board, this phase is simpler...

Once identified, the throughput of the system can only be improved by raising the bottleneck's capacity enough so that it is no more a bottleneck. You can move people to it (keeping an eye on communication costs); ensure it is used at maximum efficiency by freeing the specialized developers from other mundane tasks.

Now you can restart and find a new bottleneck...

Conclusions

This is just a little introduction to the themes of the Theory of Constraints and Goldratt's teachings; I don't pretend to explain the whole book in an article. It is also against the Socratic method: you should reach the answers yourself, and these are just examples from my experience. There is more to Goldratt and The Goal than bottlenecks and throughput, such as continuous improvement.

If you're working or managing in a software development team, I suggest you to read this book if you have the opportunity. Even when freelancing, it is an eye-opener in moving towards a Goal instead of busyworking; and it's written with a never boring teaching method.

Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Mike Mormando replied on Tue, 2011/10/04 - 12:09pm

Goldratt himself wrote a book about TOC and software development, called "Necessary but not Sufficient", acknowledging the fact that TOC by itself can't "fix" software dev.

Giorgio Sironi replied on Wed, 2011/10/05 - 2:31am

Thank you for the suggestion, I just finished Critical Chain and will go on to this book. :)

Cloves Almeida replied on Wed, 2011/10/05 - 7:42pm in response to: Mike Mormando

About "Necessary But Not Sufficient" the point is quite the opposite. Software by itself (that time represented by the low success rate of expensive ERP implementations) won't "fix" a company. Software is necessary to manage today's complexity, but it's not the saving board people used to think.

Cloves Almeida replied on Wed, 2011/10/05 - 8:22pm

My 2 cents:

a) IMO for most software projects, the "goal unit" should be perceived customer value. Implementing unneeded features just because one thinks it's "cool" doesn't cut it. At least some basic value analysis should be put in place.

b) There's also the "rope" concept - which means "don't feed the developers more that they can chew". Among the plethora of bugs, refactorings and features, the developers should be allowed to work on those that provide the most value in a given iteration AND ONLY ON THOSE. After each iteration, the WIP should be reanalyzed and another batch should be released.

c) Developers are becoming specialized - you've got UI, security, DB, build, framework experts at least. Eventually one of them will become a bottleneck and development work is full of gotchas that makes balancing the flow of work impossible. Solutions?

  1) Cross-training. Make a rule that an specialist should become at least proficient in another field.

  2) Frequent releases.  It's agile 101 - it reduces the chances someone will get stuck at a problem and noone will notice until it's too lante.

Giorgio Sironi replied on Sun, 2011/10/09 - 9:47am in response to: Cloves Almeida

I mostly agree, but the problem with a) is how to measure this value. I took for granted that a Product Owner in contact with the business would be able to prioritize the features and poll the real users to see what they consider important.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.