The rework cycle
The diagram shows a system dynamics model of software development I liberated from a class presentation at MIT. The researcher’s model was much more complex, but this is the heart of it. They dubbed this loop “the rework cycle.” In their model, it accounted to a large degree for the success or failure of a development effort.
The model says progress is determined by combining the number of people with how productive each is. The quality of the work determines how many bugs are created and there’s a defect discovery process that limits how quickly defects are found and re-enter the process as more work.
The model is idealized in one sense: Given fixed requirements, productivity and quality, the system will run with complete predictability, like a wind-up toy, until the work is done and the bugs are fixed.
You can plug in some numbers and see: Say there are 10 requirements and one programmer who implements a requirement every two days. If the programmer creates 1 bug per requirement and it takes him a 1/2 day to fix each, then the project will complete in 25 days, assuming the bugs are found without delay and I didn’t screw up the math.
But there is one thing that separates this model from typical agile or gantt-based models. It includes cycles - just like real world processes. In this model, the bug-fixes can themselves have defects, further increasing the projected end date as they’re discovered.
For more realism, you need only add customers, management, or both. With that, most of the problems of large systems engineering can be explained. In future posts, we’ll consider both the Customers-Ruin-Everything and the Corrupting-Influence-of-Management extensions.
Having a simple, yet complete model of your development process is key to making improvements. What’s yours?
