By The Book 2: The Way Of the Cost Accountant

Let's explore the problem in my previous post using Cost Accounting (CA). CA is the generally accepted management accounting method. It is used by companies all over the world, and it is the accounting method mandated by law in most countries (that I know of):

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.

Comments

Anonymous said…
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?
June 03, 2007 1:15 AM
Kallokain said…
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.
June 03, 2007 11:51 PM
Post a Comment

Popular posts from this blog

Waterfall vs. Agile: Battle of the Dunces or A Race to the Bottom?

Image
The major software methodology wars since the mid 1950’s. Someone was wrong on the Internet, so here we go… In a recent HBR article, It’s Time to End the Battle Between Waterfall and Agile , the author sets up a false premise: There is a war between Waterfall methodology and Agile. The war must end. And finally, you can combine the approaches to get the best of both worlds. This sounds good, but the article is based on a misunderstanding of both Waterfall and Agile. Also, there is no war between Waterfall methodology and Agile. There can’t be, because Waterfall methodology does not exist! Waterfall is a name for large projects that failed in the 1960’s. Waterfall was never a methodology, but a failure to apply the methodologies that existed back then. As I will show towards the end of this article, at least one of the “successful” Waterfall projects mentioned in the HBR article was neither successful, nor a Waterfall project. I got invaluable help from Alistair Cockburn. He fact che
Read more

Performance Evaluations, Business Strategy, and Agile Methodologies

Image
It is performance evaluation time in many companies. This can be stressful, both to the people being evaluated, and the people doing the evaluation. In companies adopting agile software development methods, the tension can be extraordinary. Individual performance evaluations run counter to agile philosophy, which emphasizes team performance over individual performance. However, managers and corporate leaders need to take a few steps back, and consider the impact performance evaluations have on the organization as a whole. Especially now, in the midst of a recession, it is important to look at a companies current policies to see if they can be improved, or if they are actually holding the company back. So, how can a manager evaluate policy? Performance evaluation policies can serve as an excellent example. I'll confine myself to discussing the so-called ‘rank and yank’ methods. These are performance reviews were employees are ranked using a forced ranking system. It usually looks so
Read more

Agile Requirements Structures, Part 1

Image
If you have worked in large Agile projects or programs, you may have noticed that there is often quite a bit of confusion about requirements, what the requirement types are, their purpose, how to write them, how to use them, and above all, what not to do with them. There are many causes for this confusion. Here are some of the more common I have seen: Nobody in the organization has read up on the requirements model it is using, so everyone makes their own interpretation. The organization deviates from a standard requirements model, but nobody knows which standard model the organization is deviating from, and/or there is no agreement about how they deviate from it. The organization has not documented its own requirements model very well. The organization mixes two or more different requirements models, often without realizing it. The organization has documented its requirements model, but finding the documentation is an epic project in itself, on par with when Henry Sta
Read more