Joined
·
1,201 Posts
More Software Code in Chevrolet Volt than Boeing 787
1 - 20 of 20 Posts
Don't get me wrong, I think that the Volt is the coolest car in the world, but I find it very hard to believe that its complexity is even in the same order of magnitude as the 787. I tried to follow the link to the source of the 10/8 MLOC comparisons, but it was a dead end.
I can only speculate that they considered only a few systems on the 787 and did not consider code that has instances running in multiple processors. There are hundreds (maybe more than a thousand) of microcontrollers and microprocessors on board the 787. I know, because I helped to design some of them. The "more electric" architecture means that there are motor controllers not just for the main engine starter/generators, but for electric-powered hydraulics, air conditioning, fuel pumps, cabin pressurization, and other systems. There is a multi-redundant central computer with data busses linking everything from avionics to remote electric power distribution and data concentration. And then there are the computers and networks for aircraft maintenance and for cabin entertainment.
The point is that they are both amazing products, but I'd like to see a more factual comparison between them.
I can only speculate that they considered only a few systems on the 787 and did not consider code that has instances running in multiple processors. There are hundreds (maybe more than a thousand) of microcontrollers and microprocessors on board the 787. I know, because I helped to design some of them. The "more electric" architecture means that there are motor controllers not just for the main engine starter/generators, but for electric-powered hydraulics, air conditioning, fuel pumps, cabin pressurization, and other systems. There is a multi-redundant central computer with data busses linking everything from avionics to remote electric power distribution and data concentration. And then there are the computers and networks for aircraft maintenance and for cabin entertainment.
The point is that they are both amazing products, but I'd like to see a more factual comparison between them.
<RANT>Memory is cheaper than programmers .
BUT for off the ground electronics it might be worth having less parts and smaller code.
OR a better Optimizing compiler
Stop it. This is one of my buttons. Y'all shouldn't have pushed it.
1) LOC is a crappy metric. How can I be so sure? Answer this question: is it better or worse to have more LOC?
2) LOC is far too local of a metric to make sense to use to compare ANYTHING, let alone vastly different products in vastly different domains with vastly different teams. The only aspect of them that is comparable is that they're both integers, but that tricks you into thinking that there is an ordering, and people will want to think that it's a total ordering at that. Poppycock.
3) Even in the local case, LOC is a misleading metric. It's a meta-measure, at best, and even then its hard to compare as a concrete thing within a team. For example, how many LOC is "dragging an icon of a push button onto a canvas" worth when that is the way UIs are created? The UI-laden aspect of a program is now incomparable to the algorithm-laden aspect. Wow, what a great metric.
Personally, it frightens me that there is this much code in EITHER product, knowing what I know about the state of software development on this planet. Further, given that anyone who tosses these numbers around as if they're meaningful is clueless and I'm setting their bozo bit. Stop wasting my time.
</RANT>
Wow. I feel better now that that's off my chest. I'm going to have a beer and relax.
Joined
·
1,230 Posts
That's funny!!
Joined
·
309 Posts
Here's the "Drive for Innovation" detailed technical presentation given by the company that reverse engineered the Chevy Volt, where the analogy to the Boeing 787 was made.
Article: http://www.driveforinnovation.com/volt-teardown-the-battery-pack/
Part 1: http://www.driveforinnovation.com/volt-teardown-video-excerpts-from-design-west/
Part 2: http://www.driveforinnovation.com/volt-teardown-powertrain-presentation-at-design-west-3214/
Part 3: http://www.driveforinnovation.com/teardown/infotainment-teardown/
Article: http://www.driveforinnovation.com/volt-teardown-the-battery-pack/
Part 1: http://www.driveforinnovation.com/volt-teardown-video-excerpts-from-design-west/
Part 2: http://www.driveforinnovation.com/volt-teardown-powertrain-presentation-at-design-west-3214/
Part 3: http://www.driveforinnovation.com/teardown/infotainment-teardown/
Joined
·
1,201 Posts
I agree. I worked for Bill for almost a decade and yes, having tons of excess code either means your software may be too complex or it may be inefficient.
All I know is after I've written 1000 lines of code, I usually find later that it should have been 1099 to do it right. When I write 1100, sometimes there's an extra line that screws it all up. Glad what I write doesn't run something as important as a car, or we'd all be doomed.
Joined
·
1,480 Posts
Yet Boeing didn't have a TMS like we do...hmmm.
As the CEO of a software/systems/product development company, we NEVER judged by lines of code - in fact, we gave props for getting a certain function done in less, hopefully a lot less than any competitor. Made maintenance a lot easier for one thing, but the main deal was the customer (who was actually going to churn out product in large quantities) could then use a less expensive processor - a lot less expensive, and that really adds up over million lots. If I can get the job done in a PIC uP running 10 mhz instruction rate (sometimes with only half a kbyte of ram and 8-16 of rom), vs some atom/arm/younameit super power chip, I do.
And they are far more reliable to boot (pun intended).
Whereas nowadays, people start learning on machines that have to already have linux, or some other big opsys on them already. This means they don't learn how to write efficient code (or know how to do drivers), because a machine powerful enough to run a major opsys doesn't notice their waste very much. After a generation (there have been two since I've been in the biz), it's really the blind leading the blind anymore.
Why use even a raspberry pi when a PIC will do? Lazy? Ignorance that cheaper things exist? Or just too unskilled to hook up 5v and 5 wires for in-circuit programming? Dunno, but it all seems pretty bourgeois to me these days.
More lines of code means more bugs, usually means it was written without enough design foresight, and it's harder to make changes in more often than not, without breaking something else. Keep it simple!
As the CEO of a software/systems/product development company, we NEVER judged by lines of code - in fact, we gave props for getting a certain function done in less, hopefully a lot less than any competitor. Made maintenance a lot easier for one thing, but the main deal was the customer (who was actually going to churn out product in large quantities) could then use a less expensive processor - a lot less expensive, and that really adds up over million lots. If I can get the job done in a PIC uP running 10 mhz instruction rate (sometimes with only half a kbyte of ram and 8-16 of rom), vs some atom/arm/younameit super power chip, I do.
And they are far more reliable to boot (pun intended).
Whereas nowadays, people start learning on machines that have to already have linux, or some other big opsys on them already. This means they don't learn how to write efficient code (or know how to do drivers), because a machine powerful enough to run a major opsys doesn't notice their waste very much. After a generation (there have been two since I've been in the biz), it's really the blind leading the blind anymore.
Why use even a raspberry pi when a PIC will do? Lazy? Ignorance that cheaper things exist? Or just too unskilled to hook up 5v and 5 wires for in-circuit programming? Dunno, but it all seems pretty bourgeois to me these days.
More lines of code means more bugs, usually means it was written without enough design foresight, and it's harder to make changes in more often than not, without breaking something else. Keep it simple!
Joined
·
1,126 Posts
I don't buy that the Volt contains 10M lines of code. Its complex, but not that complex. That could only be achieved if you include all kinds of bloated library packages, which is technically not part of the guts of the Volt. Much of it is just repurposed from generic cars (e.g. the body control module). If you would count the lines of code that the Volt actually executes during a normal drive, it can likely be done in less than 500K lines.
Other commenters are right that the LOC metric is only a very vaque metric of complexity. Good code is compact. Bloated code is always a symptom of a problem. Often its a management and system integration issue. The most difficult problem generally do not result in much code.
Other commenters are right that the LOC metric is only a very vaque metric of complexity. Good code is compact. Bloated code is always a symptom of a problem. Often its a management and system integration issue. The most difficult problem generally do not result in much code.
Joined
·
1,480 Posts
The Volt code probably has considerable bloat due to a bunch of different teams in different parts of the planet doing it. This no doubt increased GM's cost TONS, because to do things that way, you have to write all sorts of excessive interface specs, with the hope that you've addressed every issue upfront, since those are hard to change without breaking things.
If they'd done it like we did it - everyone would be working in the same building at least, and could solve "unexpected" issues a lot faster by just walking down the hall - or hollering around the room. Get a little team spirit/oneupmanship going on and everything gets a lot tighter, faster, and better.
GM was true to the GPL and actually did publish online the changes they made to the GPL code they used - and on inspection, what they did was take things OUT and make them tighter, at least there.
If they'd done it like we did it - everyone would be working in the same building at least, and could solve "unexpected" issues a lot faster by just walking down the hall - or hollering around the room. Get a little team spirit/oneupmanship going on and everything gets a lot tighter, faster, and better.
GM was true to the GPL and actually did publish online the changes they made to the GPL code they used - and on inspection, what they did was take things OUT and make them tighter, at least there.
I started to write a long reply the other day, but didn't finish/post it. Much of the Volt's code was automatically generated (computers programming other computers - start of the apocalypse? )
http://gm-volt.com/2011/05/11/ibm-highlights-its-help-with-the-chevrolet-volts-development/
In aerospace, on the other hand, most things are still hand coded, and extensively peer reviewed because a failure is likely to kill people. Code generators are an effective solution, providing more code for fewer man hours, but the resulting code is generally not as efficient (as in, requires more lines to accomplish the same tasks) as well designed hand coding.
It was a sensible choice for GM, but it also makes the comparison misleading.
)http://gm-volt.com/2011/05/11/ibm-highlights-its-help-with-the-chevrolet-volts-development/
In aerospace, on the other hand, most things are still hand coded, and extensively peer reviewed because a failure is likely to kill people. Code generators are an effective solution, providing more code for fewer man hours, but the resulting code is generally not as efficient (as in, requires more lines to accomplish the same tasks) as well designed hand coding.
It was a sensible choice for GM, but it also makes the comparison misleading.
Joined
·
3,527 Posts
Do comments count? I once rewrote an excessively long and memory-intensive calculation in a DOS* program that was hitting the memory limit. Because the original calculation was written to spec I wrote a lengthy explanation of why the replacement was equivalent. The end result was the same number of lines.
Lines of code may say something about the effort but it doesn't say much about the results.
* Oh crap, it was over 16 years ago.
Lines of code may say something about the effort but it doesn't say much about the results.
* Oh crap, it was over 16 years ago.
Let's ignore the center console for the moment, because almost all cars have those now.
How complex can the "battery/electric" code be? It has to manage when to turn on the ICE, how to manage regen, TMS, charge management, and a few other things. I wonder if it is more complex than a printer driver, which has to manage a ton of different kinds of renderings, ink management, etc.?
The concept that the Volt software is even an order of magnitude as complex as a modern airliner just doesn't make sense to me.
How complex can the "battery/electric" code be? It has to manage when to turn on the ICE, how to manage regen, TMS, charge management, and a few other things. I wonder if it is more complex than a printer driver, which has to manage a ton of different kinds of renderings, ink management, etc.?
The concept that the Volt software is even an order of magnitude as complex as a modern airliner just doesn't make sense to me.
When we changed from the slower mini computers to the faster micro we has to re-write some code to get it STOP as it was running so fast it would fly right by the stop instruction.
10 stop
20 stop
30 goto 10
40 end ; just in case
Years ago it was how many miles of wire and lbs of lead-tin and the tube count.
10 stop
20 stop
30 goto 10
40 end ; just in case
Years ago it was how many miles of wire and lbs of lead-tin and the tube count.
1 - 20 of 20 Posts
