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".

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.

What the cost accountants (indeed, perhaps almost everybody who belive in the theory of constraints "fix") is missing is that we don't use this to make people do more work. Rather, we identify those constraints that can be removed (not enough testers, wrong type of machine tool, material deliveries at the wrong time), and eliminate the constraint itself (sound anything like an impediment?). This, of course, moves the constraint to a new part of the production environment - the skill of project management is moving it to a place that will impact the project the least.

In the above example (and it is a good example, btw), velocity will drop in team A, because they need to divert time from developing new user story solutions to fixing bugs. In team B, they have time to do both. This is a perfect example of Agile metrics showing us when something needs fixing - our metrics don't tell us what happened, but rather that something DID happen. The team provides the answer to "what happened?".

I submit that any organization that manages its software development projects by cost accounting has not truly adopted Agile methodologies - they may be looking to use the "surface" of Agile (daily standups, burndown charts, etc.), but they quickly return to their more traditional ways.

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".

These are charges against the Technical Debt credit card. If they aren't "paid down", the team will eventually slow to a stop with respect to delivering new functionality - they spend 100% of their time fixing defects or reworking the architecture with no added business value.

BTW, this credit card isn't one of those nice, low interest rate offers. It's a nasty 30% per annum department store card, which will result in the unleashing of Hired Goons if it isn't paid.

Now, if explained in those terms, would the accountants complain about slightly higher estimates?

I don't really like using refactoring as the prime example of the evils of cost accounting. Or, at least, I can think of two other example that may be more recognizable to most.

Example 1: Pair programming

To me, this is the all time champion for demonstrating the potential down side of cost accounting. Taken on it's face, pair programming is a stupid idea. So stupid you'd have to wonder why anyone in their right mind would even suggest it. Use TWO developers to produce one unit of code? I've just halved my productivity. Crazy.

Yet, those who have witnessed the power of pair programming understand that pair programming can actually increase productivity by reducing rework.

Example 2: Collective Code Ownership

What's the single biggest reason for complicated, mega-Gantt chart project schedules? In my experience, it's narrowly defined roles and responsibilities. If the developer who knows that particular area of the project isn't available when you need him all of the sudden you have a dependency in your schedule.

Collective code ownership is intended, at least partially, to address this. There's no obvious advantage to scheduling a particular person for a particular task ahead of time. Unless you like spaghetti snarls of dependencies in your schedule.

And, yet, why do we have so many schedules that end up like this? Is it because it's easier to tell if all of your developers have enough work when you track them as separate resources?

To me, those examples really show cost accounting at it's most costly.

The reason I wrote up this topic specifically is not about ToC or Throughput accounting - although those are important and worthy topics. It is because creating the right environment can make the difference between a successful and unsuccessful adoption. It can make the difference between cargo-culting agile practices, or really seeing the 2x, 3x and more effects on productivity.

This is the type of thinking we should have more often - we should ask ourselves "How does this or the other practice affect the environment we are working in?"

Cost accounting seams to work poorly on knowledge intensive assets and projects.

Cost of motivated, gelled, totally passionate, technically competent, higly productive and effective team of 6 guys, is the same of another team of 6 guys who doesn´t have any of thouse qualities.

Resulting products from one team will be totally different from the other, even the cost is the same.

OpenSource for cost accountants does not exists, is impossible, even is well alive, and changing industries.

Policies and incentives, even moral, based on cost accounting provide wrong direction to go, wrong assumptions for basing desitions.

Local optimization creates a mindset that prevents practices that work elevating outcome (througtput), like pair programming, refactoring, colaboration, taking 20% of time working on own projects, etc.

So I think cost accounting is on the base of some of the disfunctions we see in organizations, that strugle to create winning projects and blame saying that people doesn´t colaborate, don´t have motivation, don´t see the whole picture, don´t assume responsabilities for the end product, don´t work well as teams, etc. But this organizations policies, culture and mindset based on years of this policies, are the ones that creates this kind of behaviors, pushing people on the other direction.

As Goldratt says "Tell me how you meassure me, and I will tell you how I will behave".

I am sorry to be rude. Possibly I am just wrong and dumb. But in my understanding I have to say: "What kind of crappy example is this?"In my opinion, this nice little hypothetical example even more nicely tries to mislead the reader by faking identical premises. Again, maybe I just did not understand it correctly. But does the example try to sell that you have two teams. One with programmers working hard to produce an application and one with programmers working more relaxed and both are able to produce the same amount of output? For me this sounds a lot like two differently skilled teams. Full stop. That is all. No lean magic. I do not know how the rest of the world produces software, but at the places I have been working, testing comes mostly after coding. Ergo, The amount of produced code determines the amount that can be tested. Yes, I can amplify the amount of testing ensuring better quality of software. But in my understanding it is crap to say: "Well, lets's just code less and test more, it will miraculously produce the same amount of functionality."Sure, lean programming keeps people more happy, might produce better code and nicer ideas, but a faster programming programmer will produce more functionality. He might have to stop for bug fixing, but the lean guy already stopped in between to surf the web and have a nice idea.What I want to say is the following. I do not believe that the same amount of functionality can be produced by shifting the workload modulator from more developing to more testing. You can try to make schedules the keep people easy, therefore more happy and in the long run more productive, but not believe less programming will result in the same as more programming just by increasing the testing amount. Sorry.Nevertheless, I would be happy being convinced of the opposite.

Please - by all means - disturb the harmony! The simplifying assumption here is that both teams produce the same amount of code. Team A's bottleneck are the developer's and team B's are the developers. So, given that they go the same pace, how effectively does each respond to a defect?

So, please clarify for me how this is different in:

I do not know how the rest of the world produces software, but at the places I have been working, testing comes mostly after coding. Ergo, The amount of produced code determines the amount that can be tested. Yes, I can amplify the amount of testing ensuring better quality of software. But in my understanding it is crap to say: "Well, lets's just code less and test more, it will miraculously produce the same amount of functionality."

This does not mean that there are not other circumstances - where this neat little hypothetical falls on its face - but in this one it holds up.

Re: Sorry to disturb the harmony - correction and clarification
by
Amr Elssamadisy

<correction>Team A's bottleneck is the developers while team B's bottleneck is the testers. </correction>

<clarification>That is, they are not working at the same pace - not completely matched. Also that testing is done piecemeal. As the developers complete one piece of functionality, it is tested. That is, the granularity is a user story/ use case scenario, and not an entire iteration. This is typical in an agile team.</clarification>

Cost accounting tries to allocate an expense category to every activity that occurs within the process of making whatever it is that drives revenue for the company. Though this might be too difficult for the people with the green visors to envision, could some of the excess time that developers spend honing their craft or taking a mental break surfing the web be allocated to administrative overhead (such as the admins, lights, etc.)? Would this solve the problem of direct and indirect accounting?

Re: Sorry to disturb the harmony - correction and clarification
by
Florian Hartge

Hello Amr,

first, thank's a lot for discussing with me.

Team A's bottleneck is the developers while team B's bottleneck is the testers.

But does that mean, we are just talking about really different teams and their respective ways of coping with the world? Then why compare? I think there are too much assumptions differentiating both teams, but nicely generalized here.

That is, they are not working at the same pace - not completely matched. Also that testing is done piecemeal. As the developers complete one piece of functionality, it is tested.

But exactly that does have to mean that both teams can not be equally productive assumed they are equally skilled. I agree, the lean team is probably better in the long run (less fatigue, more fun, better ideas), but I do not believe this on iteration optimization scale.

I agree with what Bruce Rennie posted. Stepping back from micromanagement might be positive (though sometimes I can understand the management, there are times where it is hard to resist despite better knowledge), but I think the example in the original blog/post is not a very good one to make the point.

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.