Three Views on Software Development

This week I happened to read three pieces by three different authors, whose publication dates span almost twenty years of evolution in the software industry, and whose ideas fall on opposite ends of a vast continuum of thinking about software and how it is written. Or at least two of them do.

The first is a remarkable paper hand-written and distributed by Edsger Dykstra in 1988, called “On the cruelty of really teaching computer science.” It has since been scanned and preserved for posterity. The handwriting is one of the things that make this work remarkable, and every teenager who today aspires to some technical trade should be required to read it and hand-write a commentary. They will learn that it was once possible for humans to think and express themselves in complete sentences, even when using a stylus and vegetable dye to scratch lines onto a surface of dried wood pulp and white clay.

Beyond that obvious and lamentable anachronism, I don’t consider myself qualified to fully understand Dysktra. He seems to be arguing that every program is a representation of a mathematical formula, and that if we were to truly educate new comp sci students we would have to begin by instructing them in formal mathematics. I don’t know. I recently worked on a large legacy system that has been maintained and extended by contractors from all over the world, over twenty years, and I am pretty sure that if you tried to express that monumental piece of shit as a formula the solar system would disappear with a soft, gaseous “pop.” This is one of those things that I intuitively think must be true at some scale, but must also be entirely irrelevant to almost anyone. Nevertheless, I admit it before the court as an exhibit marking one end of the continuum I mentioned above: software is so hard you have to understand formal mathematics to comprehend it correctly.

At the other end lies a recent piece by Stuart Cohen for Business Week, in which he discerns a fundamental flaw in the open source (FOSS) business model: the product is free. The product, of course, is supposed to be free. That’s the Stallman-esque proposition on which the whole thing is founded: that software has some ethereal quality that renders it a morally unfit object of profitable work. But programmers have to eat too, and so the business of free software (eh?) was supposed to be founded on the sales of support. Somehow it is ethically suspicious to charge money for software, but just fine to charge money for helping people to use it. It turns out that people don’t need to buy much support, and the reason that Cohen assigns for this is that the software is just too good. Good software is now a commodity, therefore the only way to make money in software is to collaborate, somehow, using Cohen’s software or software like it, which presumably he doesn’t sell, but which you pay to collaborate with… or something.

With all due respect and apologies in advance: bullshit. I have some news for Mr. Cohen. Few people have ever needed to buy software support. When faced with the need to pay for support, or the need to RTFM and figure out how the stuff works, most people always took the latter path. In various positions over the years I have paid out hundreds of thousands of company dollars for software support contracts under which I have never actually received any support. This is exactly the revenue stream that still pays for Larry Ellison’s toy jets. The payments were not actually intended to cause the delivery of support. They were membership dues for the Oracle customer club, or the SAP customer club, or entry fees for the Microsoft Customer Portal… whatever. If you really needed help you went to a community forum and asked there. To say that this is because the software was too good entirely misses the point, besides being a statement full of comedic energy in its own right.

Packaged retail software is the kind of programming that you might argue has become somewhat of a commodity, largely due to open source initiatives. That isn’t the kind of software that generates large support contract revenue streams. Therefore the expectations of the community that thought to build a business model on that platform were somewhat delusional. If they want to eat they will probably have to go back to selling their work, like the rest of us. The kind of software that requires support is the kind that is far from commoditized: the thousands of custom applications that businesses build every year to enable or improve their work processes. If that stuff is a commodity I’d like to know where the market is, so I can buy some. From my perspective code quality and effectiveness in these kinds of projects has decreased over the last twenty years, even as there has been an explosion in the number of custom apps being built and the people building them. Which brings me to the third piece I read.

Actually, it is one of a series of three essays by Jack W. Reeves that he published beginning with an installment in C++ Journal in the Fall 1992 volume. The basic thrust of the argument is that program code is design. It is based on the idea that a design is a complete specification for something that can be built. In the case of what we programmers do, the code is a design that is built by the tools into something that runs on a particular system. It might, at first glance, seem about as relevant a point as Dykstra’s, except that much flows from this seemingly innocent assumption; such as the conclusion that a lot of the other crap we have accumulated over the years in a quest for reproducable results, like UML, is not design, and can never be design. I think a lot of programmers feel the intuitive truth of this. You can work months on complete diagrams and descriptions of a software system, but what you have at the end cannot be turned into software. Once you start writing code that can be built, it immediately diverges from all that carefully prepared “design.”

Reeves goes on to argue that the popularity of languages like C++ is due to their support for higher level abstractions, which encourage and enable expressing the design in the one place that it can be effectively expressed: code. I like this idea, and I think it recognizes some hard realities that guys like Cohen just don’t get. Software is never going to be easy, or commoditized. The fact that easy software has become a commodity doesn’t illustrate an exception to the rule. Technical and business managers don’t need any further incentives to underestimate the risk of building software: they already do that very well. They don’t need to be told that good software is a commodity, either, because it isn’t. The truth, as usual, lies in the middle and I think Reeves nails the target pretty accurately, even when he skewers the people who have taken to using mechanical device analogies to describe software construction, something I’ve been guilty of. He doesn’t argue that such analogies are wrong; just woefully inadequate to describe the actual complexity of building good software.

Leave a Reply

Your email address will not be published. Required fields are marked *