Yesterday, in search of some insight into software development management, I dusted off my Accounting Textbook from college. I found two very interesting things under "Managerial Accounting." (Which is a form of Acct. designed specifically to provide guidance/information for decision makers.) It led me to this theory:
Many Generally Accepted Accounting Principles (GAAP) are mired in the 1930's, and this is harming software development(*)
(1) Accounting to Man. Acct. Theory, there are three kinds of departments:
(A) Cost Centers. Manufacturing, HR, etc.
(B) Revenue Centers. Sales Departments.
(C) Investment Centers. Mortgage Departments or asset management firms, which both incur large costs now and (may) bring larger returns later.
Under Man. Acct. Theory, Software Development Departments are COST CENTERS. Managers of Cost Centers are evaluated _solely_ on thier ability to stay below budget. This logic explains the slow machines and lack of cutting-edge tools in our industry - if the only measure of the department is cost ... we need to cut cust.
Now, there is a solution: In manufacturing operations, you can come up with a "standard cost" for a "unit." Then, if you make more units, you can spend more money - as long as you have demand and the cost of developing each unit is below "standard cost"
So, if we had a "unit" for measuring costs (not KLOC, more like Function Points), we could "prove" our expenses we just. We could also set a standard, instead of having budgets that spiral downward in tough times, and we could come up with some measurable proof of ROI. ("Did you notice that that extra $10,000 on HardWare and Training Last year netted us 200 more function points, and at $200 each standard, we "made" $30,000?")
But, sadly, realistically, we just don't have this. So we live in GAAP.
(2) My book surprised me by saying that "every level of management should be involved in the budgeting process" - but not ANY of hte people actually doing the work. The argument was that lower managment had a better idea of "reality" than upper management. What about the people doing the work?
Then I remember that GAAP was written in the 1930's, when American business was much more entrenched in a caste mentality, and a technical middle class hadn't fully emerged. The Typical level 1 Supervisor back then MIGHT have MAYBE had a high school education. Involving labor in budgeting was simply unrealistic and not practical - they didn't have much to add.
Today, a typical Software Department might have someone with a degree in accounting, business, a couplea CS guys, etc, etc. They probably each have years of professional business experience combined with a great deal of experience in create project plans and living with the consequences of budgets. They may have more time with thier current company than thier manager. Why not involve them (to a slight extent) in the planning process?
My guess? Because the accounting books say not to.
This leads me to my solutions:
(1) Software Companies seem to be generally better at this than companies that do "something else" as a core function. Obviously, Wal-Mart sees it's money in retail sales, not automation. Exceptions about for "sales force automation", etc, etc, but, overall, Software is a cost Center for these companies - while technology companies may see Software departments as having direct effects on revenue.
(2) SW Companies led by programmers, former programmers, or other folks who have a great deal of experience in technology are much for likely to "get it." (IE Yahoo's Semil might have problems with this.)
(3) SW Management Programs and "MBAs with an emphasis in E-Commerce"(etc) should teach something like Joel Spolsky's Article on Converting Capital into Code through programmers. (http://www.joelonsoftware.com/articles/fog0000000074.html) (IE - The idea is that when you invest in hardware and tools and morale budgets, you get more stuff done, which you can then sell for more money.)
(*) - GAAP was created in the 1930's as a response to the great depression.
Friday, March 15, 2002
Your technology budget should be based on one simple factor. If your software makes more money (or causes more savings) than it costs to create and maintain, then it is worthwhile. Otherwise, it is not.
Friday, March 15, 2002
Interesting ideas here. I have, myself, been thinking that some of the problems we have with SW development is because management thinking is stuck back in the early part of the 20th century when the low level workers were doing production line work, not thinking type work.
The basic goal of a mid-level manager is to advance their career and if lower costs is the way to do it, that's what they'll do.
But this doesn't seem to explain the whole problem. Developers' salaries, office space, PCs, and software tools are all expenses. Why do so many companies seem willing to hire numerous developers and skimp on the support items which are a lot cheaper?
My hypothesis: a manager's status and, thus, future career prospects, depends on the number of people managed, not on their output.
Note on Bella's comment: It is not sufficient that benefits exceed costs. Benefits must exceed the benefits of any other use of the funds to make the expediture justifiable. (i.e., best ROI)
Friday, March 15, 2002
Has anyone ever read any books by Goldratt? http://www.amazon.com/exec/obidos/ASIN/0884270610/qid=1016234486/sr=8-1/ref=sr_8_67_1/002-9398894-1701601
He hits on many of the same points. Basically he argues optimizing an accountant’s equation may not be the best thing for the business in the long run.
His books are written as a novel, like Deathmarch. You have to work past the fabricated story, but he makes good points. I would recommend it even though it is directed at manufacturing managers more than software folks.
Knowing about bean counters helps you understand why letting the VC’s into a startup can cause a quick and painful death. They impose cost accounting so they can understand the balance sheet.
If you’re a manager and you’re sacrificing long-term profits for local accounting optimization, are you really advancing your career? You could probably go to the unemployment office and ask the people in line.
Friday, March 15, 2002
(The following mostly applies to only large companies)
The post above runs along similar lines to what I have heard: "The key to managerial compensation lies in direct reports."
Or, in other words: "The big bucks comes when a lot of people report to you."
Plus, in a "boom" year, it's possible for a manager to increase departmental size as much as +50%. (Allthough multiple hundreds of percents were possible in the dotCom era.) Two years later, when the E-Conomy is back in the tank, the only thing to cut before starting layoffs is "toys" - hardware, software, captial expenses, training budgets, etc. And, sadly, managerial accounting "helps" this.
Thanks for the book recommendation!
Monday, March 18, 2002
"Interesting ideas here. I have, myself, been thinking that some of the problems we have with SW development is because management thinking is stuck back in the early part of the 20th century when the low level workers were doing production line work, not thinking type work..."
The statements about GAAP made me think about something I've suspected for a while now.
I've had a pretty fair amount of experience with organizations that had little or no process (think CMM level 1). It seems to me that it's especially difficult to get orgnizations at/near "CMM 1" to agree to pay for process improvements or tools to make work better/faster/cheaper.
My suspicion is that the folks who'd authorize the expenditures are often steeped in the "old-fashioned" GAAP (as described above) thought, and as a result, they want you to show ROI before approving the change. Well, that has a nice ring to it, sounds reasonable and all, but there's a problem for CMM 1 organizations...
ROI computations normally require a ratio between returns(or costs) *with* the proposed change and returns(or costs) *without* the change (i.e. the current state of the system). OK, makes sense. The problem arises because in an immature process, by definition, there's no data normally available to tell you what the current return(cost) is. Without this number, you have nothing to compare against.
You're left telling folks that the change will cost $X to buy or put in place, but nobody knows what the hell things cost now, so how do you make a case?
I suppose you can do a lot of research and try to find case studies, assuming the decision maker believes them.
At this point, I'm about cynical enough regarding the whole situation that I'd almost say you just have to have a leader who "gets it" to begin with if you hope to get improvements made in immature organizations in a reasonable timeframe.
Another tactic is to wait until the inevitable blow-up when the existing chaotic process messes all over itself and then point out (with as much restraint and diplomacy as can be mustered) that perhaps now they might see the value in having done what was suggested. Seems like a hell of a way to run a railroad, though.
Tuesday, March 19, 2002
Fog Creek Home