Business Requirements are Bullshit • Hacker News Board

Re: Business Requirements are Bullshit

#81

Post by jon_dahl » Wed, Aug 13, 2008, 3: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…

I think there's a difference between an engineer working for someone, and the person making the product decision. If you're a developer for a software company building accounting software, and you don't have much use for accounting software personally, you're probably fine. But if you're defining the product, you're much better off if you've been a user of accounting software in the past.

Re: Business Requirements are Bullshit

#82

Post by mattmcknight » Wed, Aug 13, 2008, 3:40 PM UTC

akeefer wrote: post #52

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

"most developers aren't hedge-fund traders, auto mechanics, laywers, hotel managers, etc. yet somehow people manage to build specialized software for those fields. "

But imagine how much better the software will be when the developers know as much as hedge-fund traders, auto mechanics, etc. If you look at a book like Martin Fowler's Analysis Patterns, you realize that a deep understanding of the domain is crucial to building a good model to support it.

Re: Business Requirements are Bullshit

#83

Post by stcredzero » Wed, Aug 13, 2008, 4:06 PM UTC

joshwa wrote: post #49

sapphirecat wrote: post #19

Earlier quoted context omitted.

> 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).…

True story: A friend of mine wrote software for NASA. There was an old control system for something that had as its interface a 9 key keypad a numeric readout and something like an enter key. The system was modernized, and its software was ported to Unix workstations. However, to keep it compatible with the operations manuals, the new GUI interface just simulated the keypad and numeric readout.

(This is not software that my friend wrote. He ported the "numerical integrator" program used to track the Space Shuttle in orbit and calculate abort trajectories during launch. And yes, he showed me the program with the keypad! Another thing: as I was walking around at JSC, I saw a "Unix for Dummies" book back there!)

Re: Business Requirements are Bullshit

#84

Post by misterbwong » Wed, Aug 13, 2008, 4:07 PM UTC

After reading the discussion, is anybody else wondering why does this have to be so hard?

There has _got_ to be a better way to find out what the user really wants. Tools like balsamiq are a start, but it seems like this is a HUGE area that needs improvement.

Re: Business Requirements are Bullshit

#85

Post by Spyckie » Wed, Aug 13, 2008, 5:59 PM UTC

jimbokun wrote: post #59

swombat wrote: post #44

Earlier quoted context omitted.

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.

'Make something you yourself want' is what I would recommend to hackers in general.

No offense to them, but when it comes to understanding what others want, they aren't able to do it, and often lament, criticize, put down, or devalue other people's actions or responses that don't make sense (instead of trying to understand them). For instance, many hackers can't fathom why so many people use Facebook (and don't try to understand that target population, but just ignore it or write a blog post about how Facebook has no value to them).

If you have the ability (and I really think it is a skill that you have to train) to understand other people and their motivations and needs, then I would suggest doing what edw is saying. But, from experience trying to teach my own hacker friends, this ability is very hard to learn.

Unfortunately for hackers, making what they themselves want often only caters to a small niche market in the vast world of people out there, so it might be useful to invest some time in learning how to understand other people, or team up with someone who has that ability in one form or the other.

Re: Business Requirements are Bullshit

#86

Post by randome » Wed, Aug 13, 2008, 7:38 PM UTC

His post is bullshit, opensource software sucks for this reason ... its built by a bunch of hackers that don't know anything about interaction design or what customers want and need, don't know much about much of anything other than the technical.

Its great when the users are all techies ... but in my opinion most of the desktop apps suck ... openoffice is a piece of shit.

I totally agree with edw519 ... this guy just doesn't know what a product developer does or how to do it. Contrary to the elitist hacker opinion that these people don't know what they are doing ... effective, methodological product developer actually do contribute significantly to finding out what people want. A lot of programmers need to let go of their egos and realize that they are not know-it-alls.

Re: Business Requirements are Bullshit

#87

Post by thwarted » Thu, Aug 14, 2008, 10:49 PM UTC

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…

At a previous job, I was tasked with automating an industry that had not seen much automation at all. I was told that we had someone in-house who "knew the industry" and "could be used as a resource", but this person was only ever on one side of the transaction, and that side wasn't the majority of the process we were trying to automate (it was like trying to computerize a retail checkout process and your "expert" was someone who had only ever waited in line to pay).

When I said I'd like at least a month to actually go and do the jobs of the people and companies in the target demographic, I was told we didn't have time for that.