Beautiful Code

I see your point but I don't think design should take precedence over requirements. Although design is very important (especially the usability kind) the product won't be of value if it is very easy to use, really nice looking but doesn't have the exact required features. This is especially true in government and education industries where VERY specific processes are in place which may conflict with your natural design tendencies.

Let me play devil's advocate. Let's say you're making a shopping cart for a customer's e-commerce website and they don't want you to have an 'empty cart' feature. At first you might question why such a vital piece of shopping functionality is left out but later the marketing guy might tell you they have studies that show the 'empty cart' actually discourages users from checking out. At this point I would understand why the button needs to be removed.

Zarar:

I agree with you about the importance of requirements, but what I was trying to outline is that requirements are, in fact, design decisions. We're not used to thinking that way in software.

Consider two examples. 1) The iPod. Apple made certain choices when they designed that iPod. One of them was to avoid having an on/off switch. That was a key product decision and, by any measure, a design decision, yet it could have be articulated as a requirement.

2) Most cell phones we've seen on the market over the past five years. Most of them are hard to navigate and completely inundated with features that we'll never use, and I suspect that it is because they were driven by requirements laundry lists without much awareness that the features are design choices.

I don't think the requirement is a design decision.

For me the requirement that leads to the use of a hatchback is: "the user should be able to load long, heavy items into the car."

As you can see, it is then divided into design decisions that makes the hatchback happen.

On the same line, the marketing department doesn't want 15 cup holders (well, except if the strategy of the company is to beat the number of cupholders in a car). It says something like: "we want the car to be comfortable, the users should be able to drink and eat in it, and never spill coffee on them."

The requirements are entirely design decisions. Even things as vague as "we want the car to be comfortable..." are design decisions. I know this is true because there are cars that don't strive for that (think any race car where safety is way more important than comfort).

It's important to realize when you are making a design decision, which is what I think Mr. Feathers is trying to get at. Any time you decide something that affects the resulting product, you've made a decision. If you don't realize that what we normally refer to as "requirements" in software are decisions that affect the resulting product then you are splitting the decisions between two groups of people who may, or may not, have the same goals and agendas.

Jeff Patton's been blogging some interesting stuff on this topic recently. See Requirements considered harmful for example.

(BTW - am I the only one who thinks the fonts on this site are insanely small? :-)

I fail to see the point of this distinction. Ok, so we say requirements are design, now what? In my mind the entire proposition is just arguing where to draw an imaginary line in the life cycle of idea manifestation. In this sense I suppose I agree with your conclusion that the traditional definition of requirements may fall under design, but I take issue with that definition (which curiously you never came out and identified.) But let me explain more:

In all cases developing something follows a general flow: inception of the idea, then refinement of the parts of the idea into smaller and smaller pieces until those pieces are no longer abstract and form a tangible result. For example an idea for a new program starts as just that, an idea, then gets broken down into general functions which are in turn broken down into more specific parts and again into yet more specific etcetera etcetera until it is fine grained enough that you are breaking it down into code statements. Arguing which part of this cycle should be called "design" or "requirements" in terms of how deep in this refining cycle they lie is inherently flawed as I see it.

Taken from the standpoint of the English language definition "design" is (according to Princeton wordnet) defined as "the act of working out the form of something." When the idea is first being refined and major feature groups decided obviously the final form of the product is being worked out on a grand scale. But similarly when the programmer is taking what input he has and forming it into computer commands he is also "working out the form" of the final product. It may not be the visible, front-end or even functional form, but it is still the form.

In this sense each of the areas you seek to differentiate by depth within the refinement cycle should instead be defined along other lines because at all depths the progression of the development could be called "design." As an example one such other set of criteria you could use might be the goal of the designer. In this respect most obviously you have design from the approach of "what it does/is" and "how it does it" (among many others beyond the scope of my point.) Then of course you have varying degrees of precision in each of those areas as the product development flows from inception to realization.

I would consider "requirements" outside the realm of this design flow completely. In my mind "requirements" are the design elements of any kind and precision (as just defined) that the customer (or marketing dept) pointed at and said "hey, I want that." They may be as general as "it has four doors" or as specific as the way the flame decals are applied.

Hi Michael, good to see you last week.

I don't think that it's quite _all_ design.

What cars have (as Antoine touched upon) is constraints. For exmaple, the constraints of the Citroen 2CV included that a peasant wearing clogs should be able to drive it over a ploughed field (without breaking a crate of eggs, IIRC) and that it it should (on a metalled road) carry 2 people and a 50kg payload (of potatos) at 60km/hr. Also, that it should cost no more than a third of what a Traction Avant cost, have a certain petrol consumption, and so forth.

Notice that design briefs for real things in industries that know what they are doing do not have this crazy functional/non-functional divison that we cripple ourselves with in IT.

Meanwhile, I see far to many "requirement" documents that prejudice not only the design but the implementation. Usecases particularly muddy the water here: since usecases exist at the system boundary they can only be a specification tool, which inevitably includes design decisions. System requirements, and even more so the business goals for a proposed IT solution should come well before this.

The literature on this kind of thinking is lamentably sparse, and much of what there is is very dubious, but Cook and Daniels and the subsequent work by D'Sousa and Cameron-Wills do a very good job of covering it.

Joshua:

Exactly. I think that the problem is that there is a lot of unconscious design happening in organizations. Sometimes it's called requirements, but it is really design by laundry list.

Adrian:

Thanks for the link to Jeff. I hadn't seen that.

Jason:

You said: "I fail to see the point of this distinction. Ok, so we say requirements are design, now what? In my mind the entire proposition is just arguing where to draw an imaginary line in the life cycle of idea manifestation."

I hear you, but I think that what we see as design and what we see as requirements affects our perception of what is possible.

When I blogged this, I came close to telling the story of Jack Reeves and his article What is Software Design?. When I read that in the 90s, it spun my head around because I had been on several projects when the project division between design and implementation had caused a great deal of waste and grief.

His articles have received more exposure since then, and that's great. It seems like there's a ripple effect in the industry. I run into many people who've never heard of Reeves but, fortunately, are in much a much better situation now than what we were in in the 90s. I suspect a lot of it is because the ideas were discussed and had influence beyond the people who heard them.

So, yes, I think that talking about these things does some good.

Keith:

Yes, great seeing you last week.

I agree. People seldom examine the constraints. I remember the first time I tried to do that as a real process step. We looked at what the customer wanted and kept trying to elicit constraints. It was seen as a distraction.

I try to imagine what happens in conversations with architects. You might walk in having a clear idea of your need for two bedrooms and a study. The architect (if he was a silly as my younger self) could have said "Whoa! Let's look at how you live and see what you really need!" or, he could be subtle about his elicitation and possibly make suggestions that are a bit off from your original plan to have two bedrooms. I think that because the work is subtle, it is easy to skip without notice.

An aside: I love Cook & Daniel's Syntropy book. I was interested in Catalysis, but I felt that it was interesting more in a "this is a good thing to know" sense rather than a "do these things whenever you are developing software" sense. It seemed like overkill in that regard.

Great post.

I think one of the most recent good examples of amputation of a successful product is Apple's iMovie '08. They gutted a reasonably full featured consumer editing program in iMovie '06 in an effort to solve one of their engineer's problems: how to make a simple movie very quickly. They've taken some beatings in the press over this reduced functionality.

It takes real guts to do this and thats why I respect a few companies like Apple and Nintendo and 37 Signals above most others because they're willing to make some damn tough design decisions that others would never make.