Why We Don't Build Software for Users (Continued)
Managers in Denial
VSM: How do we wind up trying to drive nails with jackhammers (so to speak)?
AC: One of the main reasons we don't understand what we do is because there are two types of managers: software builders, and those who are scared of software builders. Software builders are hypercompetent and highly intelligent. The managers who don't understand software builders have good management skills. The managers who do understand them don't have good management skills—they focus on developing their own understanding instead of serving the customers.
VSM: Great. We get to choose between lightweights or technoids with Asperger's Syndrome.
AC: As a result, programmers are not managed. Most of the business community is in denial about this. Inside the world of programming, there's a kind of tacit recognition that we're not managed. Meanwhile, software gets bigger and more complex, having moved from spaghetti code to structured software to OOP, which lets us build software bigger than programmers can hold inside their heads. So now you need multiple people working together, and in the same way that we've developed OOP, we've got to develop a methodology for managing programming and programmers. And one discipline that's emerging is RUP.
VSM: You said both approaches are right in their own scale domain, didn't you?
AC: They're both right as construction methodologies—not as management or planning tools. Yes, software is a craft. Yes, it's engineering. But if you're building, say, an FAA aircraft control system, you've got to have a lot of craftsmen building it and engineers engineering it, but neither discipline functions well as a management tool. And a lot of business executives who are scared of all this are saying, deep inside, we don't know how to manage them. Then they hear about RUP and they say "Yes!" Then someone else comes to execs and says XP, and they say "Yes!" again.
VSM: And the answer is software architecture?
AC: Here's a book published through the Worldwide Institute of Software Architects [rummaging through a stack of books]: The Software Architect's Profession by Marc and Laura Sewell. I read this book and every single word of it spoke to me. Everything they say I agree with. It has a forward by Grady Booch, who says there's a significant layer on top of programming that provides the bridge between business management and software construction (including both engineering and craft). It was so exciting to read this book. Kindred souls. It reminded me of that Bob Dylan lyric, "And every one of them words rang true, and glowed like burnin' coal."
So I bought the next book in the series, also under the mark of the WWISA. It's called Software Architect Bootcamp. I opened this book and read that it provides the basics that every software architect needs to know. Now I see myself as a software architect, right in the middle of that triangle of people, purpose, and technology. I understand people and I understand the pragmatic goals software is trying to reach. An application isn't a monument—it's a building that must serve some real purpose. Just like a building architect must design.
Page two of this book says the software architect both designs software and guides the construction of the software. It's a collaborative process. Then I read that being a software architect is different from a manager because he's a direct technical contributor.
So far so good, but by around page eight, either the book or I go completely off the track. The authors start talking about all the different architecture approaches, but in fact they're all engineering approaches. Nothing about users. Just use cases, which describe tasks from an engineering point of view. The book immediately leaps into detailed discussions of engineering. There's nothing in this book that I do. I'm a software architect and I agree with the intro, but I have no commonality with what they call the basics. It's clearly engineering. Engineers don't talk about why you want to build a building. They say how to do it efficiently. Use cases let you collect a spec, such as, "it has to be 40 stories tall"—but nothing about why it needs to be 40 stories tall and what purposes it serves by being 40 stories tall.
On page 103 you finally get six paragraphs devoted to users' needs, done at arm's length. "The requirements should define the goals of the system … with the use cases defined we have established the cases for architectural planning." What a terrible misstatement. That's like saying with the statistic of the number of operations performed and the chosen wall colors, we have established the design for building the hospital. It's specious.
VSM: Sounds like a book on management by Asperger's people who don't know they've got Asperger's.
AC: "Architecture bridges the huge semantic gap between requirements and software," the book says. But the authors' definition clearly doesn't, because it doesn't pay any attention to the human requirements. It goes straight from "We've performed 2,000 surgical operations per year" to "And we want the hospital's walls to be yellow." It never asks, "What are we building and how do we know it's the right thing?"
The XP/Agile programmers see this gap and step into the fray. They ask "How do you know?" and say "Let's build one operating room and see if it's big enough and see if it works."
VSM: Which is wrong too, because it ignores how scaling issues can change a project qualitatively.
AC: The engineering method the WWISA calls practical is not practical. The agile programming movement focuses on practicality but depends on flaky users. And the top echelon of engineers has usurped the Software Architect title.
The first WWISA book on theory was great, but the second was a big disconnect. I am not an engineer. I look at what engineers like Grady Booch do—I don't understand it, and I'm not attracted to it, though I can see how it's useful when applied correctly. It's certainly got its role, but not as a construction discipline and not as a management discipline.
Then I look at the XP/Agile programming people and I'm attracted to them for two reasons. They're the first to be reaching out of programming to do something practical. As an entrepreneurial guy, I'm strongly attracted to that. Then I look at what they do and I see that they do craft. They build beautiful things with their hands and their brains. I feel affinity with that. On the other hand, they say, "We've seen planning and it doesn't work, so let's throw it out."
Back to top
|