Estimated costs of embedded software.
Roberto Waltman
>I am trying to find some figures as to the estimated cost of writing
>embedded software. I have some figures that show that it is estimated at
>$10 per line.
The number will vary depending on many factors: complexity
of the project, team size, team experience, maturity of the
tools/environment used, availability (or lack thereof) of
hardware to test the software being developed, the amount of
totally new code to be developed (as opposed to
reusing/modifying existing code), the need (or not) to
develop new solutions (algorithms, techniques) as opposed to
solving again previously know problems, etc.
In any case $10/line sounds extremely low.
In a 'normal' (is there such a thing as normal?)
environment, were programmers, in addition to 'just writing
and testing their code', also need to
+ study a myriad of documents and specifications
before they understand what needs to be done
+ write documentation and test plans/cases,
+ spend time in meetings, (*many* meetings...)
+ write reports,
+ absorb info from people leaving to greener pastures,
+ train newcomers
+ do everything again when project specs and/or
management/marketing plans change
+ etc., etc.
the annual output is between a few hundred lines of code per
year per person, (in safety critical applications,) to a few
thousand (less than 6K ?) lines of code per year per person.
Divide an average salary (and the salary's overhead per
person) + the cost per person of maintaining a building,
computer network, software tools, maintenance teams, human
resources, etc. into 'a few thousand lines' per year and
reach your own conclusions.
RW.
Ed. Jones
size, complexity and team size.
Some figures that come to mind are based on total project content in which
a design is drawn out, documentation produced, code written and tested, then
the time to manufacture added in.
The figures I remember were 11 lines per day per person for "high-level" and
about 8 lines per day for assembler.
My own measurements show approximately 30 lines per day C code for small
projects which don't require "ISO 9000" or the like grade of documentation and
in small teams.
The costs from that are simple, add up all the overheads and salary and
do the division.
John Larkin
Hmmm...
eight lines per day is one line per hour. So what is the guy doing
during the other 59 minutes?
John
Alf Katz
> Hmmm...
>
> eight lines per day is one line per hour. So what is the guy doing
> during the other 59 minutes?
>
John,
It's not just "the guy", it's an average of all guys (and gals). During
the other 59 minutes the good ones are:
1) Analyzing the problem (including getting to know the system) and
documenting it
2) Designing the solution and documenting it
3) Reviewing it with 1-5 other programmers
4) Testing it (including designing and documenting test plans and test
cases)
5) Performing configuration management on 1-4 (plus the code) above.
6) Going to the toilet, having sick days, public holidays annual leave,
training other programmers or being trained, having a cup of coffee, going
outside for a cigarette.
Nevertheless, these people are producing more than the average.
The bad ones are:
1) Recoding it from scratch because they didn't actually understand the
problem
2) Recoding it from scratch because the solution didn't fit together
3) Recoding it because an elementary mistake got through for lack of a
review e.g. if (c=1)
4) Recoding it because it wasn't tested and a mistake got into the field
5) Recoding it from scratch because they didn't have a working
configuration to go back to.
6) Going to the toilet, having sick days, public holidays annual leave,
training other programmers or being trained, having a cup of coffee, going
outside for a cigarette.
7) Scratching their heads trying to figure out what's gone wrong because
there isn't any documentation
Unfortunately, these people drag the average way down.
happy programming
--
Regards,
Alf Katz
alf...@ieee.org
Steven Van Hulle
news:zCZtORsrzvEtKtz6=ttRzd...@4ax.com...
> On Wed, 12 Jul 2000 16:03:32 +0100, "Ed. Jones"
> <edward...@compuserve.com> wrote:
>
> >Estimates of work throughput are notoriously variable, depending on the
project
> >size, complexity and team size.
> >
> >Some figures that come to mind are based on total project content in
which
> >a design is drawn out, documentation produced, code written and tested,
then
> >the time to manufacture added in.
> >
> >The figures I remember were 11 lines per day per person for "high-level"
and
> >about 8 lines per day for assembler.
> >
> >My own measurements show approximately 30 lines per day C code for small
> >projects which don't require "ISO 9000" or the like grade of
documentation and
> >in small teams.
> >
> >The costs from that are simple, add up all the overheads and salary and
> >do the division.
> >
> >
> >
>
>
> eight lines per day is one line per hour. So what is the guy doing
> during the other 59 minutes?
>
> John
>
SMOFF
Here's what I do:
- Get a cup of coffee
- Have a chat with the boss' secretary
- Watch the woodpeckers through the window
- Download loads of naughty pictures
SMO
Looks like a typical WISCA reaction: Why Isn't Sam Coding Anything?
Some managers (I know quite a few) think that a programmer's job is writing
programs. And that's it.
OK, my job involves more than programming; I'm also designing the hardware.
So write a program, draw a schematic, make a PCB layout. One project a week.
Here's what I do (in no particular order):
- Talk with product manager.
- Think about a design solution.
- Talk with suppliers.
- Take courses.
- Talk with purchasing.
- Talk with mechanical engineer.
- Try to think of possible problems (FMEA)
- Think of solutions for these.
- Check planning.
- Set up software structure.
- Select microcontroller.
- Write software.
- Breadboard uC environment.
- Debug software.
- Evaluate components.
- Build prototypes.
- Check which standards are applicable.
- Write test spec.
- Do tests.
- Evaluate test results.
- Check planning. (2nd time. I know)
- Write documentation.
- Plan production tools.
- Check testseries.
- ...
I skipped the coffee here, and maybe some other things as well, but yes, 1
line per hour looks reasonable.
Steven
Herman
of different projects and it came down to 2.5 lines of code per hour per
person, for all of Ada, C and ADSP assembler projects, with from 1 to 50
programmers in the team, for both military and commercial projects. It
seems like a magic number - a cosmic programming constant...
Cheers,
Herman
http://www.AerospaceSoftware.com
Paul E. Bennett
jjla...@highlandSNIPTHIStechnology.com "John Larkin" writes:
> Hmmm...
>
> eight lines per day is one line per hour. So what is the guy doing
> during the other 59 minutes?
Thinking, writing the documntation, testing, debugging, analysis.....
There is plenty he could and should be doing. However, I still prefer to
look at projects on a function point basis as it has more relevence to
the code produced. Sometimes a great deal of analysis and design effort
may need to go into just one or two lines of highly optimised code.
--
*******************************************************************
Paul E. Bennett ...................<email://p...@amleth.demon.co.uk>
Forth based HIDECS Consultancy ....<http://www.amleth.demon.co.uk/>
Tel: +44 (0)7971-620145 / NOW AVAILABLE:- HIDECS COURSE
Going Forth Safely / see http://www.feabhas.com for details.
*******************************************************************
John Larkin
<stev...@pandora.be> wrote:
>"John Larkin" <jjla...@highlandSNIPTHIStechnology.com> wrote in message
>news:zCZtORsrzvEtKtz6=ttRzd...@4ax.com...
>> On Wed, 12 Jul 2000 16:03:32 +0100, "Ed. Jones"
>> <edward...@compuserve.com> wrote:
>>
>> >Estimates of work throughput are notoriously variable, depending on the
>project
>> >size, complexity and team size.
>> >
>> >Some figures that come to mind are based on total project content in
>which
>> >a design is drawn out, documentation produced, code written and tested,
>then
>> >the time to manufacture added in.
>> >
>> >The figures I remember were 11 lines per day per person for "high-level"
>and
>> >about 8 lines per day for assembler.
>> >
>> >My own measurements show approximately 30 lines per day C code for small
>> >projects which don't require "ISO 9000" or the like grade of
>documentation and
>> >in small teams.
>> >
>> >The costs from that are simple, add up all the overheads and salary and
>> >do the division.
>> >
>> >
>> >
>>
>> Hmmm...
>>
>> eight lines per day is one line per hour. So what is the guy doing
>> during the other 59 minutes?
>>
Steven,
ok, but when you *are* programming, how many lines per day do you
produce? Does a 2000 line embedded program actually take you a year to
write?
I do the same things you do... hardware design, PCB layout, FPGA
design, manuals, specs, customer support, all that. But when I *am*
programming, I run about 300 lines/day of debugged assembly code.
I guess I'm just glad I'm not a programmer. And it's obvious that I
can't afford one.
John
Herman
but that doesn't help a lot when estimating the cost of a new project.
Also, towards the end of the dev cycle, the lines of code per hour can
become negative, due to optimizations...
Steven Van Hulle
I'm currently working on a design which has ridiculously few components. I
always expect some manager popping the question "It took all this time to
end up with *this*?". Maybe they do understand it's because I worked so long
at it that the result looks so simple.
In this case the cost is high, although the part count is small. Space is
the keyword here. Mechanical constraints limit the number of options for
components to choose from. (You can easily replace the electronics by
software: the limitation could be the uC ROM size).
There is a number of factors in play when calculating cost. Size is one of
them. In my case, the smaller the size, the greater the cost. (Depends on
the type of product you work on.)
But also: the smaller the size, the smaller component count. So component
count is reversely proportional to cost.
May well be the same for source line count.
Steven
"Herman" <aero...@AerospaceSoftware.com> wrote in message
news:396E0864...@AerospaceSoftware.com...
Steven Huang
[...]
> ok, but when you *are* programming, how many lines per day do you
> produce? Does a 2000 line embedded program actually take you a year to
> write?
The key point that I'm afraid you're missing is that "x lines per
day" statistics are valid only within a certain context. One such
context is the total number of lines, because while a 300-line
program might be finished in a day, a 3,000-line program will quite
likely take more than ten days, and a 30,000-line program almost
certainly will take longer than 100 days. Complexity rises
exponentially with the number of lines in the program.
Another such context is the number of programmers involved. A
program that might take one year for one programmer to complete
might take seven months for two programmers to do, and perhaps
five months for three programmers. This is because they need to
communicate with each other, which is a cost.
> I do the same things you do... hardware design, PCB layout, FPGA
> design, manuals, specs, customer support, all that. But when I *am*
> programming, I run about 300 lines/day of debugged assembly code.
[...]
How many such days? How big is the program? How many programmers
are involved? What quality assurance processes do you follow? What
do you mean, precisely, by "debugged"? What documentation do you
supply with this code?
Without these background contexts, comparing "20 lines per day" to
"300 lines per day" is meaningless.
Paul E. Bennett
aero...@AerospaceSoftware.com "Herman" writes:
> Never mind the 'looks reasonable'. I actually measured it over a number
> of different projects and it came down to 2.5 lines of code per hour per
> person, for all of Ada, C and ADSP assembler projects, with from 1 to 50
> programmers in the team, for both military and commercial projects. It
> seems like a magic number - a cosmic programming constant...
Does that include the code you throw away (for reasons of quality,
integrity or plain solutions that didn't work out)?
I know that some weeks I will not write a single line of code and
others where I will do nthing but. Then non-ciode writing weeks are
spent in other activities like design of hardware or perhaps in
system architecture.
Jan Leithe
"Steven Huang" <sth...@hns.com> wrote in
news:8kl3gt$nao$1...@hnssysb.md.hns.com...
Take a look at COCOMO (constructive cost model).
It takes into account a lot of the factors you mention:
- Size of system
- Type of system and complexity of system
- Need for size optimation and execution time optimation
- Development time
- .....
You find a lot of information available on the WEB.
I used this model approx. 10 years ago. Our experience with it was rather
good,
also on embedded systems. We also found that we had to include a
"calibration factor"
to get the correct figures. I think this figure was approx. 2.5.
(our team was 2.5 more productive than stated by the model).
Typical project size was in the range 10.000 - 100.000 code lines in final
system.
Ed. Jones
> produce? Does a 2000 line embedded program actually take you a year to
> write?
Yes and no, in that order. The values were for fully designed, documented, tested
and shrinkwrapped code. The "raw" production rate was seen to be over 250 lines
per day per person, but as simply text in a file.
For larger projects, the effect of personnel interaction and complexity reduces
the 30 lines per day downwards to the more likely 11 lines per day over the
whole life of a project until first saleable release.
A recent project of 18,000 lines took a man year to create, (85 lines per day)
but involved a large amount of re-use and known algorithms, so reducing the
uncertainties and time drain of entirely fresh code.
I do recognise that "lines per day" is a dreadful measure!
Rennie Allen
>
> With lines of code it's a bit like component count in an electronic design.
> I'm currently working on a design which has ridiculously few components. I
> always expect some manager popping the question "It took all this time to
> end up with *this*?". Maybe they do understand it's because I worked so long
> at it that the result looks so simple.
Nail on head dude. Managers *so* do not understand. One manager I worked for
(who shall remain nameless) was actually disappointed when we managed to squeeze
a very sophisticated system into 32K (and still have maintainable source code).
> In this case the cost is high, although the part count is small. Space is
> the keyword here. Mechanical constraints limit the number of options for
> components to choose from. (You can easily replace the electronics by
> software: the limitation could be the uC ROM size).
Above system had (you guessed it) 32K ROM.
> There is a number of factors in play when calculating cost. Size is one of
> them. In my case, the smaller the size, the greater the cost. (Depends on
> the type of product you work on.)
Smaller size equals greater development cost, but lower lifetime cost; however,
there is a critical point at which in the effort to make it small,
implementation
compromises must be made (this has little effect on development cost, but a huge
negative impact on lifetime costs). Bottom line is (as Einstein said)
"make it as simple as you can, but no simpler".
> But also: the smaller the size, the smaller component count. So component
> count is reversely proportional to cost.
> May well be the same for source line count.
Exactly the same for source line count, except that for hardware the paybacks
for
the increased development time come from ease of mfg, reliability, and overall
reduced product cost, while for software the payoff comes in reduced maintenance
expense (i.e. debugging + feature enhancement).
--
To succeed in this world it is not enough to be stupid; you must also be
well-mannered. - Voltaire
Steven Van Hulle
"Rennie Allen" <ral...@computermotion.com> wrote in message
news:396F317A...@computermotion.com...
> Steven Van Hulle wrote:
> >
> > With lines of code it's a bit like component count in an electronic
design.
> > I'm currently working on a design which has ridiculously few components.
I
> > always expect some manager popping the question "It took all this time
to
> > end up with *this*?". Maybe they do understand it's because I worked so
long
> ^ not ?
>
> > at it that the result looks so simple.
>
> Nail on head dude. Managers *so* do not understand. One manager I worked
for
> (who shall remain nameless) was actually disappointed when we managed to
squeeze
> a very sophisticated system into 32K (and still have maintainable source
code).
The "maybe" is because you never know with managers...
> [snip]
> negative impact on lifetime costs). Bottom line is (as Einstein said)
> "make it as simple as you can, but no simpler".
>
Yeah, sometimes he was right.
> [snip]
> To succeed in this world it is not enough to be stupid; you must also be
> well-mannered. - Voltaire
Ah, that's why it didn't work. 'm gonna try it on Wednesday. Thanks for the
tip
Steven
Blakely LaCroix
Snipped from this thread, original author lost.....
>
> With lines of code it's a bit like component count in an electronic
> design. I'm currently working on a design which has ridiculously
> few components. I always expect some manager popping the
> question "It took all this time to end up with *this*?".
>
I worked with a programmer in S. CA years back who justified his development
budget to senior management by saying:
"Drivers are like women's underwear. The less there is to see, the more
expensive it becomes."
He got his funding.
Blakely LaCroix
Minneapolis, Minnesota, USA
The best adventure is yet to come.
Simon Brady
>
> Sometimes a great deal of analysis and design effort
> may need to go into just one or two lines of highly optimised code.
Or, for that matter, one or two lines of _correct_ code.
Simon Brady sjbrady
Research Assistant, Computer Science Dept. at
University of Otago, Dunedin, New Zealand acm dot org
Steve Rencontre
alf...@optushome.com.au (Alf Katz) wrote:
> >
> > Hmmm...
> >
> > eight lines per day is one line per hour. So what is the guy doing
> > during the other 59 minutes?
> >
> [...]
> The bad ones are:
> 1) Recoding it from scratch because...
I would take issue with this. IMO, recoding from scratch can be the mark
of a /good/ programmer. Just as the old military proverb says that no
battle plan survives contact with the enemy, no software design survives
contact with the silicon.
Attempting to beat intrinsically unsuitable code until it sort of just
about fits the problem is far worse than recognising you've painted
yourself into a corner and starting again.
I throw away a lot of code without the slightest feeling of guilt. The
experience of building something often teaches you a better way you
couldn't have known in advance.
--
Steve Rencontre http://www.rsn-tech.demon.co.uk
//#include <disclaimer.h>