Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Business Requirements are Bullshit

steve-yegge.blogspot.com

Post reply on HN
Print view View original

51–60 of 87 posts

Re: Business Requirements are Bullshit

#51

Post by edw519 »

Retric wrote: post #48
edw519 wrote: post #42

Earlier quoted context omitted.

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.

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

You're probably right about that.

But enough of it works to run the world. No small feat.

Re: Business Requirements are Bullshit

#52

Post by akeefer »

I'd like to point out that this article completely ignores most specialty or enterprise markets. As a maker of insurance software, we employ some people who were former insurance agents/adjusters, but none of our developers are, and our only real hope for understanding exactly what has to go into something like a policy administration system is to get out there and talk to customers and potential customers. Even within an insurance company, the developers still won't have a clue because it's not a product they themselves would ever use, and they'll have to rely on someone else communicating the requirements to them.

The same is probably true of just about any other business-focused software; most developers aren't hedge-fund traders, auto mechanics, laywers, hotel managers, etc. yet somehow people manage to build specialized software for those fields. You need people in the organization that understand those fields and what's involved, but the motto of "make something you yourself want" just doesn't apply when you're writing software to run an entirely different kind of business. Developers can be mountain bikers on the weekends, but they're generally not insurance agents or doctors in their spare time.

Re: Business Requirements are Bullshit

#53

Post by stcredzero »

michael_dorfman wrote: post #36
stcredzero wrote: post #31

Earlier quoted context omitted.

Nope, but if you can, hang out with the actual users jockeying the software as often as you can. I know that I learn something new almost every time I go out on the trading floor and have a user walk me through the software I'm writing and fixing.

Absolutely! And that was my point-- you need to understand the user's problem-space very well, and there are better ways to do this than the traditional "business requirements gathering" process, which tends to focus on the (sub-optimal) solution the users have already imagined.

It shouldn't be "business requirements gathering." It should be "business requirements refinement."

Re: Business Requirements are Bullshit

#54

Post by aneesh »

axod wrote: post #13
michael_dorfman wrote: post #5

He raises many good points in the course of the rant, but I think that "only build for yourself" goes a bit too far than most of us are willing to go. I'd suggest, in the spirit of compromise, that "gathering (and understanding) business problems" is a better practice than gathering requirements, as user-proposed solutions (and the requirements which make them up) are often doomed to failure.

Why is only building for yourself a bit too far? This seems like common sense to me. If you're not using your own product day in day out, you should be.

Because then PG wouldn't have built Viaweb. He certainly wasn't building it for himself.

Re: Business Requirements are Bullshit

#56

Post by stcredzero »

signa11 wrote: post #39
stcredzero wrote: post #9

Earlier quoted context omitted.

Linus has an easier task. The hardware the kernel runs on and the software running on it act as an ironclad, rigorously defined spec. Dealing with human users is something else.

not really true. what would you say about git ? it has no kernel components, no spec (at least not that i am aware of).

Linus wrote git for himself.

Re: Business Requirements are Bullshit

#57

Post by bbgm »

Steve has obviously never had to develop software for the life science industry. My response to any such post is simple. It depends. It depends on the kind of application, for what kind of market, etc.

I've seen more than my share of applications done in the "this is how I would use it" fashion and the results have been disastrous. I am sure there are examples, perhaps a first take or prototype that reflects what your ideal it and then you whet it with people out in the market, but you have to ask yourself "what problem am I trying to solve?". You have to ask yourself (cause if you don't someone else will) the "so what" question.

It's not about the process, which is where a lot of requirements gather bogs down (IMO, every time you talk with a current or potential user, or even a hater you are collecting requirements). It's about really caring about the problems you are trying to solve and why someone would care about the way you want to solve it.

Re: Business Requirements are Bullshit

#58

Post by jimbokun »

mechanical_fish wrote: post #43
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…

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,…

"How do you fall in love? Is there a set of best practices and a six-sigma process?"

I don't know, but "The Six-sigma Process for Romance; Taking the Guesswork out of Finding Love" sounds like the title of a New York Times Bestseller to me.

Re: Business Requirements are Bullshit

#59

Post by jimbokun »

swombat wrote: post #44
edw519 wrote: post #41

Earlier quoted context omitted.

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" a…

I think Yegge goes beyond that, though. He presents "make something you, yourself, want" as the key to making something others want. If I understand edw519 correctly, he is saying "bust your butt and do a lot of very hard work to see the world through your customers eyes," in order to to make something others want.

Re: Business Requirements are Bullshit

#60

Post by jimbokun »

axod wrote: post #18
edw519 wrote: post #6

I have read Steve's articles before with a certain amount of respect, but this time he addresses an area very near and dear to me, and all I can say about this one is: I call bullshit. This article was so full of it, the more I read, the more I had to change into higher waders. As I normally do when responding to a post, I started pulling out the statements I wanted to respond to, highlighting them, and putting my re…

"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…

The Apple process seems to be "make something Steve Jobs wants."

It seems to work pretty well.

Post reply on HN