Lines of code per day (in embedded systems)?

[ricko_uk]

Hi,
this question has been asked countless number of times on many forums but haven't come across answers specifically for embedded systems coding.

The reason why I am assuming the answer is different (i.e. less lines/day) is that:
a) in embedded systems you have to work with other systems (which might have bugs) and external hardware/mechatronics that can behave in all sorts of unexpected ways especially when environmental or system conditions can change dynamically. Not to mention the fact that just to test a piece of code, sometimes because you have to run the entire system through a cycle you waste 5-10 minutes every time you test a modification...
b) for some platforms/vendors/micros the tools are not as advanced as for the PC microprocessor's world

So I am curious how many lines of good quality code per day do you write on average?
That includes architecture design, coding, debugging, refactoring/polishing, documentation, extensive testing, etc...

Thank you

[WattsThat]

Haven’t measured it for years, don’t get paid for it these days. Fun stuff only.

Have you seen this:

http://www.ganssle.com/tem/tem400.html

Scroll down to “what does firmware cost”. There are some interesting LOC metrics in there.

[profdc9]

Not to be evasive, but I think this is a "how long is a piece of string?" question.

Any development process that rates the quality of the code or the developer based on the rate at which code is written is going to inevitably favor quantity of quality.  If you are writing the embedded code for someone's pacemaker, probably writing one line of code per day on average is okay as long as it doesn't result in any stopped tickers.  If you are writing the embedded code for a doorbell, and then doorbell doesn't ring, someone can usually knock. 

When I worked at Motorola years ago on the old analog cellular phones, some of the assembly code files might have four actual lines of assembly in them and 50 lines of comments.  Does this count as four lines of actual code because it is four 68HC11 instructions?  Or does it count as 54 lines including the comments? 

What is much more important, in my opinion, is the discipline needed to produce the reliable, predictable progression of a software process and the ability to, if possible, guarantee a response to critical events.  I don't think the basics behind this have changed that much even as the hardware has become more complex.  Ultimately, computers are state machines, and we want the transition from state to state to be well defined.   The process of responding to an external event needs to be well understood, starting at the interrupt or delivery of a bus message, to the queueing of the event, to the dispatch of the event, and any further alterations in the state machine as a result of the event.  If the code paths become too complex or the priorities of events become unclear, the dispatch of events will become unclear and unpredictable and edge cases and race conditions result. 

If your management really assesses productivity using code quantity, eventually someone will be left holding the bag for a monstrosity of code that simply exists to check a box, and its likely whoever produced the code will have wisely moved on from that situation.  Engineering is hard even when you think you know what you're doing, and becomes doubly so when ridiculous constraints are placed on design.
 

[T3sl4co1l]

Worth noting whether this is merely an indicator for reference, or an actual performance metric.  I suspect not the latter, as it's a notoriously poor metric, and I think even most managers these days realize this.  But as you can see from the above, you can never be too careful, I guess...

FWIW, in a recent project, I did about 700 LoC in 23 hours, for a simple, self-contained project on a platform I'm comfortable with (no libraries besides libc, no networking/comms/APIs, etc.).

Tim

[profdc9]

If you want a reference (which is not particularly relevant or helpful), for my own battery charger project I cranked out about 800 lines in a day or two, on or off, for the Arduino (as while its not the best environment, its super common and accessible).  For example:

https://github.com/profdc9/FlexibleCharger/blob/main/src/BatteryCharger.ino

But keep in mind this is just a personal project and there's no guarantees for it.  My mistakes could result in the power supply applying excess voltage and current to a battery and causing it to leak and explode.  Obviously, if this was for a real product, I would need to be more serious about testing it, but the project is just more of an experiment in trying to find better ways to improve battery life.  It is basically a switching power supply with constant voltage and current modes that are digitally controlled.

[mazurov]

I had a gig last year when I removed about 20K lines of code in about a month. The previous guy had no clue :-).

As far as cost per line in embedded - from my experience, C++ is about 3 times more expensive than C so it makes sense to specify the language.

[HwAoRrDk]

Yes, you really can't measure the 'worth' of a codebase in terms of number of lines of code, nor can you effectively measure progress or predict timelines based on a lines per day metric. I'm sure lots of sharp-suited types with MBAs like to think you can, but you can't really. Writing code is not a production line, going through the same motions repetitively. It's more like painting a picture but sometimes doing the trees and clouds in the same style as has been refined before (where the action comes without forethought).

Sometimes, the number of lines of code written per day is negative. On several occasions, I've hammered away all day on a piece of code, only to delete it all the next day because I took the wrong approach or thought of a better way.

As others have said, there is often a correlation between quality and productivity (when measured in lines/day). The very highest quality (which in the embedded world can be synonymous with safety or reliability) might only be single-digit lines of code per day. Some code may be voluminous and turned out quickly, but is akin to a rank mound of spaghetti, written with zero shits given, just to "get it done".

[NorthGuy]

When I copy and paste pieces from previous projects, I can "write" a lot of code very quickly. Really.

[T3sl4co1l]

Oh, remembered this article I saw last week:
https://factorio.com/blog/post/fff-366

Tl;dr: as the codebase grows, the connections between its various parts, tend to weigh down every additional LOC.  The cost is nonlinear, the returns are diminishing.  At some point (in this case), it pays to find and refactor the pain points -- up to and including whole rewrites of those sections, if necessary.  The easier it is to add features, without having to reason about the function of everything those features depend on / interact with -- avoid leaky abstractions in your interfaces -- the faster your code can continue to grow.  Some of which can only be learned through experiment (i.e. doing it wrong the first time), some of which comes after years of experience in structuring designs.

I can personally say I already feel this, with just the little ~kLOC codebases I've made.  I might have only dozens of functions, but I have to keep remembering their arguments and effects and cross-checking to make sure everything's doing what it's supposed to do.  And like, updating header files and all that boilerplate, because C is C.  I don't have experience with large codebases, obviously; and someone with that experience, will be able to handle more lines, but should also command a higher price, for the same reason.

Tim

[MIS42N]

Too many variables to put a figure on it. I have a project, one piece of code services an interrupt 40,000 times a second. I spent many hours whittling it down to 20 lines of assembler and ensuring it worked under all conditions I could think of. Another piece of code runs at most once a second and more likely every few minutes. To save instructions it could be written as a 6 instruction loop. But time was more important than instruction space, so it was cut and paste 4 instruction in line 8 times in 5 minutes.
A friend and I once looked at the problem of converting DDMMYY to bDMMMYY (bD zero suppressed day, MMM three letter month). I dashed off 45 lines of assembler, tested and working in an hour or so. Friend chopped it to 30 lines, long story we produced many variants all the same number of instructions (I think it was 22), same execution time, different instructions, and none of them easy to follow. If it was a commercial job, the 45 lines would be the final product - easy to understand and maintain.
Some code can be tested in a simulator, some has to be stress tested in realistic situations.
It's a balance between unit cost, speed, available memory, time to market, maintenance (product lifetime), cost of failure to mention some considerations. Then there's the quality of the coder ...
yes - how long IS that string ...

[Doctorandus_P]

I once spend 3 weeks debugging code.
In that time I was throwing away pieces of code while still keeping the fault reproducible. and I managed to reduce the code from around 2MB of source code to about 50kB.

After that I handed it off to a college and he spent another day or two with a logic analyzer.
The fault was finally tracked down to a pointer with a too small address range so it wrapped around.

Judging productivity by LOC is somewhat similar to judging a diet by counting the amounts of colors in it.

[madires]

There's no simple answer because it can be many lines/day for a gadget and down to a few for something safety critical which requires triple-checking everything, being fault tolerant and dealing with all possible error conditions.

[Scrts]

There's no simple answer because it can be many lines/day for a gadget and down to a few for something safety critical which requires triple-checking everything, being fault tolerant and dealing with all possible error conditions.

Agreed. Now if I write a library of 3000 lines of code and then use that library calling 10-20 functions later on - how does that count?

Lines of code is NOT a good measure at all.

[SiliconWizard]

Yes, this is a pretty poor metric for many reasons.
Not only does it depend on the project and its requirements, but also on code style. Even worse: there is no strict way of estimating the total number of LOCs needed for a given project and requirements. So it's extremely hard telling if one particular implementation actually uses too many LOCs, or too few.

As a paradox, actually using the fewest possible LOCs (as long as readability, correctness and maintainability are guaranteed) for a given implementation should be a goal in itself. Which contradicts using the number of LOCs per day as a productivity metric.

[pardo-bsso]

As far as cost per line in embedded - from my experience, C++ is about 3 times more expensive than C so it makes sense to specify the language.

Expressive and expensive.
Also a source of many expletives.

It makes some things more concise (hi there GObject) but then I read anything that Raymond writes (like https://devblogs.microsoft.com/oldnewthing/20210628-00/?p=105374) and I wonder what are they drinking when updating the standard.

About the OP question, some days are different than others and it is not a good metric but I can spend 10 hours chasing a bug and then commit 3 lines.

[coppice]

Worth noting whether this is merely an indicator for reference, or an actual performance metric.  I suspect not the latter, as it's a notoriously poor metric, and I think even most managers these days realize this.  But as you can see from the above, you can never be too careful, I guess...

FWIW, in a recent project, I did about 700 LoC in 23 hours, for a simple, self-contained project on a platform I'm comfortable with (no libraries besides libc, no networking/comms/APIs, etc.).

Tim

I've done a couple of things in the past where I turned out >1000 lines of code per day, but:

• These were applications I knew intimately. I had a full design in my head before I started.
• I knew the tools and environment really well.
• I had all the equipment set up ready to roll.
• They were applications where the testing was trivial, as a run basically either did the right thing or didn't.

Cases like these are rare.

[dietert1]

In my experience it depends a lot on what you want to achieve. I can write a simple application within some days and it will work in the sense that it implements the basic process. It may be good enough to get things done in the lab. Here we are talking about a youtube hobby project.
Once you hand out/sell the application to some user, they will find unexpected errors and traps or there are new ideas and proposals. So it comes back and receives a rework. This can happen for years and years while the product lives. Who creates a serious embedded application for commercial reasons should think about how much work it may give and whether you are willing to do whatever it takes to make it a complete and perfect solution. In the end you may have to keep alive various versions of the product and debugging/testing will take much more time.

Regards, Dieter

[SiliconWizard]

and I think even most managers these days realize this.

Yeah, well, most may have realized it... but some still use this metric. Not because it's particularly relevant, but because it's very easy to use. And in many companies now, particularly the larger ones, managers are asked to use "KPIs" to monitor their teams's activity. So, LOCs/day (or /week, /month, whatever...) is an easy one to track.

KPIs are not that easy to properly select. It's often hard to quantify software development in a relevant way. But it's easy to define a few simple indicators, and keep track of them. Then you can show nice dashboards  to your upper management.

[NorthGuy]

KPIs are not that easy to properly select. It's often hard to quantify software development in a relevant way. But it's easy to define a few simple indicators, and keep track of them. Then you can show nice dashboards  to your upper management.

KPI? You just say: "Finish this by that time or you're fired".

[coppice]

and I think even most managers these days realize this.

Yeah, well, most may have realized it... but some still use this metric. Not because it's particularly relevant, but because it's very easy to use. And in many companies now, particularly the larger ones, managers are asked to use "KPIs" to monitor their teams's activity. So, LOCs/day (or /week, /month, whatever...) is an easy one to track.

KPIs are not that easy to properly select. It's often hard to quantify software development in a relevant way. But it's easy to define a few simple indicators, and keep track of them. Then you can show nice dashboards  to your upper management.

Management must have metrics. If it can't have meaningful ones, it will generally settle for utter garbage ones. Even ones which rate every actual improvement as a worsening of performance.

[SiliconWizard]

and I think even most managers these days realize this.

Yeah, well, most may have realized it... but some still use this metric. Not because it's particularly relevant, but because it's very easy to use. And in many companies now, particularly the larger ones, managers are asked to use "KPIs" to monitor their teams's activity. So, LOCs/day (or /week, /month, whatever...) is an easy one to track.

KPIs are not that easy to properly select. It's often hard to quantify software development in a relevant way. But it's easy to define a few simple indicators, and keep track of them. Then you can show nice dashboards  to your upper management.

Management must have metrics. If it can't have meaningful ones, it will generally settle for utter garbage ones. Even ones which rate every actual improvement as a worsening of performance.

Exactly.

[T3sl4co1l]

Worth noting whether this is merely an indicator for reference, or an actual performance metric.  I suspect not the latter, as it's a notoriously poor metric, and I think even most managers these days realize this.  But as you can see from the above, you can never be too careful, I guess...

FWIW, in a recent project, I did about 700 LoC in 23 hours, for a simple, self-contained project on a platform I'm comfortable with (no libraries besides libc, no networking/comms/APIs, etc.).

Tim

I've done a couple of things in the past where I turned out >1000 lines of code per day, but:

• These were applications I knew intimately. I had a full design in my head before I started.
• I knew the tools and environment really well.
• I had all the equipment set up ready to roll.
• They were applications where the testing was trivial, as a run basically either did the right thing or didn't.

Cases like these are rare.

Indeed, this exactly describes that project.

Tim

[ricko_uk]

Thank you all.

Yes this was more for me to get a feel for it. To have a personal reference for my own performance because I see that depending on the project it can vary quite a bit.

[Scrts]

KPIs are not that easy to properly select. It's often hard to quantify software development in a relevant way. But it's easy to define a few simple indicators, and keep track of them. Then you can show nice dashboards  to your upper management.

KPI? You just say: "Finish this by that time or you're fired".

Doesn't work this way. Engineer can say "Go f*** yourself, I quit" and you will spend the next month or two trying to find a new engineer, then 3 more months training and getting beat by the customer.

[MarkF]

Years ago I worked on a very large project where we bid 11 LOC/hr.
That includes coding, documentation, design reviews and testing.

In actuality, the design and testing phase required two years and 14 people.
We wrote approximately 750,000 lines of Fortran code.  You do the math...
That was 30 years ago and development tools are much different today.  ( i.e. there are some  )