The Artima Developer Community
Sponsored Link

Artima Developer Spotlight Forum
Steve Yegge on Requirements Gathering

15 replies on 2 pages. Most recent reply: Sep 28, 2008 8:32 AM by john steve

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 15 replies on 2 pages [ 1 2 | » ]
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Steve Yegge on Requirements Gathering Posted: Aug 19, 2008 7:33 PM
Reply to this message Reply
Advertisement

Whether through user stories or formal documents, gathering the requirements of a software system is considered by many to be a necessary step before coding, or even estimation, can begin. In a controversial blog post, Business Requirements are Bullshit, Steve Yegge disagrees with this view, writing that in many cases requirements gathering is, in fact, predictor of future product failure:

It's the first thing everyone wants to do! It's the first thing they teach you in Project Management Kindergarten: the very first thing you should do on a new project is look both ways before crossing the street to your building. Assuming you parked across the street. And the next thing is: start gathering business requirements!...

Self-professed experts will tell you that requirements gathering is the most critical part of the project, because if you get it wrong, then all the rest of your work goes towards building the wrong thing. This is sooooort of true, in a skewed way, but it's not the complete picture... The problem with this view is that requirements gathering basically never works.

What really happens is this: the focus group asks a bunch of questions; the customers have no frigging clue what they want, and they say contradictory things and change the subject all the time, and the focus group argues a lot about what the customers really meant. Then the product team says "we can't build this, not on our budget", and a negotiation process happens during which the product mutates in various unpleasant ways. Then, assuming the project doesn't fail, they show a demo to the original customers, who say: "This is utterly lame. Yuck!" Heck, even if you build exactly what the customer asked for, they'll say: "uh, yeah, I asked for that, but now that I see it, I clearly wanted something else."

Yegge explains that while general requirements may be collected in the traditional manner, requirements about product quality are often compromised in the process, and such quality decisions can have adverse affects on eventual success:

In this phase nobody "imagines" that the thing will weigh too much, or be too slow, or will go through batteries like machine-gun rounds, or that its boot time will be 2 minutes, or any number of other things that ultimately affect its sales...

I'm not saying that usability teams can't do a good job. It's just that when the project implementation team and the target customer aren't exactly the same group of people, then there are inevitably negotiations and compromises that water an idea down about two levels of quality: great becomes mediocre, and ideas that start as "pretty good" come out "just plain bad."

In his post, Yegge suggests that one way to boost the chances of a product's success is to build a product that you yourself want to use:

ONLY BUILD STUFF FOR YOURSELF

That's the Golden Rule of Building Stuff. If you're planning to build something for someone else, let someone else build it...

You can look at any phenomenally successful company, and it's pretty obvious that their success was founded on building on something they personally wanted. The extent that any company begins to deviate from this course is the extent to which their ship starts taking on water... And the key leading indicator that they're getting ready to head off course? You guessed it: it's when they start talking about gathering business requirements.

Do you agree with Yegge's opinion that business requirements gathering is not a generally practical way to ensure a product's success?


John Wellbelove

Posts: 72
Nickname: garibaldi
Registered: Mar, 2008

Re: Steve Yegge on Requirements Gathering Posted: Aug 20, 2008 6:35 AM
Reply to this message Reply
I work in the postal automation business and the requirements are not so much gathered as imposed. The inputs and outputs are very solidly defined both in content and timing from the outset and are highly unlikely to change during the course of development. The only thing we do have a certain freedom over is the look and feel of the GUI, though the customer will specify the items that must be shown.

Sean Landis

Posts: 129
Nickname: seanl
Registered: Mar, 2002

Re: Steve Yegge on Requirements Gathering Posted: Aug 20, 2008 8:12 AM
Reply to this message Reply
I think the picture painted is possibly a common one but it only arises in a certain set of scenarios and presupposes a specific kind of customer-producer relationship. This is a narrow view and therefore, basing an encompassing 'answer' on it is not helpful.

This is a variation of the "If you want it done right, do it yourself" argument which has obvious flaws.

Jesse Kuhnert

Posts: 24
Nickname: jkuhnert
Registered: Aug, 2006

Re: Steve Yegge on Requirements Gathering Posted: Aug 20, 2008 8:23 AM
Reply to this message Reply
I agree completely that having someone with "subject matter expertise" on hand as part of a core member of the team developing a product is essential if you want to be successful. Ideally this person(s) will also use and beta test the product in their normal every day work. (or else they're just "remembering" what they used to do, which isn't nearly as good as actually using it to accomplish whatever the product is supposed to help you do)

Michael Hobbs

Posts: 51
Nickname: hobb0001
Registered: Dec, 2004

Re: Steve Yegge on Requirements Gathering Posted: Aug 20, 2008 9:27 AM
Reply to this message Reply
His points might be valid for the 1% of developers and business analysts that work for a division that actually sells their product - of which Yegge is a member. For the remaining 99% of us grunts out in corporate IT, we are essentially in the role of contract development. The customer gives us money beforehand and tells what they want. Then comes the sometimes unpleasant business of making sure that the customer is actually pleased with whatever result they ask for.

To say that we should not gather requirements is like telling custom home builders to pick an arbitrary house and start building an addition that they themselves would like to have. If they did a good job, the home owners will pay for it.

Marc Stock

Posts: 17
Nickname: salient1
Registered: Mar, 2007

Re: Steve Yegge on Requirements Gathering Posted: Aug 20, 2008 11:19 AM
Reply to this message Reply
Apparently Yegge doesn't know anything about agile development otherwise he wouldn't make such ignorant statements (which he seems to do a lot).

No matter...I'm sure he'll still be thought of as some kind of genius because he works for Google.

Carson Gross

Posts: 153
Nickname: cgross
Registered: Oct, 2006

Re: Steve Yegge on Requirements Gathering Posted: Aug 20, 2008 2:10 PM
Reply to this message Reply
All of Yegge's advice is great for people who meet the following critiera:


1) The possibility that your immediate experience may not generalize very well does not occur to you.

2) You work for google or some other company with such a huge cataract of money rolling through thanks to the poor saps who work on AdWords (none of whom give a shit about advertising, btw) that what you do essentially does not matter to your company.

3) You don't write enterprise software and, after a few beers, if none of them are around, you make fun of the people who do.

Everyone else can pretty safely ignore most of the stuff he writes, except for entertainment value.

Cheers,
Carson

John Wellbelove

Posts: 72
Nickname: garibaldi
Registered: Mar, 2008

Re: Steve Yegge on Requirements Gathering Posted: Aug 21, 2008 3:40 AM
Reply to this message Reply
> Apparently Yegge doesn't know anything about agile
> development otherwise he wouldn't make such ignorant
> statements (which he seems to do a lot).

You don't have to be doing agile development to know that feedback from the customer at regular intervals is essential to know...
1. Did you fully understand what the requirement was?
2. Did they fully understand what the requirement was?
3. Does the real world match up with what both parties think they understand!

Anyone who's ever had to interface with hardware using information from a manufacturer's data sheet will know what I'm talking about.

Jesse Kuhnert

Posts: 24
Nickname: jkuhnert
Registered: Aug, 2006

Re: Steve Yegge on Requirements Gathering Posted: Aug 21, 2008 5:13 AM
Reply to this message Reply
I have, but I'm not sure how that applies here? (other than the generally negative/hopeless feeling it reminds me of)

> Anyone who's ever had to interface with hardware using
> information from a manufacturer's data sheet will know
> what I'm talking about.

John Wellbelove

Posts: 72
Nickname: garibaldi
Registered: Mar, 2008

Re: Steve Yegge on Requirements Gathering Posted: Aug 21, 2008 6:36 AM
Reply to this message Reply
> I have, but I'm not sure how that applies here?

1. What you understand it means.
2. What they understand it means.
3. How it actually works.

This applies the requirements too.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Steve Yegge on Requirements Gathering Posted: Aug 21, 2008 8:29 AM
Reply to this message Reply
> > I have, but I'm not sure how that applies here?
>
> 1. What you understand it means.
> 2. What they understand it means.
> 3. How it actually works.
>
> This applies the requirements too.

I've worked on one project where this went reasonably well. The key was that there was a separate functional specification team that had the following responsibilities:

1. extract (as in 'pulling teeth') the requirements from the customers.
2. document the requirements.
3. verify the requirements were met prior to user testing.

The third one is crucial IMO. This is the only way I know of to mitigates the issues you are referring to. This team must be responsible to the customer that the requirements are met. If they test some code and say it's met the requirements, the developers are free and clear. It's between the functional team and the customers at that point. This eliminates most of the interpretation issues between the developers and the authors of the specifications. There is still the possibility of this issue between the customers and functional team but it's much more manageable.

There are two reasons why this works better. The first is, (let's be honest with ourselves) emotional intelligence is not typically something that engineers and developers have a lot of. Secondly, it's hard to bridge the gap between the fuzzy desires of the customer and technical requirements that are not subject to interpretation. It takes a special kind of person (I would guess mixed left/right dominance) to do this well and it takes time.

Of course, in my situation it was contract software so we knew who the users were and who was paying for it so it's not really what the original article was about.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: Steve Yegge on Requirements Gathering Posted: Aug 22, 2008 10:42 AM
Reply to this message Reply
I think the rant is generally sound if one or more of the following hold:

1. You can make a living building stuff for yourself
2. You work somewhere (e.g. Google) that will subsidize at least part of your time to build whatever you want.
3. You don't need to work to eat, pay the mortgage, etc.

Other than that, I think we all know that requirements gathering is hard. It is also necessary, as many others have pointed out here. Steve's rant pretty much is a brilliant statement of the obvious in many ways told in an entertaining fashion.

Generally speaking, most people make a living by building something or doing a service for other people.

Software developers, generally speaking, don't interface well with others. The fact that I can use that phrase and you all understand what it means I think is enough evidence to support it.

Since a lot of developers cannot or will not do a good job of figuring out what customers want, other groups have to do that. You essentially have a big game of telephone going on where millions or bilions of dollars are at stake.

What would be nice is if somebody could offer a superior alternative to focus groups and traditional requirements gathering that is not prohibitively expensive or puts undue requirements on the customer. Having a domain expert handy and available is great, and has been suggested in lots of places, but I think it ultimately fails simply because it is impossible. A domain expert has to work. They can't be at the beck and call of the development team to answer niggling questions that aren't spelled out in the requirements.

I guess just bitching about existing problems is much easier than offering practical solutions.

John Wellbelove

Posts: 72
Nickname: garibaldi
Registered: Mar, 2008

Re: Steve Yegge on Requirements Gathering Posted: Aug 27, 2008 3:38 AM
Reply to this message Reply
I've worked on both types of project, ones where we were developing products for sale in a specific market as well as products for a specific customer.

The product for general sale could in no way have ever been designed without research into requirements. I'm an engineer, competent in hardware/software design. Our end users were security guards. If had deigned the product that I thought I would want to use, it would likely have been far from the end users perception of what they needed.

Paul Beckford

Posts: 51
Nickname: phaedrus
Registered: Feb, 2007

Re: Steve Yegge on Requirements Gathering Posted: Sep 1, 2008 7:47 AM
Reply to this message Reply
As always Steve is being provocative. Whilst I enjoy his style, I can see why he is often misunderstood:

<p>ONLY BUILD STUFF FOR YOURSELF</p>

In the ideal case, the person who desires the system and the person who programs the computer should be one and the same. Given that what is desired is often unclear in the first place, then rapid experimentation and exploration can best take place if the person driving the keyboard is also the customer.

This is not a new idea, and Fred Books identifies this problem too, and talks about the Uber programmer and the surgical team as a solution. The Smalltalk system was an attempt to bridge the gap between programmer and customer by raising the level of the programming language to something that customers could use themselves. The concept of liveliness is key here, where the system is always alive allowing the "customer programmer" to make changes on the fly and get live feedback without needing to restart the system. This idea has been carried forward into languages like Ruby. Whether a programming languages can ever be "customer friendly" is debatable, but DSLs and "live" languages do narrow the gap.

Steve's proclamations are as false as the ingrained dogma he is trying to dispel. I think he knows that. He just enjoys using shock tactics to get people to look at the root problem afresh.

Provoking thought is a good thing. Keep it up Steve :)

Jean-Daniel Nicolet

Posts: 13
Nickname: jdnicolet
Registered: Oct, 2003

Re: Steve Yegge on Requirements Gathering Posted: Sep 23, 2008 2:41 AM
Reply to this message Reply
I believe the manufacturing context is important here.

If you plan to develop something new, outbreaking, clearly you can't stand on reliable requirements emanating from a yet non-existing customer.

In a more stable business, like banking, insurance or administration, most projects are not new. They are just evolutions due to law or regulations changes, or re-building existing applications due to technology outdating (like IBM annoucing that it won't support AS400 anymore in 3 years from now).

In such cases, you are much better with good requirements than without. Nonetheless, it's largely a maturity issue of the end-users community. It's not always clear for these people that good requirements must also be testable and that after the necessary effort to formalize them, they'll have to invest in another round to write good test scripts, and then make the necessary effort to test the final product by playing the scripts they have just written.

In other industries, like automotive, aeronautics or pharma, requirements gathering is just so evident that it is not even mentioned. You can't start the development of a new medicine without taking the FDA regulations into account!

So we expect that the need for proper requirements management will not be discussed anymore in a few years from now, with a maturer software industry.

Flat View: This topic has 15 replies on 2 pages [ 1  2 | » ]
Topic: Community Book Creation: Python 3 Patterns and Idioms Previous Topic   Next Topic Topic: Look Ma! No OS!

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use