Re: GAAP and Agile
- I wonder what would happen if the numbers deviated significantly from what they expected, but with a logical argument. For example:
Programmers don't build; compilers build. Let's say 1% of the time is building then, in the sense, of waiting for a build to happen.
You can actually measure support time, so that one is OK.
We test, but those of us that do TDD use it to help with design. And ATDD helps a lot with analysis. After that the testing kind of happens in almost no time. Let's say a few percent to testing then.
So that leaves analysis and design. Yup. Let's say 45% to each of those.
So we've got 45% analysis, 45% design, 1 % build, 5% test and 4% post launch support, or something like that.
What would they do with that?
--- In firstname.lastname@example.org, "alisongilles" <alisongilles@...> wrote:
> Hello all,
> A somewhat random question, but our Finance team has instructed us to code all of our hours to one of the following categories: Analysis, Design, Build, Test, Post Launch Support.
> Obviously, this feels pretty non-agile. The response to questions on this has been that this coding follows Generally Acceptable Accounting Principles for capitalized/non-capitalized software development expenses, and that we don't have a lot of flexibility in this. Has anyone experienced this or is anyone familiar with the Accounting Principles for software?
- Good points, Mark. AsI said earlier, the accounting profession seems to be 20 years behind in its accounting practices and internal auditing practices for software development.
Date: Tue, 8 Dec 2009 22:46:31 +0000
Subject: [scrumdevelopment] Re: GAAP and Agile
R&D can not be capitalized, but once a product is deemed feasible, all design, development, and testing can be capitalized.
I have a stinking suspicion that your accountants have been led to believe that "analysis" is R&D, and not simply a high-level form of design.
Have you ever read the accounting rules for software development? It's clear that it was written by a group that was convinced that the waterfall model was the only viable one.
For example, software "maintenance" can not be capitalized, when in fact most "maintenance" is actually adding new features to software, which extends its useful life. Software does not break or wear out like a physical item. The same bits will continue to run indefinitely unless the environment changes. When it does change, modifying the software to run in the new environment *is* adding a new capability.
--- In scrumdevelopment@ yahoogroups. com, "extremeprogrammer" <LanceWalton@ ...> wrote:
> --- In scrumdevelopment@ yahoogroups. com, Ron Jeffries <ronjeffries@ > wrote:
> > Hello, extremeprogrammer. On Friday, December 4, 2009, at 2:24:49
> > PM, you wrote:
> > > Criminy! But can you really capitalize 'analysis' differently from
> > > 'design', for example?
> > When did a government or regulator ever care about that?
> That's what I was getting at. If the government and regulators don't care, then why do the accountants or finance department? If they can't use the discrimination between 'analysis', 'design', etc. to gain some tax break or something, then what do they do with the information?
Check out the latest features today Get more out of Hotmail