Business Requirements are Bullshit • Hacker News Board

Re: Business Requirements are Bullshit

#41

Post by edw519 » Tue, Aug 12, 2008, 3:46 PM UTC

nonrecursive wrote: post #35

edw519 wrote: post #24

Earlier quoted context omitted.

...actual methods described in most of the software engineering requirements books... Thank you, Matt. You have just demonstrated my number one concern about the nature of discourse here on hacker news. The issue of "book contents" vs. real world experience. I don't know you and certainly don't mean to pick on you, but calling my criticism of Steve's article "way off base" merits this response... First a little of my…

I think that mattmcnight's point was that Yegge is criticizing an accepted definition of requirements analysis. So, edw, when you say "he doesn't respect it, probably because he doesn't know how to do it" you are a bit off base - you're referring to a practice which is different from the one matt and Yegge are talking about. But you're probably right that they aren't familiar with the kind of requirements analysis yo…

Yegge is criticizing an accepted definition of requirements analysis

So his title (Business Requirements are Bullshit) was just bait. I guess I took it.

I once wrote a hn post with a lot more "meat on the bones" about what works. Here it is:

http://news.ycombinator.com/item?id=84977

Re: Business Requirements are Bullshit

#42

Post by edw519 » Tue, Aug 12, 2008, 3:52 PM UTC

axod wrote: post #37

edw519 wrote: post #26

Earlier quoted context omitted.

If you're trying to write software for others, it's going to end up as mediocre and probably not entirely what they wanted. Stop for a minute and notice how absurd this statement is. 99.9% of all software ever written was for others. Was it all mediocre and "not entirely what they wanted"? This is the entire reason for systems analysis and requirements specification. You don't need to do any of this for the software…

99.9%? That's just insane. You're saying that all the games developers never play their own games? How about people writing languages, compilers etc. You don't think they use them?? I'd say the majority of open source software is written for yourself rather than others. People contribute the most when they are using that software. You don't have to be the only customer/user of your software, but it helps to be a cust…

There are over 800,000 programmers working in the U.S. alone, an overwhelming majority employed by someone else.

http://answers.google.com/answers/threadview/id/43888.html

I'm saying that the ERP, accounting, banking, claims processing, ecommerce, order entry, scientific, etc., etc., etc. software they work on is for someone else. They dwarf those working on games, compilers, and open source.

Welcome to the real world.

Re: Business Requirements are Bullshit

#43

Post by mechanical_fish » Tue, Aug 12, 2008, 4:03 PM UTC

edw519 wrote: post #24

mattmcknight wrote: post #11

Earlier quoted context omitted.

"You get with them and "live their lives" and suffer with them, understanding what they must accomplish, how they must do it, and what's stopping them now. " This is a great idea, and the real way to address the problem Steve suggests: Become the business. However, the majority of your criticism of Steve is way off base, because the methods he describes are not strawmen, but the actual methods described in most of th…

...actual methods described in most of the software engineering requirements books... Thank you, Matt. You have just demonstrated my number one concern about the nature of discourse here on hacker news. The issue of "book contents" vs. real world experience. I don't know you and certainly don't mean to pick on you, but calling my criticism of Steve's article "way off base" merits this response... First a little of my…

Part of the problem is that talking about the analysis process is like writing a textbook on romance. How do you fall in love? Is there a set of best practices and a six-sigma process? Well, no. It's an art. It depends entirely on the situation and on the parties involved. You get better at it with practice. There are rules of thumb that are definitely helpful, but you have to know when to break them. Unfortunately, there's also a great deal at stake: If you screw it up it can ruin your life, but if you get it right you can be happy for decades.

The literature on the subject tends to gravitate towards formal techniques: Dance instruction, sex education, grooming, fashion. Not so much because these are the essence of romance, but because they're much easier to describe in print. And because the people who turn to books are not the ones whose relationships are going well, but the ones who need help -- and when the going gets tough, formalism can be a very useful tool. Nobody consults a lawyer on a first date, but when you need a divorce formal procedures come in really handy.

Re: Business Requirements are Bullshit

#44

Post by swombat » Tue, Aug 12, 2008, 4:16 PM UTC

edw519 wrote: post #41

nonrecursive wrote: post #35

Earlier quoted context omitted.

I think that mattmcnight's point was that Yegge is criticizing an accepted definition of requirements analysis. So, edw, when you say "he doesn't respect it, probably because he doesn't know how to do it" you are a bit off base - you're referring to a practice which is different from the one matt and Yegge are talking about. But you're probably right that they aren't familiar with the kind of requirements analysis yo…

Yegge is criticizing an accepted definition of requirements analysis So his title (Business Requirements are Bullshit) was just bait. I guess I took it. I once wrote a hn post with a lot more "meat on the bones" about what works. Here it is: http://news.ycombinator.com/item?id=84977

Of course his title was bait! What else could a title like that be!? :-)

I also think that your response is off-base though. Taking your own statements:

1) Steve is wrong to call "Requirements gathering" bullshit because you know how to do it properly

2) "Requirements gathering" as taught in most accepted books and other texts is bullshit

If you then throw in:

3) Steve was referring to the "Requirements agethering" as taught in most accepted texts (and, I'll add, practiced in many large organisations).

Then we get:

4) You're referring to your own special brew of "Requirements gathering", which has little to do with what Steve was talking about!

Unfortunately, when most people say "Requirements gathering", they refer to the standard, accepted processes taught in books and large consulting companies. And those, as Steve declares, are largely bullshit. I worked in a large, process-driven IT consulting firm for 4 years, and I can affirm without a doubt that the processes they used to gather requirements would fail miserably at attempting to produce a great start-up product.

Re: Business Requirements are Bullshit

#45

Post by swombat » Tue, Aug 12, 2008, 4:19 PM UTC

edw519 wrote: post #26

axod wrote: post #18

Earlier quoted context omitted.

"In short, do whatever it takes to find out what you need to know to develop your software. This is hard work. Hardly anyone does it now, and relatively few have ever done it. Steve Yegge certainly hasn't" For me, the point Steve makes is that the optimum is to build for yourself. The feedback loop is instant. That's where the best software gets written. When developers wake up at 3am with some idea for a feature tha…

If you're trying to write software for others, it's going to end up as mediocre and probably not entirely what they wanted. Stop for a minute and notice how absurd this statement is. 99.9% of all software ever written was for others. Was it all mediocre and "not entirely what they wanted"? This is the entire reason for systems analysis and requirements specification. You don't need to do any of this for the software…

99.9% of all software ever written was for others. Was it all mediocre and "not entirely what they wanted"?

Having lived and breathed (and somehow survived) in the enterprise environment that employs the vast majority of the programmers out there, I can agree with that proposition whole-heartedly.

Yes, 99.9% of the software that gets written is mediocre at best. A shockingly large proportion of it is downright abysmal, but most of it is mediocre. Thankfully, we don't get to see most of that software since it is safely locked away inside the mega-corporations that pay hordes of programmers to write it.

Re: Business Requirements are Bullshit

#46

Post by axod » Tue, Aug 12, 2008, 4:26 PM UTC

edw519 wrote: post #42

axod wrote: post #37

Earlier quoted context omitted.

99.9%? That's just insane. You're saying that all the games developers never play their own games? How about people writing languages, compilers etc. You don't think they use them?? I'd say the majority of open source software is written for yourself rather than others. People contribute the most when they are using that software. You don't have to be the only customer/user of your software, but it helps to be a cust…

There are over 800,000 programmers working in the U.S. alone, an overwhelming majority employed by someone else. http://answers.google.com/answers/threadview/id/43888.html I'm saying that the ERP, accounting, banking, claims processing, ecommerce, order entry, scientific, etc., etc., etc. software they work on is for someone else. They dwarf those working on games, compilers, and open source. Welcome to the real worl…

Where did I say you have to not be employed by someone else??? That's pretty much irrelevant.

Re: Business Requirements are Bullshit

#47

Post by Retric » Tue, Aug 12, 2008, 4:44 PM UTC

stcredzero wrote: post #34

Retric wrote: post #16

Earlier quoted context omitted.

If you don't eat their sandwiches, then you'd better have a LOT of friends who eat them every day, or you're breaking the cardinal rule The point of that long winded article is don't build something unless you are going to use the product or personaly know a lot of people who will. Never ask people you don't know what they want it's stupid. Take the segway it's cool but it's clearly something people want in the abstr…

An example of the opposite as a datapoint: We've all eaten institutional food cooked by people who are following a recipe they may not particularly care a whole lot about and probably won't eat their own cooking.

We are developers so I think the question is the rate of adoption of new recipe's at McDonalds? They are spending money on new recipe's and advertising them etc but how many of there new ideas catch and are still in use in 5-10 years? And how many of the successes are based on what someone wants to eat vs. what they think other people might buy.

Re: Business Requirements are Bullshit

#48

Post by Retric » Tue, Aug 12, 2008, 4:54 PM UTC

edw519 wrote: post #42

axod wrote: post #37

Earlier quoted context omitted.

99.9%? That's just insane. You're saying that all the games developers never play their own games? How about people writing languages, compilers etc. You don't think they use them?? I'd say the majority of open source software is written for yourself rather than others. People contribute the most when they are using that software. You don't have to be the only customer/user of your software, but it helps to be a cust…

There are over 800,000 programmers working in the U.S. alone, an overwhelming majority employed by someone else. http://answers.google.com/answers/threadview/id/43888.html I'm saying that the ERP, accounting, banking, claims processing, ecommerce, order entry, scientific, etc., etc., etc. software they work on is for someone else. They dwarf those working on games, compilers, and open source. Welcome to the real worl…

Most: ERP, accounting, banking, claims processing, ecommerce, order entry software sucks.

Scientific software is often started by someone who uses it and tends to work well.

Re: Business Requirements are Bullshit

#49

Post by joshwa » Tue, Aug 12, 2008, 5:17 PM UTC

sapphirecat wrote: post #19

stcredzero wrote: post #8

One of the biggest, most consistent problems I saw as a Smalltalk consultant was simply poor communication between development and users . There were inevitably at least two groups or levels of management in the same group between the users and development. The result was always the game of "telephone" or "gossip" -- the one where you form a line and one person whispers a message to the next. Information, filtered th…

> But the right way to do it is to have smart actual users talking directly to smart actual devs. I find in my own software that the best thing to do, if you're improving an existing process, is to watch (or participate in) the current process, with an eye toward the parts which waste time or irritate people. In any case, after the initial study, it's crucial to back out of the details of the process and think about…

Of course, that assumes you are actually permitted to change the process. The project I'm working on has the constraint that while we are allowed to write less-buggy software that catpures the existing process more effectively, we are not allowed to propose changes to the existing process (which evolved around the existing cruddy software-- 10 years of accumulated process and "feature" cruft, now cast in carbonite).

Corporations sometimes have a funny definition of "risk." Sometimes, Risk(changing to a sane process) < Risk(reproducing unnecessary complexity of existing process).

Re: Business Requirements are Bullshit

#50

Post by michael_dorfman » Tue, Aug 12, 2008, 5:21 PM UTC

axod wrote: post #40

michael_dorfman wrote: post #29

Earlier quoted context omitted.

Because I may not be in the same line of business as my users. For example, my last start-up develops planning software for large agricultural firms. I don't happen to manage a large agricultural firm, nor am I likely to manage one in the near future. Still think I should be using my own product day in day out?

Ideally yes. Go work for one for a year, then create the software... Of course this isn't always possible, but it's the way to better products.

I'm not saying that on-the-job experience is a bad thing-- clearly it isn't-- but as you say, it isn't always possible, and it's still a long way from creating software for you yourself to use.

Put another way: I'm not the target user of any of the most valuable (or most lucrative) software I've created-- and I don't think that's a rare condition.