The Failure of Reuse
Jack Ganssle is an author, consultant, and software developer who focuses on embedded software. He’s got an e-newsletter called The Embedded Muse I’ve been subscribed to for years, even though I haven’t done embedded development for quite some time, because he has great insight into software development in general. He also talks about other related topics, like dealing with customers, dealing with coworkers, dealing with change, etc.
His most recent issue[0][1] talks about the failure of software reuse, especially in the embedded world. Not that reuse isn’t great, but that we’re simply not doing it.
Reuse is the holy grail of software engineering, one that is so entrenched in our belief system no one dares to question its virtue. The quest for reusable components is one of the foundations of object oriented programming and all of the tools and languages that OOP has spawned.
Yet, my observations suggest that at least in the embedded space reuse has been a dismal failure.
…Reuse is hard. It’s like a savings account. My kids complain that if they stick a few bucks in the bank then that’s money they can’t use. and it’s just a piddling sum anyway. Sure. The value of savings comes after making regular deposits. Ditto for reuse. The cost is all up-front, the benefits come from withdrawals made in later years.
If you like this issue, the back issues are available on his website.
Footnotes:
- At the time I’m writing this, the article I linked to is not actually there, but should be in a few days. I just followed his naming convention to figure out what it will be named.
- Yes, I start numbering footnotes at zero. It’s a C thing. That’s how I roll. And it was fun figuring out how to do it in CSS.
Reuse is something of a bogon, I think.
Don’t get me wrong, there are important ideas which can appear to be re-use. Normalization, for example, and retention of knowledge.
But there are other important things to avoid which can also appear to be re-use. Cruft, for example, and dead code.
Since embedded systems have much lower tolerances for cruft than desktop systems, it’s easy to imagine that these priorities would result in “non-reuse”. But if that’s a failure, it’s a failure of something that should fail.
Of course, it’s possible to go overboard in the other direction, but Charles Moore for example got quite a bit of mileage from his practice of writing each of his applications quite literally from scratch and avoiding irrelevant generalities.
I think that the important thing to re-use is not code but interfaces. You need good (relevant, simple, clean, to-the-point) interfaces when you have teams of people working with each other. You can independently swap out the code on both sides of an interface if your interface is appropriate.
That, and data. Data re-use is important, and it’s important that we have stable interfaces that let us get at our data.
But code? The importance of reusable code is easy to overstate.
Comment by rdm | October 29, 2008
rdm has some good points, but it’s hard to write clean, efficient code. When you can do so and reuse it, you actually reduce cruft. Of course that’s if (1) You give a damn enough to do it right, and are supported in doing so by your company, and (2) you package your finely-tuned code in small enough libraries that you’re not including something of emacs-sized proportions each time
Data is an interesting point. I started a company (http://www.agilerules.com/) with a few others a while ago that specialized in Agile coaching, consulting, evangelizing, and readiness assessments. One of our niche markets was Agile in the embedded world. Towards that end, I developed a tool (http://www.agilerules.com/projects/catsrunner/index.phtml) that could be used for unit testing on an embedded board via the gdb debugger on the host computer.
The three big selling points were (1) Generating pass/fail reports is easy, because it happens on the host computer, (2) The tests to run are controlled by the host, so they’re not taking up space on the board, and it’s easy to change, and (3) the test data is also supplied by the host, so it’s also easy to change and not taking up space.
Comment by David | October 29, 2008