Brain Versus Heart

Which is the more important, your brain or your heart? It's a stupid question, isn't it? You can't live without either one.

Which is more important, action or state? Broadly speaking, programming languages perform actions using executable code, and maintain state using variables. So which is more important? It's an equally stupid question, isn't it? You can't write software without either one.

Which is why OO languages like C++ and Java combine action and state into a single lexical component, the class, with some syntax and rules that force you, and the developers that maintain the code after you, to address both in tandem.

Can you do something similar in non-OO languages like C? You bet. If you implement the exact same functionality, the run-time overhead will be exactly the same in either language. But the developer-time overhead will be much greater in C because the developer is saddled with all the work that C++ will do automatically. Maybe that's okay.

Or maybe it's not. 


Reiterating what I wrote about recently, about two thirds of the life-cycle cost of a large code base is in its maintenance. Even if you could eliminate entirely the necessity of requirements, initial development, debugging, and testing, you would reduce your software development costs by only about a third. You'd still be saddled with corrective maintenance (fixing bugs), perfective maintenance (improving code, often for run-time performance or ease of developer-time maintenance), and adaptive maintenance (changing code to adapt to something that changed outside of the system, for example a new part because the prior one was discontinued by its manufacturer, or a new API for a system with which your code interfaces).

Old school organizations, like Bell Labs, and new fangled companies, like Google, have figured out that one way to reduce the long term costs of code bases is OO design and implementation. And part of that cost reduction is using a language that automates much of the cost reduction automatically. That's why both organizations, and lots of others, leverage the hell out of C++. 


That still doesn't make it easy. You can write crappy code in any language. It might even be easier to write crappy code in C++ than it is in C. So using C++ doesn't excuse the developer from knowing what they're doing. If anything, it increases the developer's responsibility not to be a dickhead. But in the long run, if developers know what they are doing, costs are reduced.

So it's about money. Hint: it's alway about money.

Again as I've said before, products that have a short life span, either by design or because they failed in the market place, won't face this issue. Only long term successful products will find themselves deep in the maintenance phase of their life cycle. 
Some organizations may find that they fail in the market place because their maintenance costs doom them. Their processes were not sustainable or scalable; they made short term cost reductions that inflated their long term costs with technical debt. And just like too much financial debt, it buried them.

Back in the 1970s, when I was getting paid for writing FORTRAN if you can believe it (because I am so old I am actually a brain in a jar connected up to wires and tubes), there was this new fangled idea called "structured programming". A lot of guys thought it would never catch on: the code was just too inefficient. But I liked it. Because, all on my own, through laborious trail and error, I had already discovered that writing something like structured code was the only way I could write code that I and others could understand, debug, and maintain. Languages like Pascal and C that supported structured programming were great because they automated what I was already doing by hand. 


In the 1980s, when I was getting paid for writing this new language called C, there was this new fangled idea called "objected orientation". A lot of guys thought it would never catch on: the code was too inefficient. But I liked it. Because, all on my own, through yet more painful learning experiences, I had already discovered that if I wrote header files that defined a structure and well-named functions that operated on that structure, it was the only way I could write code that I and others could understand, debug, and maintain. OO languages like C++, and later Java, were great because they automated what I was already doing by hand.

Which is why I'm a little surprised, here in the twenty-first century, that using OO and languages that support it for embedded development continues to be controversial.

I spent a good part of the late 1970s and early 1980s as a systems programmer writing code in assembler, for heaven's sake, for both IBM mainframes and PDP-11 minicomputers. Microcomputers made this problem even worse. I remember a colleague of mine once tiredly asking rhetorically "How many assembly languages do I have to learn before I win?" C was the higher-level structured assembly language we had all been waiting for, without knowing exactly what it would look like when we found it. I have no desire to go back to those bad old days.

The same emotion applies to my application of OO and C++ and other tools and techniques to embedded systems. I describe myself not as a software developer, but as a product developer, because the latter title describes better the full range of skills I bring to the table, the broadness of the work that I do in hardware-firmware-software debugging and integration, the range of talented technical folks with which I like to surround myself, and the issues that I worry about on a daily basis. For me to be successful as a product developer, I have to ship a product. And leveraging C++ in the embedded domain helps me do that.