Lines of code per day (in embedded systems)? - Page 1
Forum section: electronics / general

author: ricko_uk
author_rank: Super Contributor
timestamp: June 29, 2021, 01:26:46 am
content: 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 worldSo I am curious how many lines ofgood qualitycode per day do you write on average?That includes architecture design, coding, debugging, refactoring/polishing, documentation, extensive testing, etc...Thank you

author: WattsThat
author_rank: Frequent Contributor
timestamp: June 29, 2021, 01:49:30 am
content: 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.htmlScroll down to “what does firmware cost”. There are some interesting LOC metrics in there.

author: profdc9
author_rank: Frequent Contributor
timestamp: June 29, 2021, 02:02:07 am
content: 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.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 29, 2021, 02:16:55 am
content: 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

author: profdc9
author_rank: Frequent Contributor
timestamp: June 29, 2021, 02:36:48 am
content: 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.inoBut 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.

author: mazurov
author_rank: Frequent Contributor
timestamp: June 29, 2021, 02:39:26 am
content: I had a gig last year when Iremovedabout 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.

author: HwAoRrDk
author_rank: Super Contributor
timestamp: June 29, 2021, 02:53:02 am
content: 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".

author: NorthGuy
author_rank: Super Contributor
timestamp: June 29, 2021, 04:37:03 am
content: When I copy and paste pieces from previous projects, I can "write" a lot of code very quickly. Really.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 29, 2021, 09:27:33 am
content: Oh, remembered this article I saw last week:https://factorio.com/blog/post/fff-366Tl;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

author: MIS42N
author_rank: Frequent Contributor
timestamp: June 29, 2021, 11:38:24 am
content: 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 ...

author: Doctorandus_P
author_rank: Super Contributor
timestamp: June 29, 2021, 01:18:12 pm
content: 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.

author: madires
author_rank: Super Contributor
timestamp: June 29, 2021, 01:52:41 pm
content: 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.

author: Scrts
author_rank: Frequent Contributor
timestamp: June 29, 2021, 04:32:44 pm
content: Quote from: madires on June 29, 2021, 01:52:41 pmAgreed. 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 29, 2021, 04:56:20 pm
content: 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.

author: pardo-bsso
author_rank: Frequent Contributor
timestamp: June 29, 2021, 05:03:40 pm
content: Quote from: mazurov on June 29, 2021, 02:39:26 amExpressive 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 (likehttps://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.

author: coppice
author_rank: Super Contributor
timestamp: June 29, 2021, 05:07:36 pm
content: Quote from: T3sl4co1l on June 29, 2021, 02:16:55 amI'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.

author: dietert1
author_rank: Super Contributor
timestamp: June 29, 2021, 05:35:19 pm
content: 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 29, 2021, 06:47:31 pm
content: Quote from: T3sl4co1l on June 29, 2021, 02:16:55 amYeah, 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: June 29, 2021, 07:00:07 pm
content: Quote from: SiliconWizard on June 29, 2021, 06:47:31 pmKPI? You just say: "Finish this by that time or you're fired".

author: coppice
author_rank: Super Contributor
timestamp: June 29, 2021, 07:11:10 pm
content: Quote from: SiliconWizard on June 29, 2021, 06:47:31 pmManagement 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 29, 2021, 07:21:20 pm
content: Quote from: coppice on June 29, 2021, 07:11:10 pmExactly.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 29, 2021, 07:32:03 pm
content: Quote from: coppice on June 29, 2021, 05:07:36 pmIndeed, this exactly describes that project.Tim

author: ricko_uk
author_rank: Super Contributor
timestamp: June 29, 2021, 10:13:45 pm
content: 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.

author: Scrts
author_rank: Frequent Contributor
timestamp: June 30, 2021, 12:52:36 am
content: Quote from: NorthGuy on June 29, 2021, 07:00:07 pmDoesn'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.

author: MarkF
author_rank: Super Contributor
timestamp: June 30, 2021, 01:40:35 am
content: 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)

author: dietert1
author_rank: Super Contributor
timestamp: June 30, 2021, 06:20:17 am
content: 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

author: Siwastaja
author_rank: Super Contributor
timestamp: June 30, 2021, 10:59:04 am
content: 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.

author: apurvdate
author_rank: Contributor
timestamp: June 30, 2021, 11:34:30 am
content: 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..

author: rstofer
author_rank: Super Contributor
timestamp: June 30, 2021, 04:00:45 pm
content: 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.

author: ajb
author_rank: Super Contributor
timestamp: June 30, 2021, 07:51:17 pm
content: Quote from: rstofer on June 30, 2021, 04:00:45 pmYes, 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.Quote from: T3sl4co1l on June 29, 2021, 09:27:33 amGames might be one of the best examples of when a strategy that Pragmatic Programming callstracer bullet developmentmakes 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.

author: esepecesito
author_rank: Regular Contributor
timestamp: June 30, 2021, 08:21:25 pm
content: 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)

author: esepecesito
author_rank: Regular Contributor
timestamp: June 30, 2021, 08:25:04 pm
content: Quote from: SiliconWizard on June 29, 2021, 06:47:31 pmI 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...

author: SteveyG
author_rank: Unknown
timestamp: June 30, 2021, 08:29:21 pm
content: 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.

author: viperidae
author_rank: Frequent Contributor
timestamp: July 01, 2021, 06:36:45 am
content: 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.

author: coppice
author_rank: Super Contributor
timestamp: July 01, 2021, 12:55:58 pm
content: Quote from: viperidae on July 01, 2021, 06:36:45 amI 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.

author: emece67
author_rank: Frequent Contributor
timestamp: July 01, 2021, 04:26:01 pm
content: .

author: Doctorandus_P
author_rank: Super Contributor
timestamp: July 11, 2021, 10:19:16 pm
content: 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.