Welcome Guest!
Create Account | Login
Locator+ Code:

Search:
FTPOnline Channels Conferences Resources Hot Topics Partner Sites Magazines About FTP RSS 2.0 Feed

Back to the Introduction


Why We Don't Build Software for Users (Continued)

Development vs. Construction
VSM: What's the difference between software "development" and software "construction"?

AC: For years I've talked about software development, but it's a confusing label. Software doesn't get developed. It gets built. It's a construction project. Calling it development gives the impression that it's an ongoing thing, and many of the ills we experience come from that. Buildings don't get "developed." They get built—even if they can be remodeled later. I'm trying to strike the word "development" from my technical vocabulary and talk about the software construction process.

Consider this observation: Everything we build in the real world comes from a long string of pre-industrial construction. Take a table, for example. I'm sure there are people who've studied table making, table selling, and so forth. But before that, people made tables by taking a tree and laying it across a couple of stumps without thinking of it as a discipline. There are deep roots to this.

It's true also for machines that come out of the industrial revolution—they replace manual things. So they're extensions of things we did by hand, with roots in practicality.

Building software is different. It doesn't have roots in the physical world. And in fact, software's roots are in academia. Unfortunately for us, success has a different definition in academia. In the real world, if the tree falls off the stump, it's a failure; in academia it's a successful experiment. In academia we think about developing an idea. Our roots don't lie in the pragmatic world of making mechanisms that serve us. Instead, they lie in the scientific discipline of observing. That's why we have so much trouble with the idea of "constructing" software.

If you look at the construction trades before the industrial revolution, there was craft. Craftsmen were highly skilled people who worked with their hands and heads to do difficult, complex work—they were masons, harness makers, cobblers, coopers. They had their tools, training, and lore. And they built things that served a practical purpose.

The industrial revolution changed that by creating the engineer. The engineer is also someone who's building something, but his or her work is one step removed from the people who will use it. The engineer is clearly a creation of the industrial age—the age of engines. But we're not in the industrial age any more. That's over.

VSM: Are you saying programmers are like mechanics or engineers or…?

AC: I see that there's a great deal of confusion about roles. Here are programmers who are intelligent, highly skilled, doing a demanding job that is remarkably impenetrable to outsiders. Most people know more about how the Vatican works than what programmers do. And I think that programmers' education is still deeply rooted in the scientific discipline of approaching software construction as though it were a scientific experiment. When you're constructing software, you should have a pervasive awareness that as a craftsperson, you're exercising your craft to build something someone will use. Unfortunately, this is not a constant in the software construction world. We resolve problems not in service of the user but in service of the engineer.

Introduction The Rise and Fall of the Craftsman


Back to top

Printer-Friendly Version












Java Pro | Visual Studio Magazine | Windows Server System Magazine
.NET Magazine | Enterprise Architect | XML & Web Services Magazine
VSLive! | Thunder Lizard Events | Discussions | Newsletters | FTPOnline Home