Have you ever wondered how much software costs? Most techies vastly underestimate the cost of the software they are writing. Partly this is because engineers and especially software developers are an optimistic lot. Partly it is because our intuition for such things was formed back in the days when we hacked out 1000 lines of code in an all-night session. (I wouldn't trust my life to that code! But that is what our brains remember as being how long it takes to write that much code.)
I've had the opportunity to see how much it really costs embedded system companies to produce code.
The answer is $15 to $40 per line of code. At the $40 end you can get relatively robust, well designed code suitable for industry applications. The $15 end tends to be code with skimpy design packages and skimpy testing. (In other words, some people spend only $15/line, but their code is of doubtful quality.) Use of all-US developers tends to be more expensive than joint development with both US and overseas team members, but the difference is less than you might have imagined.
The methodology used to get those numbers is simply divide COST by code SIZE. Ask a project manager how much a project cost (they almost always know this) and how many lines of code were in the project. Divide, and you have your answer.
COST (in dollars) includes:
- All developer labor plus overhead, fringe benefits, etc.
- Test, SQA, technical writers, etc.
- Expenses (e.g., tools), capital equipment if not in overhead, etc.
- First-level managers for the above
- All activities, including meetings, design reviews, acceptance test, and holiday parties
- Does NOT include support after initial release (which can be huge, but I just don't have data on it)
In other words, you have to account for the whole cost of developing, not just the part where you actually write the code.
SIZE (in source lines of code SLOC) includes:
- All the non-comment lines of code written or substatially rewritten for the project
This metric is far from perfect. For example, tracking developers split among multiple projects gets tricky. So does accounting for reuse of big chunks of code. But if you get a manager to give a reasonable estimate following the above guidelines, the answer always seems to come in at the $15-$40 range for industrial and transportation embedded software.
Sure, you can spend as much or as little on software as you like. But it is hard to find an organization who can field embedded software and have a viable product at less than $15/line. And it is usually just regulated, safety critical applications in which it is worthwhile to spend more than about $40/line. When all is said and done, the results I've seen make sense, and are generally in line with what few other data points I've heard on this topic.
UPDATE, October 2015. It's probably more like $25-$50 per line of code now. Costs for projects outsourced to Asia have done up dramatically as wages and competition for scarce coders have increased.
Companion blog to the book Better Embedded System Software by Phil Koopman at Carnegie Mellon University
Saturday, October 2, 2010
2 comments:
Please send me your comments. I read all of them, and I appreciate them. To control spam I manually approve comments before they show up. It might take a while to respond. I appreciate generic "I like this post" comments, but I don't publish non-substantive comments like that.
If you prefer, or want a personal response, you can send e-mail to comments@koopman.us.
If you want a personal response please make sure to include your e-mail reply address. Thanks!
Subscribe to:
Post Comments (Atom)
Static Analysis Ranked Defect List
Crazy idea of the day: Static Analysis Ranked Defect List. Here is a software analysis tool feature request/product idea: So many times we...
-
It is common to see small helper functions implemented as macros, especially in older C code. Everyone seems to do it. But you should ...
-
(If you want to know more, see my Webinar on CRCs and checksums based on work sponsored by the FAA.) If you are looking for a lightwei...
-
Oct 3, 2014: updated with video of the lecture Here is my case study talk on the Toyota unintended acceleration cases that have been in ...
It's not a good metric - If you put real thought into design, you will need less total lines of code and have a more reliable project. During the maintenance phase, I have often taken a few days to study a problem and come up with a solution that uses less lines of code. A rhetorical question: Would I owe the company money after simplification?
ReplyDeleteI think it is an excellent metric to summarize what happens on reasonably large projects staffed with a representative distribution of programmer abilities using a reasonable design process. This number does in fact include the cost of coming up with requirements, design, test, etc. and represents generally experienced designers who tend to do a good job at design.
ReplyDeleteIf you are talking about one subroutine it could well be you can optimize some (and not others). But over tens of thousands of lines of typical embedded code there is only so much you can do (and these numbers already have a factor of 3 built in to accommodate things like that).