BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Does Cost Accounting Cause Crappy Code?

Does Cost Accounting Cause Crappy Code?

Cost accounting , the standard accounting approach to analyzing the monetary value of a project, treats all parts of a project independently and encourages local optimization. Local optimization of costs means that you focus on task completion time. A focus on minimizing task completion time means that you don't have time for refactoring and other niceties - they are too expensive. This is the source of the all-too-common reason of not doing something because "my manager won't give me time".

Henrik Mårtensson has been blogging about Theory of Constraints and how throughput accounting is needed to create an accepting environment to Agile development practices. He took us through a hypothetical example:

Consider two project teams, A and B. Each team has one project manager, four developers and three testers. Each team member makes €3,500/month and works 160 hours/month. The project managers make €4,000/month. Both teams produce 80 Story Points worth of functionality in a week.

In team A, the developers work very hard, but the testers have time to surf the Web now and then. In team B, it is the other way around. The testers are pressed to keep up, so the developers slow down a bit to avoid deluging them with more work than they can handle. On the same day, a defect is found in each project. Both defects will take eight hours for a developer to fix. What is the cost to team A? What is the cost to team B?

This was a thinking exercise presented to the reader - what happens when a defect is found? Cost accounting tells us that both teams will have the same cost to fix the defect. However, a little thought shows that this is really fiction:

When the developers in team A need to fix a defect, it directly impacts their productivity, which is the productivity of the entire team. The developers in team B, on the other hand, have time to spare. They can fix the defect with less impact, perhaps no impact at all, on overall production capacity. Even without getting into details, it is clear that the impact on the two teams will be entirely different.
So what is the problem? The problem is that cost accounting does local optimization, when in fact we need global optimization. By using cost accounting we create an environment that discourages anything that prolongs the local cycle time.

The somewhat abbreviated version is that if you treat each part of a software development project as independent of any other part, then it becomes important to focus on task completion time. If you focus on task completion time, then you won't waste time on trifles like refactoring, writing unit tests, and doing domain design. Even if you want to, management will keep pushing you to start a new task.

Looking to Theory of Constraints and Lean Manufacturing is nothing new: David J. Anderson has written Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, and Mary and Tom Poppendieck are well known for their work on Lean Software Development. As our community grows we will see more of ideas from these two areas become mainstream and their terminology become as familiar as Stand Up Meeting or Pair Programming.

Rate this Article

Adoption
Style

BT