Lines of code per day (in embedded systems)?

[dietert1]

The number i get from the example above was 53760 h total, and 14 LOC/h.
Yes, if somebody does 1000 lines on a single day and he does that once per month, you divide 1000 by 160 hours per month and arrive at 7 LOC/h. Certainly he will do something useful on the other 19 days, so the average can be twice as much.

Regards, Dieter

[Siwastaja]

My largest MCU project I developed alone was finally approx. 25k lines (on Cortex-M7; binary is 85k) and developed actively for some 9 months (half of which approximately full-time with no other tasks related to the project) and less actively maintained for another 9 months; this was a project involving several controls such as
* BLDC FOC motor control
* Inertial measurement (gyro, accelerometer, compass) collection from several sensors,
* Wheel odometry + IMU sensor fusion thing with simple motion planning ("go to coordinates x,y")
* Control for custom 3D time of flight camera system, imaging of ten(!) 3DTOF CCD sensors,
* Image processing for lens flare compensation, and finally, dealiasing and depth map calculation based on phase shift images
* Some autonomous logic like "detect the optical marker and drive to charging station" or "obstacle on the way, stop before hitting", later of which also involves sensor fusion for point cloud generation
* Software-defined DC/DC control for a 500W two-phase synchronous buck converter aka battery charger
* Communication and a lot of auxiliary functions like audio beeping, battery management, each simple and small on their own but add up

(The reason I listed what it does is to kind of prove those 25klines are needed. Yes, maybe it could be squeezed into 15klines but the point is, this amount of code is not due to boilerplate or spaghetti copypasta typical to beginners like myself 20 years earlier.)

25klines over 9 months is 92 lines per day or approx. 15 LOC/h. And yes, this is too much. This code base didn't end up total disaster, and it's totally workable, but it's not nearly as good as I wanted it to be. For robust and responsible development, halve that rate; and get enough engineers to share the tasks so that one can focus on the firmware, another in higher-level software, yet another in UI...

For each line of code in the final product, you could say approximately 16 lines are originally written by the programmer:
* 8 (50%) deleted by simply hitting delete and backspace while you try to think what to write before even testing the code
* 4 (50%) deleted during test & verification even before committing into version control
* 2 (50%) deleted by later commits
* 1 (50%) deleted when finally doing a rewrite or refactor of some parts. Here the granularity is larger; maybe a complete "module set" of 10k lines disappears, but another 10k lines unit is kept as-is.

[apurvdate]

Last year I worked on PIC18F. It was my first time working with any kind of PIC. Instead of using any code configurator or libraries, I jumped to datasheet for register information & had produced a basic code for I2C & UART in 3 days. Application was to read sensor data over I2C & send it to another master controller over UART.

Obviously we faced some issue, and I spent 4 more days debugging what was wrong in my code (as I was apprehensive because my first go at PIC), only to realize later that the master controller to which my PIC was supposed to communicate to was configured wrongly by another team  .

All in all I spent first 3 days writing 100 lines.. adding and removing 15 lines daily for next 4 days.. and still remaining at base 100 lines at end of the week..

[rstofer]

The number of LOC per day is going to vary all over the map.

https://successfulsoftware.net/2017/02/10/how-much-code-can-a-coder-code/

The bigger the project gets the harder it is to write additional code.  Adding features can be a real challenge.

Writing the code is easy, designing what the code should do is hard.  That's why there is a difference in pay scale for programmers versus system design engineers.

I guess I would be optimistic for small projects and assume 100 LOC written, debugged and documented per 8 hour day.  That can be truly optimistic if you have no experience with the device and have to struggle through the datasheet for every single detail.  If you're learning while writing, I would cut the figure to, perhaps, 10 lines per day.

Comment lines count because they should be part of the documentation phase.  Correct comments tend to be rare after the second programmer touches the code.

It's even worse if you don't have a finalized hardware design.  It's kind of like nailing Jello to the wall.

[ajb]

Writing the code is easy, designing what the code should do is hard.  That's why there is a difference in pay scale for programmers versus system design engineers.

Yes, and while in theory you could come up with a complete set of specifications ahead of time and create state diagrams and define behavior sequences and error conditions etc etc to the point where writing the actual code becomes as close to pure data entry (or I guess transcription as possible), in practice the amount of design that can practically be put into an application before coding starts varies between zero and "some".  Really, almost no system that is expected to be maintained over years can be fully designed up front, because if the active lifespan of the project is long enough inevitably there will be some external change that requires new functionality or a shift in existing functionality, so a certain amount of redesign is inevitable. 

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

Games might be one of the best examples of when a strategy that Pragmatic Programming calls tracer bullet development makes sense.  Games are inherently meant to be novel, unique experiences, and the experience is shaped by a pretty complex set of interactions between the user, game logic, visual and audio design, rendering systems, etc, and it can be incredibly difficult to anticipate enough of that whole mess to be able to design the framework for it ahead of time.  Once you add real live players to the mix things the way the game fundamentally works can change, and it may turn out that a substantial chunk of the design was faulty.  So it's important to close the feedback loop as quickly as possible around the whole system, which is why games always involve play testing and increasingly (esp with more indie development and digital publishing) open betas or early access programs.  It simply doesn't make sense to start the development process with a big heavy design phase, because you do not have all of the information you need for a full design, and even if you end up needing to rip out and replace huge chunks later on because of that, it's still overall the more efficient way to get the application done. 

Many non-game projects may be like that as well, especially ones that rely a lot on user interaction, and ones that are relatively novel.  We spent a lot of time going back and forth with users on one of our bigger embedded projects because the whole point of it was to make it easier for them to do complicated things quickly in a way that was entirely new in the industry, so there was a lot of time spent understanding how different ways of presenting control options would affect the user's workflow.  It was kind of a rough development process as a result of that, with a lot of ripping out and rewriting core parts of the functionality, but ultimately it got the thing done a lot faster than if we had fully designed a solution in the first place and developed it out before discovering that we'd made faulty assumptions or overlooked something critical.

Of course none of that is an excuse for writing bad tightly coupled spaghetti code--you should still make an effort to write good code no matter what the development strategy is--but it does make the overall throughput on the project a lot harder to predict ahead of time, and thus it's harder to hold to a consistent metric like LOC/day.

[esepecesito]

Proper documented, with all needed safety procedures ISO26262 and ASPICE, with SAFe Planning, according to PMI/PMO procedures, in a big (automotive) company following CMMI, about 1 line per day. Tops! If you are "the productive"guy.

Average good code without burocracy (but clean and *well* documented), maybe start one year with a project, and at the end of the year you can have somewhere between 1000 and 5000 lines. (Including the fact, each line you write from Jan 1st. will have to be debugged, refactor and changed for maintenance in the next 365 days)

[esepecesito]

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.

I firmly believe ANY KPI used publicly (I mean, you know what is being measured) will be manipulated in no more than 6 month. LOC is trivial to mess with. Just add comments, and if they don't count, just split the code all you can.
By the way the worst coda I've ever seen, was driven by such a stupid KPI...

[SteveyG]

Depends on too many factors. Is the software architecture and spec already created? In a professional environment, usually the code writing is the easy bit and you shouldn't be making any decisions on-the-fly. Some organisations work differently, but that leads to problems, especially where you are working to a specific standard.

[viperidae]

I write system software for a living and spent 8 hours today "writing code".
I've ended up with fewer lines of code than when I started.

[coppice]

I write system software for a living and spent 8 hours today "writing code".
I've ended up with fewer lines of code than when I started.

I used to know a couple of people whose main activity was enhancing Unix systems from a certain vendor on a contract basis. They said most of their work was taking a large chunk of code, figuring out what it did, realising its functionality was actually quite trivial, then writing a new short piece of code to do the same job. From there, adding the required enhancements was usually a simple task. So they produced the required result quickly, and with the code being small and easy to understand it was more maintainable, but their productivity measured in KLOCs was massively negative.

I have done several things where I had to take something that wouldn't fit - the code was too big, the data was too big, or the key loop in the code couldn't keep up - and spent considerable time getting the code into a working state while having roughly the same number of KLOCs or less than when I started. Again, a big improvement for everyone (except the competition), but zero to negative productivity measured in KLOCs. I've also done some things similar to the Unix case, starting with a tangled mess that nobody would work on, as it kept breaking when anyone touched it. I kept working on the code until is was considerably smaller, faster, much simpler, a decent platform for future enhancement, and actually fit, Again, a big benefit for everyone, but a massively negative productivity measured in KLOCs.

I actually think KLOCs can be a useful measure of productivity, but only within small teams. There the true meaning of the number of lines of code at the start and end of an activity can be meaningfully assessed. There a cleanup activity can actually be praised based on its number of KLOCs reduced per working hour.

[emece67]

.

[Doctorandus_P]

Me too.

I've several times encountered unreadable spagetti code which was buggy and needed cleanup.
You spend a lot of time trying to understand what the details are of what it's supposed to do, then refactor it and end up with a few clean and easy to understand functions that use less lines.

Writing code is not a linear process.