Without software that interfaces with users (or real life events), the software/software interaction code that you’re writing may be perfect, but ultimately useless. If your code is used at all, it’s because of those programmers that write the software that interacts with users.

I haven’t changed my mind yet..
Taking Euclid’s theorems by way of example, certainly the GCD algorithm has an existence as a glorious immutable truth (given of course the usual Godelian caveats). But it also has many instantiations, expressions in mutable media, most of which are now defunct. The Alexandrian scroll itself may have had transcription errors or lacunae. The existence of the immutable truth doesn’t help the scribe who is trying to compute something based on the scroll with its incomplete or imperfect expression of the truth.

When we deal with software, we’re not usually at the ‘immutable truth’ level. A few brilliant coders are, but, lackaday, most of us who toil at this particular coalface are not there. We’re dealing with the Platonic shadows of their brilliance. From our perspective, calling software ‘perfect’ looks like a category mistake: and giving databases as an example of the bedrock stability of software, verges on the ludicrous. Certainly there are thousands of installations of large databases processing billions of calls every day, which is pretty damn good software. There are also spectacular disasters in every database system known to man, at wholly unpredictable intervals. This is not perfection, nor do I expect to live to see it.

As for examples of projects that dropped off the radar and then returned, well, the biggest example is the software I’m using right now — Firefox. I use both that and NeXT as examples in the book. The Web itself spent 3-4 years as a project with very limited participation until Mosaic introduced it to a much wider public. And so on. The larger point to me is that the life cycle of software isn’t a linear sort of thing. I totally agree that in general, most successful projects stay a little ahead of the various cycles that govern the field. But sometimes a project falls so far behind one turn of the wheel that it ends up a little ahead of the next. Admittedly, this is not common. But it happens!

I can’t think of any examples. Maybe NeXTStep, but even that didn’t slog along for years unreleased. Vista had a long slog, but it didn’t emerge to fill a vital need. Chandler is an example of a project that will probably be irrelevant if it is finished and released — a modern “Soul Of A New Machine.” Projects that don’t move at least a little faster than the computing ecosystem as a whole are pretty much doomed.

One more thing. In this list which names don’t belong? Edsger Dijsktra, Watts Humphrey, Frederick Brooks, Ward Cunningham, Kent Beck, Joel Spolsky, Jason Fried, Nick Carr, Charles Simonyi, Alan Kay, Jaron Lanier, Richard Gabriel and Donald Knuth.

Obviously a lot of important names are missing, but what the heck is Joel Spolsky doing there? And Jason Fried? Their contributions are ephemeral or insubstantial by comparison to Knuth, Dijkstra, and Kay. If you think Joel’s “law of leaky abstractions” is an important new concept you should read his sources: Glenford Myers, Edward Yourdon, Brian Kernighan, and Steve McConnell.

Interesting comparison and taxonomy — and it meshes well with my notion that software is still extraordinarily young. (We are still in the era of “physicks” and “natural philosophy” to continue with your science analogy.) A new model is certainly needed, and I believe that truly coming to grips with the uniqueness of software is a prerequisite — and that means a broad-based understanding of notions like the perfection that software alone can achieve. (By the way, it is my belief that this will happen — at the latest — when humanity collectively realizes that the software upon which it has become inextricably dependent was largely written by dead engineers. This isn’t true today — by a long shot — but it’s hard to see how it won’t be true a hundred or two hundred years from now…)

I wonder if a decent model for “software engineering” might be something like the sciences, where a broad hierarchy:

math -> physics -> chemistry -> biology -> …

exists but doesn’t strangle the culture of the lower branches. All “field biologists” like me need some familiarity with the “physics” invented by you and your peers, and ultimately depend on it in various ways. “Biological physics” — domains where the algorithm is the heart of the user tool, such as search — certainly exist. But the many programmers doing the equivalent of studying polar bears or developmental genetics are IMHO not helped by a professional culture which exalts the terse, high-performance, hardware-centric systems algorithm above all, any more than field biologists are helped by exhortations to do better mathematical analysis of quarks.

Another way to look at it: in my mind, Page and Brin are arguably second only to Berners-Lee in their contributions to making the Internet a public tool. Yet in the professional discourse I follow they receive many times more attention than he does. Money and contemporaneity surely cause some of this, but it seems noteworthy that in one case where the landmark breakthrough at the application level provides the foundation for a big deal algorithm, we as a profession have flocked to them as heroic leaders, while mostly ignoring him.

I think you’re raising some good points here, but I definitely think that software that interacts only with other software has value — considering that that includes every compiler, every operating system, every database, every virtual machine, every app server, etc. Or rather, if it doesn’t have value, there are a ton of people who are paying too much for it. ;) And while it is true that ultimate value is derived from users’ interactions with the system, those interactions need not be explicit — and frequently aren’t in companies for whom IT is a core competency. For example, my interactions with FedEx consist of giving them a package, and perhaps checking a website a couple of times — but there’s a tremendous amount of deep, unseen, valuable IT that makes FedEx happen and happen efficiently…

I was disappointed with Beautiful Code because the majority of the entries fled the messy world where value actually arises for the tidy world where APIs can aspire to elegance. Worse, a large number of them more-or-less took as a postulate that “beautiful” == “fast”.

Like hundreds of thousands (?) millions (?) of other software developers, I write programs with human interfaces. Those programs would not be possible without the work of systems giants such as yourself, and speed is an occasional issue, but I have found the worship of internal elegance (and speed) in the culture of software development to be unhelpful, while the issues that Scott discusses in DiC are pressing everyday concerns for me.

Perhaps the biggest obstacle to developing coherent theories of software development is the sheer diversity of the work?