On the one hand, our industry is beginning to recognize that successful UI design is about communicating with a human being to support that person in the performance of some task. Organizing that communication around terminology, metaphors, concepts, and workflow that is natural to the task takes quite different skills than the technical skills of making the computer perform a specified action.

Similarly, successful software design requires thinking of larger issues (scalability, deployability, addition of future unanticipated features, etc.) that don’t arise from simply reading the functional requirements of the current release.

It is important to return to visionary documents such as Kapor’s, not only because they give us fresh perspective on where we are, but also because they can remind us of parts of the vision we may not have fully realized in our rush into the future. As William Gibson said (and O’Reilly has used as their tagline for a podcast series), “The future is here. It’s just not evenly distributed yet.”

Cleo wrote: “What would be better is if there was a way to specify design and have the computer generate the implementation.”

Yes, it would be nice, but I’m wary of things that sound like code generation. To have a truly useful tool, it would have to accurately reverse-engineer the design from the potentially modified results of the code generation. I have never seen this work on anything other than small-scale projects.

The few such tools I’ve tried in the past have been tedious to use, error prone, and generally unhelpful. Keep in mind that programmers don’t like making extra work for themselves. If it’s hard to use and doesn’t do a great job they’ll avoid using it. But, if someone eventually gets this to work, I’d definitely give it a try.

But then, in order to scale it, these men are advanced to “architect” positions and less “expensive” programmers are hired to work under their leadership in hope that in this way the company will get one’s talent “improve” others team members output. That’s crucial mistake, because the art of programming is not “scalable”, because of great complexity of software projects. It is a lonely wolf routine. Your best stake is to hire as many good programmers as you can and let them roll.

What would be better is if there was a way to specify design and have the computer generate the implementation. Now, that would change things drastically in the computing community. Instead of building implementation directly, we would write code as possible algorithms that the code generator can use for its output. But the design would be easy to change. This area interests me so much that this is exactly what I’ve been researching this past year and am currently developing a project with this in mind. I wonder how many other attempts have been made and what ideas there are out there on the subject.

I’ve heard that too often to give it credence. The code is not design, it’s implementation. You can hope to extract a design from the code, but more often than not you’ll see a mass of implementation details.

In construction, there is a distinction between the architect’s plan and what is on the ground. As a building gets constructed, notes are made on the plan with the caveat “As Built”. “As Built” is a trade-off between the actual design and the reality of building something. In construction, such changes are documented. In software, that information is often lost and is almost never in the code.

Some people use “the code is design” as an excuse to slap things together with no plan for construction to begin with. The result is a mess that is buggy and extremely difficult to understand.

I’ve also heard “The code is documentation” too often to trust, but that is a separate issue.