It is a great question, one worthy of an real in-depth answer:

Software Blueprints

Paul.

So wouldn’t it be great, if you could take six months to a year and produce a blueprint of your idea operating system? One that you could give to a team and be confident that it was built the way you specified it?

No more ‘big plans’, no more wars. You don’t have to set it in motion and wait for twenty years. Just experienced people building full and complete products.

Did I mention I wanted a pyramid too?

Paul.

The “Big Plan” idea is what killed commercial UNIX, creating the void Linus filled. Well, it was “the war of the Big Plans,” which introduces a new factor a bit OT from this thread, I grant, but it was also true that none of the Big Plan companies was actually managing to deliver the product. It was too big for a single company, not only in the mass of cod and cost of labor, but in the ownership of the vision and evolution.

(Disclaimer: I worked for one of those Big Plan Unix companies in the 1980s, on their UNIX; maybe I’m jaundiced. And in my next gig, I worked at another, a smaller company with a bigger plan, and even less delivery and follow through, so maybe I’m jaundiceder. But neither looking around at the time, nor looking back at the history, was any vendor apparent that was actually delivering the goods!)

UNIX I suppose, is a great example since — to me, at least — I like the older versions better. There ‘was’ a philosophy and the result was that the systems were simpler and cleaner and more understandable. Once Linux and GNU became the ‘in’ thing, as more and more people contributed the complexity sky-rocketed. Some of it admittedly because the new versions do a few more things than the older ones, but lots of it is really artificial (accidental). Where I used to ‘know’, I can now only ‘guess’.

Personally, I would love to go back to ground-zero again and write my own operating system, learning from the mistakes of the past. I would (I dream) start with the basic ideas, but extend them in a rational and consistent manner. Clean up all of the messes, right all of the wrongs. But of course, by myself I’d need hundreds if not thousands of years.

It took twenty years to get to our modern version of Linux. A committee would only produce Multics again. Are our only choices between complexity created by committee or complexity created by time? Iteration is nice but it is a slow moving beast, and it must stay close to where it started.

I always feel that modern software is only a small fraction of what it can be; what it should be; and I sense that our own past is what is holding us back (when we aren’t too busy trying to forget it).

Paul.

There’s something to what you say, of course, and some kinds of software need that separate design activity. Not all need that much dedicated energy in the design, though. Maybe rocket trips to the moon (the historical context for a lot of software engineering discipline), for instance. But some surprisingly large and complex things seem to work better by incrementalism. Even before Linus took over, UNIX was much better described as collaborative, iterative design — and at that, substantially built from Multics and other efforts. And of course Linux specifically has been a jaw-dropping exercise in evolutionary unified design and implementation. The big question might be how to recognize which approach is more promising, before you’ve committed too much to the other one!

I find a separate design very attractive because I want to be able to leverage my abilities. Given the length of time it often takes to get a sophisticated software product past the 1.0 stage, if I want to build something big and complex my choices are a) take twenty years, or b) loosely rely on other people to build the right pieces.

It’s not that I am controlling for no reason, if my design is predicated on specific architectural features, someone only seeing or understanding a subset of the design may jump to the wrong conclusions. I want to allow some degree of freedom, but the final pieces have to fit together.

I try — each time I build something new — to make it bigger and better than my previous work, but I’ve definitely bumped up against my own ability to complete the whole project by myself. Big teams often produce significant compromises, as everyone gets their say; people are happy, but the ideas get watered down. To get to the next level I need delegate the work, but not lost control of the output.

Paul.

1. Maybe this “separate design from implementation” thing is only attractive to people who don’t know what they’re talking about, who view the “other” discipline to which they wish to apply it as only an annoying hinderance (or something like that)

2. OTOH: I think Cooper is advocating for software what he has separately advocated for his own field, interaction design. And I know interaction designers who desperately want permission to work that way, and cite Cooper constantly to that end. But I don’t see that yearning in the software arena, and don’t feel it myself: in software, we see this as a step backwards. Cooper attempts to forestall this objection in his writings and website, but how many actual practitioners have to disagree with the out-freyn pundit before they win by majority rule?

3. In any case, he nowhere I know of addresses the question of how these designs get communicated to the implementers, how we translate between the design-centered quick-and-unconstrained language to the details and robustness implementation language. In interaction design, this is the difference between “HTML written strictly to produce screen shots” and “templates and JavaScript and Flash and what-not intended to produce similar HTML”: the finished product of the designer *is* the specification for the implementer. But if I choose to design software in something unconstrained like Java or LISP, my concrete design is no help at all to my implementer working in C# or Ada: the turn-over dynamics are quite different, enough to make me wonder about the wisdom of transferring the process.