CA makes the calculation like this: A developer has to work 8 hours to fix the defect. The developer makes €3,500 per 160 hour month. This would work out to €175 (8⋅3, 500 ÷ 160 = 175). However, CA allocates overhead costs from management, rent, electricity, and other things. These costs are shared by all workers. The overhead costs can be quite large. Let's be conservative and say they are €1,000 per developer and month.
A developer’s total cost is now 4,500/month (3, 500 + 1, 000). Cost Accounting then gives us 8 ⋅ 4, 500 ÷ 160 = 225. That is, it would cost €225 to fix the defect. The cost is the same for teams A and B.
Let's do a thought experiment. Have a look at the figure above. The teams spend working time in order to produce software. Both teams are equally productive, but their limitations are different. 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.
Cost Accounting told us the cost of fixing the defect is the same in both cases. We have just seen that it can't be. Something fishy is going on. It could be me, I am not an accountant, so I could be misunderstanding how Cost Accounting works. On the other hand, I have checked Cost Accounting out fairly thoroughly, so that is probably not it.
Could it be Cost Accounting itself? Some people believe so. Check out what Wikipedia says about Cost Accounting. Here is a quote:
...using standard cost accounting to analyze management decisions can distort the unit cost figures in ways that can lead managers to make decisions that do not reduce costs or maximize profits.Why should software developers care? Because software development projects are economic engines. If the theory governing about project economics is flawed, then the project management will be flawed. This should be of special concern for anyone working with agile, because agile will work only if management does not make mistakes like the one above.
In my book, I am showing a connection between the economic mistake you just have seen, and crappy code. 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.
Next time I'll work through the example using Throughput Accounting. Throughput Accounting is based on the Theory Of Constraints. As we shall see, the results will be quite different. This will affect management behavior, which will create a different environment for developers.
I am looking forward to your upcoming blog post on Throughput Accounting. While am waiting for it, is there any book on the subject that you would recommend that I read?
My main reference on Throughput Accounting (TA) is Thomas Corbett's "Throughput Accounting". The book is available from Amazon.
David Anderson's "Agile Management for Software Engineering" also has a description of how to use TA to calculate the economic effects of defects in software.
TA grew out of the Theory Of Constraints (TOC). There are several TOC books that mention TA without going into details.
There is a new TA book available by Stephen Bragg. I haven't read it yet. I am ordering it from Amazon tonight.
Post a Comment