Why We Don't Build Software for Users (Continued)
The Rise and Fall of the Craftsman
VSM: Reminds me of a saying I heard decades ago: "In the course of every project, it eventually becomes necessary to shoot the engineers—and begin production."
AC: In the world of software, Web designers are called programmers. Programmers are called engineers. Engineers are called architects. And architects never get called! There's a real confusion about titles and roles. A lot comes from the fact that before the industrial age, craft was a peak achievement. If you were a political leader or owned property or were a priest, you had status in the community. But if you weren't any of these, the only way to rise was as a craftsman. It was a big deal. Then the Industrial Age changed that and made craftsmen go away. We gave up craftsmanship to get availability. Engineers figure out how to make the machines that make the products. The engineer rose and the craftsman sank.
VSM: So software is engineering?
AC: Having spent a long time in every role, I can tell you it's a craft. Software programmers have more in common with masons than with engineers. Engineering—real engineering, not programming—is problem solving divorced from the needs of actual people.
VSM: What would you call those software architects whom you say never get called?
AC: Here's what I think the division should be: Architects synthesize people, purpose, and technology. If you just take people and technology, you have art—entertainment. If you just take technology and purpose, it's engineering. And people and purpose without technology is psychology. Architects have to synthesize all this, to create a vision of a solution. People must get something practical achieved. Going back to our table example, a table is a mechanism to support eating.
VSM: Doesn't requirements analysis provide that?
AC: Requirements analysis doesn't fully solve the problem. [Taking out some books] Here's a book that I highly recommend: Software Craftsmanship: The New Imperative by Pete McBreen. The Extreme/Agile programming movement is in sync with Pete McBreen's thinking. The programming world is boiling under the surface with two powerful movements emerging.
One is the engineering movement, as exemplified by UML and the Rational Unified Process (RUP), which describe how you plan and document huge projects. The other is the craft movement. McBreen asserts that programming is craft. This is echoed by people in the Extreme Programming (XP)/ Agile Programming (AP) movement, which says it's not about method, but your individual skills. I love this. I think for the first time the world of software construction has a chance to get out of this academic cloud. The god programmers worship is one of their own construction, not one that serves a practical purpose. Programmers have gotten away with this for 50 years. Agile programming represents the first time programmers have faced the fact that their job is to make real software for use by real people, rather than for our intellectual aggrandizement.
VSM: Sounds like you're saying XP über RUP.
AC: These two movements in the software world—engineering and craft—appear to be moving in opposite directions. But I think they're both right. The problem is that you can't focus craft methods on engineering problems and vice versa. So the places they break down is misapplying RUP to something that needs three craftsmen working on it, or trying to use individual craft methods to do big projects.
Where is it carved in stone that we have to use the same method for all projects? A carpenter can build a house just fine, but you can't use carpenter skills on an aircraft carrier. On the other hand, if you're used to building aircraft carriers, with giant metal shops building giant subassemblies, then you'll try to build a small house using giant slabs assembled in a welding shop. This doesn't mean what we know about building houses or aircraft carriers is wrong.
Back to top
|