Why We Don't Build Software for Users (Continued)
Programmers Aren't Planners
VSM: And you're saying they haven't seen planning.
AC: Right. I tell them they haven't seen planning, and planning works when done right, but they're otherwise right on target. Real software architects do effective planning—they do research, work with stakeholders, and distill what the real goals are. Then they begin to synthesize a real solution and collaborate with the builders as they build. Organizations that have wholeheartedly adopted goal-directed planning methods such as ours have been able to create products that both users and programmers love. And they get enormous efficiencies, sometimes cutting development time as much as 50 percent.
VSM: Is iterative development part of your method?
AC: "Programming is an iterative process," the XP/Agile folks say. I say the act of delivering an appropriate solution to the user is iterative, but doing that iterating in code is far more expensive than iterating at the design stage, where it's far cheaper, far more efficient. You should iterate, yes, but five times, not a thousand times. Virtue lies not in the iteration itself, but in achieving the successful course correction.
VSM: I've heard it asserted that in India programmers do much more planning than in America.
AC: I don't think programmers are good at planning, nor planners good at programming. Maybe it's like choreographers and ballet dancers. The best choreographers have some dance experience, and the best architects have some practical experience. Architects who've spent a couple years programming know best, but they weren't necessarily great programmers. I've done so much programming I have an innate sensitivity about what the programmers have to do. How programmers use their special programming abilities to solve programming problems interests me. But what's strange about people who program: They have this sense that they'll solve all problems with those skills.
VSM: To a hammer all things look like a nail.
AC: In the professions that are rooted in the physical world, design pattern inventor Christopher Alexander describes what he calls the self-conscious process, with people reflecting on what they build, vs. the unself-conscious process. Programming is a self-conscious process. In the world of software, we don't have that enormous physical craftsman heritage. Engineers are good at solving in vitro problems, and programmers are good at building stuff, so all these people realize there's a crisis in software construction. Consequently, all the engineers are trying to do plans and methodologies disassociated from users, such as RUP, and the programmers are saying, "just let me build one room." I'm deeply respectful of the impetus both have to solve the problem, but they lack the sense of humility that the physical disciplines have.
The unique thing about software is that people in the software trade don't see that their point of view is unique and only applicable in a unique situation. Every company has a controller, bookkeepers, and financial analysts. If you went up to any one of them and said "we want you to write code," they'd say "we can't." But if you go to any programmer or engineer and say "we want you to do financial software of some sort," they'd jump right in.
VSM: That's how you get accounting packages that can't handle real-world problems such as bounced checks.
AC: I read on the Web where someone was trying to get a refund, and the Web site would let him fill out a form for a price adjustment, but had no provisions for a refund. He wound up using the price adjustment form and entering an amount that was a penny less than a full refund. It worked. There are a bunch of problems here that are conflated.
VSM: What do you think is the root cause?
AC: A lack of management. There's a vacuum in software construction management. The true architect asks some simple questions, such as: Before we start pouring concrete, do we know what we're building? The solution is to hire an architect and have him figure it out. Then builders can build it using the best tools of their craft. This way you get much more efficient software devel—er, software construction.
If you look at any construction project, there are foremen and construction supervisors: a hierarchy of people whose job it is to keep the builders—the constructors—following the plans. The supervisors know the craft, the trade, and the blueprint, and it's their job to make sure that the blueprint gets executed. They constantly have to corral the tradesmen. But in software construction, nobody is playing the role of foreman or construction supervisor.
VSM: What about lead programmers?
AC: The lead programmer is a construction person, and has different responsibilities. It's like telling the carpenters to elect one of their own to run the group. But the lead programmer's loyalty is to the programmers. There's no self-interest there. No bonus if you build to the plan because there is no plan. There's no management infrastructure inside software construction. Yet every other discipline has a robust infrastructure.
For example, non-commissioned officers in the military bridge the space between the officers and the enlisted men. I think there's management at this level in every trade except programming. There's this break in the command structure, and the programmers are let loose. HR manages job benefits and IT management makes sure the programmers are working on the right project. But nobody's comparing plan with daily execution. So there's no sense that you need a plan. Nobody in management has ever seen a plan, so there's no concept that you need somebody to guide programmers along the plan.
Consequently, if you broach the idea of introducing a plan, the programmers scream bloody murder. Ask Kent Beck what he thinks of plans, and you'll hear his voice two states away because he's been victimized by engineering methodologies masquerading as architectural plans.
Those are the main points I want to cover. There's this upheaval going on inside the software industry. People outside the industry know it's out of control. Software is expensive and becomes obsolete in a year. But people outside have no way of knowing that it doesn't have to be that way. And people inside haven't cared too much up until now. But there is some movement within the industry toward recognizing that it's not all milk and honey. That's providing the impetus behind these two movements [UML/RUP and XP/Agile].
Back to top
|