A very eloquent argument in support of Software Reuse

In The Matter Of Component Architecture

I had sort of a revelation this afternoon when I think I finally figured what it was that I knew was a missing piece and the explanation.

And it also came to me as to why we have such a horrible problem with software reliability. Let me ask you to take a moment and consider how you started this morning.

Most likely, you crawled out of your cave, went down to the stream to bathe in the ice-cold water, came back and pulled the wheat out of the ground, stripped the chaff, then used either a mortar and pestle or a grindstone to make flour, then pulled some yeast from the pot to mix with it to make bread, then chopped wood, then used the wood to build a fire and baked the bread, then ground peanuts in the same mortar to make peanut butter, then spread it across the bread and ate it, because by now it was lunch, no?

No, most likely you got out of a bed, got up and took a hot shower in your indoor bathroom, poured boxed cereal into a bowl or made breakfast from materials you bought in a store, then cooked it on a range, or went to a restaurant and bought something to eat, then went on to work, and probably in this entire time you did nothing more strenuous than pick up the morning paper.

Also, you did not mine the ore for your utensils or forge the steel for them, nor did you build the automobile you drove to work. Or a thousand other things you used today if you don't drive. You used items someone else made. And they used things other people made for them to make those things.

So what and how does what I just said have anything to do with the idea of a means to reduce or eliminate software failure? Because we do not do the same thing in the virtual space of software that we do in the real world.

Every time you use something manufactured, you use a component. A system as it were, an object. That component or object is itself built out of other components, or subsystems, which are operated upon by various other objects through various events. Let me give a simple example.

Using our hypothetical peanut butter sandwich from earlier in this article, no, on second thought we'll make it a peanut butter and jelly sandwich, we have an object which has three components or subsystems, the bread object, the peanut butter object, and the jelly object, which are manipulated by the hand and knife objects via the spread event.

Now you may start to see what I'm talking about here. All of the things we do or work with are generally made by combining other components either to produce an object or are used standalone (as when someone eats a sandwich which is finished or was made by someone else). We generally do not build everything from scratch.

But when was the last time you saw this sort of obvious acceptance of previously built components in the software development field? Okay, we will use an operating system and a compiler. That's about it; people will look at you askance if you talk about code reuse and designing applications to be built out of modular pieces and possibly completely built out of components designed by someone else.

For some reason it's perfectly acceptable for a trucking company to build an accounts receivable application from scratch but nobody in their right mind would expect them to build their own trucks.

If you're remodeling a kitchen the nearest Home Depot, Lowes, or a thousand places on the Internet will sell you any of several thousand designs to match your taste, decor and budget. That even though you are constructing a space you can buy all the components pre-built and while some people might be willing to pay extra for custom-built kitchens (and most people won't because the pre-built stuff is absolutely fine for all but the most unusual cases), but even at that nobody makes their own stove, refrigerator or sink.

Go out to a typical shop in a data processing organization and they'll look at you funny as they peer out over the landscape of trees they plan to mill for the cabinets, and the stocks of steel and copper tubing they have to build the gas powered refrigerators, and the enamel painting shop they plan to use to bake the finish onto the custom-built coal-fired stove they'll provide you with, to give a mismatched comparison.

They also can't estimate how long it will take to build the equipment, they don't know what it will cost, and as for warranty protection that the stove won't explode when it's used, a promise that the cabinets will support the weight of the dishes and groceries you want to put in them, and guarantees that the refrigerator will start when you plug it in and won't catch fire, or will even keep food cold, they'll think you're crazy if you want it anything but "as is."

Does this make any sense?

And we as software practitioners have been getting away with this sort of racket for decades.

The Sears Department stores of K-Mart Corporation will sell you an adjustable wrench that not only has a guarantee that it will do what it is intended for, and is guaranteed against defects in materials and workmanship, they will even replace it if you broke it because you damaged it on purpose. Forever. And their Craftsman brand is competitively priced against tools from competitors. I do note that their more complicated appliances don't have this strong a warranty, but in any case they do have one on everything they sell.

If you order even the simplest piece of software from anyone they can't even give you the minimum under the Moss-Magnuson Warranty Act: that the product is fit for use for the purpose it is intended to be used. The reasons for this are many, but come down to two things.

Software has neither architectural integrity nor engineering discipline. You buy a house and have knowledge that it was built according to detailed blueprints which an architect knows if it is built according to the specification that it has the characteristics to support the structure. You remodel a kitchen and have knowledge that the cabinets were built according to good engineering practices to support the usual and customary weights and stresses dealing with household goods used in kitchens.

Software developers will promise neither of these in even the simplest pieces of software. Neither will there be a promise of architectural correctness nor even engineering integrity. They can't because they don't have a way to determine what the load factors or stresses on the software are. It's all built by hand, on an ad-hoc basis, usually without any formal disciplines being used, with all new materials milled from scratch. Very little if any predeveloped components are used.

One of the greatest improvements in programmer productivity was the move from using wire boards and toggle switches to being able to write programs in source code, typically assembler. The next boost was the development of third-generation programming languages such as Fortran, C, Cobol, Basic, Pascal and six thousand others. And I think the next boost was the implementation of object orientation. Of the use of components to build software out of previously constructed pieces. Despite the capacity being there, it's rarely used.

If you have small components that you know are right, and you then combine those components to manipulate each other according to their published interface specifications, the results should be consistently correct. The results will be predictable, the usage will be consistent every time. But in general, this is not how we are designing software.

The question that should be asked is, "why this is allowed to continue?"

Software as it is currently being developed provides so much value relative to its costs that we as practitioners of this medieval-class craft (in terms of our level of automation and sophistication of production methods) can get away with practices that would not be tolerated by a Taiwanese manufacturer of toasters.

And this is the reason we are seeing programming jobs being outsourced to low wage countries. If you're going to get crappy software there's no reason to pay premium prices for it. It is exactly the sort of situation that befell the American automobile manufacturers back in the 1970s and 1980s. And unless we start to make changes we will see exactly the same thing happening.

Actually some of the software development places that are used for outshoring have formal practices in place for reducing defects. So it is entirely possible what we are getting is the exact equivalent of what I stated above. The overseas "manufacturers" produce better quality at a lower cost than we do.

I think that a basis of component architecture is the direction that we need to go in the development of software. That we need to make more software to be designed as a series of reusable components that can be used in other contexts. It also means we need to develop at least an engineering discipline in a way of making software of higher quality and eventually to reduce the risks of development.

And this is why I now understand more clearly why I knew that there was something right about this concept even though I didn't know exactly why at the time. In a book I once wrote, the main character explains about realizing the validity of a concept even if you're not sure why:

I know how that is; more than once I've had gut feelings about things where I couldn't put my finger on it, but I knew something wasn't right. Later I would discover why I had that feeling, and, more importantly, why I was right, but at the time I did not have the evidence or knowledge to know why I felt that way.

• George Green, "In the Matter of: The Gatekeeper: The Gate Contracts"

We can continue on the same path of disaster-ridden bugware or we can choose to change. We can change because the current methods do not work very well, they spell disaster in terms of cost, reliability, future employment potential, and the possibility of seeing our craft ruined by heavy-handed government mandates for licensing. We can choose to change because if we do not, the choice on how to make the changes may be made for us, and in a manner we will not appreciate.

The process will not be easy, but the benefits to us will more than outweigh the short-term losses by having to re-learn a new way of working, and thinking. If we want to continue to have fun in this craft without being placed into a bad position because of our own arrogance in failing to acknowledge the incompetence, sloth and waste our current practices contain, we need to change. And we need to do it before we are forced to do so because the customers decide they can't stand it any more, before we do.

by Paul Robinson 20 Deb 2005