he more time I spend thinking about alternative programming methodologies, the more I wonder why there’s so much resistance. Which is to say that I generally believe in the concepts of agile programming?except, at least, one. Last week I attended a presentation by Scott Ambler, the guru of the Agile Modeling methodology. The talk was one in a series of lectures put on by SDForum. Ambler clearly knows what he’s talking about and has seen it work. But it wasn’t until I read more about Ambler’s belief that requirements are the sole domain of business managers, or “stakeholders,” that I felt a rift opening. In an online essay, Ambler says defining requirements and prioritizing them are solely the responsibility of business-side stakeholders and not the concern of developers.

I don’t wish to oversimplify Ambler’s position. He has written volumes about what he calls “Active Stakeholder Participation” and on close study, much of it is quite sensible. But I cannot agree with the basic premise: The process of creating software requirements simply cannot be decoupled from the technical knowledge base, and that technical knowledge base lies in the brains of developers.

However much development wants business stakeholders to be perfectly equipped to define and prioritize software tasks, it’s simply wishful thinking. Sure, it would be great if you had interested, technically astute business people who could clearly formulate software requirements and help with design and who are given adequate time to devote to the process, but this circumstance is far too rare to expect.

As a business person?a stakeholder?I find myself wishing that Ambler could watch me fumbling with the task of writing requirements. I can’t be the only one who finds the idea of conceptualizing the full scope of new software daunting. For me, it’s a very backward process. As a person trained to take data and analyze it, draw conclusions from facts that I can gather, the notion of creating facts and requirements from a blank slate is unspeakably difficult. If you ask me questions, I can answer. But left on my own, the right questions don’t seem to occur to me, until far too late.

For example, imagine my chagrin when a coworker, being trained on a new piece software, turned to me and asked with barely suppressed derision: ‘Who on Earth decided that this thing should be a Web application?’ The answer: I did. Can I give you good reasons for why I chose a Web interface over a desktop app? Not really. It’s just what occurred to me first. The responsibility was mine; the repercussions of my short-sightedness now belong to the organization.

The ‘I Just Build It’ Refrain
Development teams once bore all the responsibility of building software and seldom had adequate input and feedback from the business side. Those days are thankfully over. But now it seems we’re in danger of seeing the pendulum swing way too far in the other direction.

It’s not hard to understand why the “I just build it” refrain is growing in popularity. The latest data (released just a few days ago) from the Standish Group, which has been studying software success and failure rates for 10 years, found that 15 percent of all software projects still fail, while more than 50 percent are considered “challenged.” It’s a depressing statistic. The reasons for failure, of course, are as varied as you can imagine, but poor or myopic requirements are likely to be way up there. The business-side people fail to tell you exactly what they want, you do your best to divine their preferences from a vague concept, and when the finished product doesn’t meet expectations, they blame the failure on you. And later your team ends up spending more of its time doing maintenances and changes to fix problems that should never have occurred in the first place. Is it any wonder that developers want to get a little distance from the responsibility of software success and failure?

It’s not your application anyway, right? If you were building it for yourself, you’d know exactly what you wanted. But you’re not building it for yourself: you’re building it for customers, with whom you have little or no direct communication. It’s the job of the business people to know what customers need, to decide how a new software product should work to best meet those needs, and it’s your job to make it work the way they say. That way, if the software works, but fails to meet expectations, the business side people have no one to blame but themselves.

There’s another benefit to this kind of insulation, too. It will give you of more of what you need most: time. If the business people do all the planning, all of the UI, and all the prioritizing for all of the projects, the development team has the luxury of being able to simply select tasks off the top of stack and work on each one in relative peace. Your team has less chaos, less responsibility for failure, and more time to do what they do best. It’s no wonder this management philosophy is growing more popular.

And despite all of those benefits?despite the fact that it will make you more agile and increase your productivity?it’s still a bad idea.

It’s a bad idea because you should want to have input?to contribute your knowledge, your past experience, your opinions, and your insights?to the application’s design. But more importantly it’s a bad idea because, quite simply, if YOU don’t help, it’s not going to get done right.

Your stakeholders are not, probably, a Dilbert-esque vision of half-wits in suits. If you were working at a company where that were the case, you would have quit by now. Neither are they uninterested in giving you the information that you need. But just as developers do not likely have a perfect sense of customers’ information requirements, business side people likely lack complete knowledge of what can be done, how it can best be achieved, and how long it will take. To a non-programmer a task that will take you 100 hours of programming can be indistinguishable from one that will take you 10 minutes. Their decisions on how to build things are mostly likely going to be drawn from their experiences as end users, using software and Web sites that are outdated or of arbitrary quality.

In contrast, as a developer, you know what software is capable of. You know what your team is capable of. You know how long it takes to do things one way vs. another. You know how the software you already have works (and you probably know what things need to be done differently). You know, because you’ve studied software and can see it completely deconstructed. You can see all the many ways that a new feature can be built. In the same way that only a composer can imagine a symphony and construct each part for each instrument, only you can see the big picture that will guide stakeholders to success.

Will the business people know when certain features are dependent on one another or when features could share a code base for efficiency or need to share a data store? Not likely. But worse, if you treat all the features of an application like so many interchangeable components, leaving it to others to prioritize the sequence of feature development, neither will you.

Questionable Practice
I’m oversimplifying the problem on purpose. Even developers who rigidly insist that the responsibility for requirements falls solely to non-developers would never simply accept those requirements without analyzing them, without carefully surveying them and engaging the submitters in a careful process of question-and-answer. But even that doesn’t solve the problem because the problem begins the moment you tell a stakeholder in your organization to ‘go and write down what you need and we’ll talk about it.’

A stakeholder who has a question about the feasibility of a certain type of feature shouldn’t be forced to document that feature before he has any possibility of uncovering an answer to his question. Being too regimented about how you accept and respond to questions can lead to many wasted hours in writing requirements that will never be acted upon. It bloats the process and wastes other people’s time.

If a lot of this sounds like common sense to you, good. That’s exactly what I’d hoped. But if you’re participating in the groundswell that eschews responsibility for requirements planning, you’re simply exchanging one set of problems for far uglier ones.