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

11–20 of 87 posts

Re: Business Requirements are Bullshit

#11

Post by mattmcknight »

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…

"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 the software engineering requirements books. If you look at Karl Wiegers book, Software Requirements, which is considered by many to be a leading reference on the subject, it describes a process much like the one Yegge criticizes.

Re: Business Requirements are Bullshit

#13

Post by axod »

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.

Re: Business Requirements are Bullshit

#14

Post by [deleted] »

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…

[deleted]

Re: Business Requirements are Bullshit

#15

Post by axod »

prakash wrote: post #12

can someone provide a cliff's note version of what Yegge wrote? I tried reading what he wrote, but there is too much rambling.

Don't try to find out what potential customers might want, just build something where you are a potential customer - Build for yourself.

That's what I took from it anyway :/

Re: Business Requirements are Bullshit

#16

Post by Retric »

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

I'll second that call. Formula for blog entry: 1) Pick an area that most newbies don't get (ie, requirements) 2) Blather on for a while about all the ways they are done wrong 3) Miss the point of the topic. In requirements, you list what you do, then do it. Instead confuse key terms, like "user" and "customer", or "grill" with "be immersed in" 4) Try to be funny 5) Make sweeping conclusions that are obviously incompl…

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 abstract even if it's not useful 99% of the time which is the type of thing you build when you ask people what they want without having any idea what you want to build.

Re: Business Requirements are Bullshit

#18

Post by axod »

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 that would make the software they want, work better.

If you're trying to write software for others, it's going to end up as mediocre and probably not entirely what they wanted.

Re: Business Requirements are Bullshit

#19

Post by sapphirecat »

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 the overall goal to be accomplished. You don't want to waste effort evolving a process that's been badly distorted by existing software, when you could simplify the process immensely by writing something directly focused on the actual goal. This is an intensely creative/intuitive phase of the process, so it often takes several iterations (from a fresh state-of-mind each time).

Once you think have the perfect solution, go back and make sure that it solves all the problems noted in step 1. If it doesn't, try again.

Post reply on HN