Software is cheap -

Software is cheap

Click here for reader response to this article

Firmware is the most expensive thing in the universe.

In his book “Augustine's Laws,” Norman Augustine, former Lockheed Martin CEO, tells a revealing story about a problem encountered by the defense community. A high-performance fighter aircraft is a delicate balance of conflicting needs: fuel range vs. performance, speed vs. weight. It seems that by the late '70s fighters were at about as heavy as they'd ever be. Contractors, always pursuing larger profits, looked in vain for something they could add that cost a lot but weigh nothing.

The answer: firmware. Infinite cost, zero mass. Avionics now accounts for more than half of a fighter's cost. That's a chunk of change when you consider the latest American fighter, the F-22, costs a cool $257m a pop. Augustine practically chortles with glee when he relates this story.

But why is software so expensive? Tom DeMarco once answered this question with these three words: compared with what? He went on to discuss relatively boring business cases, but that answer has resonated in my mind for years.

Compared with what? Using software we routinely create product behaviors of unprecedented complexity. Sure, the code's expensive. But never in the history of civilization has anyone built anything so intricate.

Consider the following bubble sort, lifted shamelessly from Wikipedia and not checked for accuracy:

void bubblesort(int * A, int n){    for(int i(0); i < n;="" ++i)="" for(int="" j(0);="" j="">< n="" -="" i="" -="" 1;="" ++j)="" if(a[j]=""> A[j + 1])                std::swap(A[j], A[j + 1]);}

It's a mere 110 non-space characters, perhaps tossed off in an hour or two. Suppose we didn't have software and had to implement a sort using some other strategy. What would it cost?

A mechanical engineer might boast that his profession built sorters long before computers. Consider IBM's 1949-era model 82 card sorter with a throughput of 650 cards per minute, rather less than our code snippet might manage even on a 4MHz Z80. The model 82, of course, only sorted one column of a card at a time; to completely sort a deck could take dozens of passes.

How long did it take to design and build this beast? Years, no doubt. And its functionality pales compared with our code, which is so much faster and can handle gigantic datasets.

But that was 1949. How long would it take to build a bubble sort from electronic components–without FPGAs and VHDL, today's software-like solution to hardware problems?

Every time I start to sketch out a circuit I'm sorely tempted to plop in a CPU. It's the natural solution, but breaks the rules of this game.

In an hour I managed a rough block diagram, one above the chip level (blocks have names like “adder” and “16-bit latch”). But the sequencing logic is clearly pretty messy so I've just tossed in a PLD, assuming at some point it wouldn't be too hard to write the appropriate equations. And, yes, perhaps that breaks the no-programmable-logic rule, but to design and debug all that logic using gates in any reasonable amount of time is as unlikely as buck-a-gallon gas.

Assuming 16-bit words and addresses, the circuit will need around a dozen 16-bit latches, adders, and the like. Plus memory. And I have no idea how the unsorted data arrives into the RAM or how the results get exported. Those are unspecified design requirements. The software-only solution naturally resolves these requirements just by the act of writing the function prototype.

Translating the rough block diagram to a schematic might take a day. Then there's the time to design and produce a PCB, order and load parts (and change the design to deal with the unexpected but inevitable end-of-life issues), and then of course make the circuit work. We could be talking weeks of effort and a lot of money for the board, parts, and appropriate test equipment.

All this to replace seven little lines of code. Few real embedded programs are less than 10,000; many exceed a million. How much hardware and how much engineering would be needed to replace a real, super-sized computer program?

Firmware is the most expensive thing in the universe, but only because of the unimaginable complexity of the problems it solves. But it's vastly cheaper than any alternative. So when your boss irritably asks why the software takes so long, you know what to say.

Compared with what?

Jack G. Ganssle is a lecturer and consultant on embedded development issues. He's running a seminar teaching developers how to create better firmware faster in Baltimore and Austin in April. Contact him at . His website is .

Reader Response

I couldn't agree more. There is a point I would like to add. Software has been made it easy to produce and easy to deliver. It has varying ranges of success based on varying levels of expertise.

– Mark Hurley

So when your boss irritably asks why the software takes so long, you know what to say.

I suppose in comparision to the time it took for the schematic, artwork and the PCB. Comparing apples and oranges.

So, since when do bosses ask sensible questions?

– kalpak dabir

Though I completely agree that building an efficient and robust software involves good amount of work but I do not completely agree with author's line of reasoning. There is a natural advancement of technology and it has to be considered too. Through software, we have just developed a better way of building & implementing systems. A better method, perhaps, to reason costs is to differentiate between a poorly written piece of code with well thought out, carefully developed code.

– Harish

Not -only- easy to produce and easy to deliver… but easy to CHANGE. Especially when you get to integration and an errata sheet comes down the line -after- you've committed the hardware to… well, hardware!

So who does the boss turn to? Ahhhh! The software folks?

And who better than to fix the timing problems in the hardware? The firmware geeks!

And I'm proud to admit I'm one of them!

– Theresa Beizer

easy to write code.

very difficult to write good code.

– Bindu Madhavan

Well, I was thinking about this and my experience working for a company that worked in the formal hardware synthesis area.

One of our standard designs was a fibonacci number generator, which was expressed in as a behavioral model and synthesized into a FPGA circuit.

While I agree with the point about complexity vs. cost benefits of software over hardware solutions, I was thinking about the example you gave and comparing C code development vs. designing hardware by hand (paper/pencil).

I wonder how hard it would be to express bubble sort in behavioral VHDL/Verilog/HardwareC and having the hardware (especially the control section) be synthesized by a hardware compiler.

I suspect that the design process is similar to C (i.e. edit, test the model), but that the result would actually run pretty fast. Of course, you'll still end up with a bunch of gates for an equiv. circuit (i.e. can handle signed 32bit numbers, DMA to memory arrays if arbitrary size, etc…).

Anyone with a EDA synthesis tool want to give it a try. I'd be interested to see how complex the circuitry was (FPGA gates) and how much a FPGA would compare to a uC in price vs. performance.


– Ingo Cyliax

Cheap can also be interpreted as unimportant.

When reality hit. (Recall bugs). It is not likely that the budget gets better.

I am not convinced that the view of software as something cheap is always helpful.

– Martin

bayazetI came to hate words: “So! How're we doing?” Those words usually were precursors of nasty screeming and names calling from my idiot boss. And I seemed never to be able to work fast enough to avoid those his monologs on how unworthy I was. Whatever I did took “… too long”. My application outlived my stay in the company: I just went on the web site I built – it's still there, kicking.

– bayazet

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.