What does it mean - "Management science for software engineering"? Why do I say that on this site?

I'm not making it up. What are we saying when we say we are doing science? Science is the idea that we can predict the outcome of events given our understanding of how things work. Our understanding is typically expressed using a model. Sometimes those models are expressed as mathematical equations but often times they are simple visual models or sets of rules or abstractions that appear to be true for a given problem domain. These models can be used to predict a cause and effect relationship and the effect can be measured. If it concurs with the predict results based on the model then the model is believed to be true.

I genuinely believe that we can build these models for the management of software engineering and this week I published a paper that proves this point. My paper from the TOCICO Barcelona conference, shows that using the Theory of Constraints 5 focusing steps and the drum-buffer-rope solution for production flow problems, it was possible to increase the productivity of a sustained engineering department by more than 200%. In the final, quarter of the study period, a 25% increase (elevation) of the capacity constrained resource, produced a 25% increase in overall system throughput - just as the theory and model would predict. In the previous quarter, a subordination and elevation step which involved moving resources from a non-constraint to the capacity constrained resource, produced a 25% improvement. In this case, the resource increase was 33% but it was implemented 1/3rd into the quarter and therefore an actual 25% increase in real resources produced a 25% increase in overall system output. This shows a correlation between cause and effect based on the model of the 5 focusing steps of The Theory of Constraints.

It is this case study that inspired my Stop Estimating blog and contributed to my view that all estimates are muda.

This paper proves that a management science approach to software development can be made to work even in very uncontrolled circumstances of sustained engineering, break-fix and incremental upgrades of IT applications. With no changes to the way software development or testing were conducted, and with no more than changes explained through the Exploit and Subordinate steps of TOC, it was possible to produce a 155% productivity improvement with significant drop in lead time and improvement in due date performance.