"In reality, most projects worth doing are not repetitions of previous things."
Thank you for that.
If it has been done before -- same problem -- same technology -- then we should be able to clone that solution and avoid creating a software development project. If there's something novel -- new problem -- new technology -- then we can't easily predict the whole sweep of software development effort.
The whole Estimation Charade is an artifact of the way accountants exercise control over the finances. They require (with the force of law) that budgets be written in advance. Often in advance of the requirements being known. When we sit down to fabricate next year's budget, we're dooming some fraction next year's projects to a scramble for funding leading to cancellation and failure.
Accountants further require that software development be arbitrarily partitioned into "capital" and "expense". There's no rational distinction between the phases. The nature and scope of the work don't change at all.
Yet.
Somehow, the accountants are happy because some capital budget has been spent (as planned 18 months ago) and now we're spending expense budget. From an accounting perspective, some kind of capital asset has been created.
Think of it. Some lines of code are a capital asset. Other lines of code are an expense.
Someday, I'll have to ask some accountants to explain how I can tell which was which.
A few thoughts on this (as a finance manager and beginning programmer who has read your online books).
ReplyDelete1) If your issue is that the accountants can't even explain the difference between what is capitalized and what is expensed, you have bad accountants and you should read the standards yourself. They're not that long.
If the software to be sold, leased, or otherwise marketed, FASB topic 985.20.25 answers your question.
If the software is internal use, FASB 340.40.25 has your answer.
2) Assuming #1 isn't your issue, it might be that you find the phased process outlined in 340.40.25 and 985.20.25 to be far more reflective of a waterfall methodology than the more Agile methods you use.
If so, here's a pitch that talks about how to apply existing accounting rules to Agile methodologies:
http://www.scribd.com/doc/40154541/Agile-Accounting
There is always considerably leeway in the determination of accounting phases. Perhaps you can show this pitch to your accountants to get them to see that they can interpret the phases in a way that is more consistent with Agile methodologies.
3) "Some lines of code are a capital asset. Other lines of code are an expense." Yes, we know. If it makes you feel any better, it doesn't make sense to us, either, and there are dozens of other accounting areas that are equally arbitrary.
Good finance managers know that the only thing that matters is cash flow and the "market value" of the software you build (vs. the accounting charges and resultant assets). They also know that there are better uses of developer's time than supporting accounting processes which, quite frankly, has no impact on a company's value.
If the finance people you have in charge of your business don't see it that way, they're just not good at what they do.
Hey, nice site you have here! Keep up the excellent work!
ReplyDeleteISTQB Training Institute in Chennai