6 ms·

Business Requirements are Bullshit

116 points by mqt 18y ago

signa11 18y ago
this (http://kerneltrap.org/node/5725 http://kerneltrap.org/node/5725) is soo much better.
- ojbyrne 18y ago
  More succinct, yes, interesting too, but I'd disagree with "better." It's like saying an apple is better than an orange.
  - stcredzero 18y ago
    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.
    - signa11 18y ago
      not really true. what would you say about git ? it has no kernel components, no spec (at least not that i am aware of).
      - stcredzero 18y ago
        Linus wrote git for himself.
- dcminter 18y ago
  Interesting link. It's amusing that in the comments someone cites SCSI as proof that coding to a standard can be sufficient. The trade association holds "plugfests" ( e.g. http://www.scsita.org/news_events/plugfests/plugfests.html http://www.scsita.org/news_events/plugfests/plugfests.html ) specifically because coding to standards isn't sufficient and sometimes you have to actually try the things out with other peoples' hardware to find out if things actually work properly.
- gaius 18y ago
  Wow. I guess this is why Linux RAID sucked so badly for so long.
bdfh42 18y ago
I think that Mr. Yegge missed the real question - but the rant was worth it. I particularly liked "The easiest way to build a product that kicks ass is to start with someone else's great idea (camcorders, for instance), and take stuff away." I suspect what the "business correspondent" wanted to know was something more like: "My customer wants me to build him a new billing system. Their top managers have some defined strategic objectives but no-one I have met seems to actually know what this system should do in any detail. However, they can all detail the bad things that would happen if it did not do (whatever it is) perfectly from day one. Now how do I find out what to build them?" Now that question is the one that development teams face every day.
- mattmcknight 18y ago
  And would the answer then be, join the billing the team for while, learn their processes, and then build a system to make your job better and provide value to the project sponsor.
michael_dorfman 18y ago
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.
- axod 18y ago
  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.
  - michael_dorfman 18y ago
    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?
    - stcredzero 18y ago
      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.
      - michael_dorfman 18y ago
        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.
        18y ago
edw519 18y ago
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 response below. After 10 minutes, I had the Magna Carta. This is simply too much wrong with this article to respond in the usual way. So instead, I'll just say this... Get this and get this good, fellow hackers: When anyone says "analysis" or "requirements gathering" is bullshit, there can only be one reason why: they don't know how to do it. Sure, there are antecdotes and case studies of people building great software without talking to users first, but they are in the extreme minority, and anyone proposing doing this all the time is doing a disservice to his readers. In order to find out what people need from software, you don't "grill" them, "interview" them, or "role play" (whatever that means). 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. How do you do this? Any way you can. Change uniforms and shovel shit with them. Do their job for a day. Put them together in a room, feed them, give them beer (optional), and get them to bitch about it. Identify every single data element related to their tasks. Connect tasks and data to objectives (You may find that half of what they already do is a waste of time.) 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. If he had, the data in this rant would have been very different. Sorry, Steve, I normally enjoy your columns. Do us all a favor and don't say something can't be done because you've never done it. Next time, write about something you've already done. Then we can all resume learning from you again.
- DanielBMarkham 18y ago
  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 incomplete in the real world "Code only for yourself" -- so everybody with a need now has to have a programmer with the same exact need? Wow. 6) Throw in some generally accepted wisdom ("find something good and take stuff out") as a way of tossing the crowd a bone 7) Profit! As a general rule of thumb, if somebody comes to you with a common phrase from software engineering and makes a sweeping statement (a friend just blogged "reviews are worthless!") then they are either pulling your leg a little bit or don't know what the heck they are talking about. The usual method of attack is to describe how something is commonly done and then disparage the concept by way of association.
stcredzero 18y ago
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 through too many minds always gets distorted in the process. I think you can do requirements gathering. But the right way to do it is to have smart actual users talking directly to smart actual devs. Even here, there is a chance for misunderstanding, but at least it's not compounded. (I suspect that the "telephone" game is an example of a nonlinear exponential process.) Unfortunately, middle managers defending their personal fiefdom will sometimes actually tell you that it's specifically not going to happen. In large organizations, upper management generally wants their representative to be the filter between the devs and the users, because software is generally an instrument of control. (Through workflow, even if the app has no explicit workflow framework, but that's another story.) Often in large organizations with a software project, devs and users will find some way to get together and talk face to face. It's a sign.
- sapphirecat 18y ago
  > 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.
  - stcredzero 18y ago
    By "talking directly" I mean going to the floor where the software is actually used and hanging out with the users. The bandwidth is so much higher. Talking to them in a meeting room with no computer is almost a complete waste of time.
corentin 18y ago
We, the hoi polloi developers, work for industries (retail, transportation, insurance, etc.) we hopefully know some thing about, yet without having the same level of expertise (or even the same point of view) as our customers. He should get himself familiar with the concept of division of labor...
prakash 18y ago
can someone provide a cliff's note version of what Yegge wrote? I tried reading what he wrote, but there is too much rambling.
- axod 18y ago
  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 :/
- stcredzero 18y ago
  "Eat your own cooking."
maxklein 18y ago
Over complicated business requirements are bullshit. But starting a product without researching first is a recipe for disaster, particularly if you are entering a crowded market.
- edw519 18y ago
  Over complicated business requirements are bullshit. What if the requirements are complicated? Go ahead and develop an arbitrage system, a medical claims processing system, or a repetitive shop floor control system without "complicated enough" requirements and see how far you get.
  - maxklein 18y ago
    Over-complicated is the same thing as too complicated, which does not put a limit on how complicated a system can be.
    - mattmcknight 18y ago
      Over-complicated is also a tough guideline to follow, because how do you when you have "too much" complexity?
  - bmj 18y ago
    My sense is that to someone outside the industry, such requirements would seem overly complicated. A few years ago, I worked for a company that did patient management software (including billing). In the effort to get the product to market, they neglected documenting the requirements of the billing portion. Over time, because of the requirements of our each of customers were different (depending on what entity they billed, the rules for the billing were different), the application turned into a mess of stuff that was never well-documented (fortunately, I didn't work on the billing app). Had they done a bit business requirements gathering before building, they could have likely saved time and money by designing more flexible software. It's also worth noting that this wasn't some big, lumbering corporation--it was a start-up.
deleted 18y ago
[deleted]
pongle 18y ago
Hmm, I'm not convinced about the "only build what you are going to use" argument. The best example I can think of is pace-makers (or any other form of life-saving equipment). A manufacturer of these devices cannot be a user, because they'd be dead...
- stcredzero 18y ago
  I'll bet that a pacemaker embedded software developer who personally knew patients with a pacemaker and hung out with them every day would be a whole lot more motivated.
  - astine 18y ago
    Just to add to that: I imagine that the makers of the first pacemakers were doctors who were better in tune with the need than the patients. In fact, I'm pretty sure that doctor, not the patient, really counts as the target market. He's the one the diagnoses the problem (and understands the need); he's the one that actually orders the devices; he's the one that actually orders the devices. The patient generally only needs to know that he needs one, and that it's going to be installed. In the same vein, I'll bet that if actual accountants were to design a piece of accounting software, it would probably rock pretty hard. (Assuming of course, that the accountants in question were also competent designers/developers.)
- jimbokun 18y ago
  "A manufacturer of these devices cannot be a user, because they'd be dead..." Well, unless you're Tony Stark.
biohacker42 18y ago
Good rant, but I want to talk about dog poop. Surely there must be an enzyme cocktail that can evaporate poop! You would not use it indoors, only for outdoor use. But there must be something that will decompose dog poo super fast. Any organic chemists here?
- kirubakaran 18y ago
  Genetically engineered dogs that excrete sealed tubes will put you out of business.
  - Leon 18y ago
    Robot dogs will put you out of business.
    - whatusername 18y ago
      Virtual Reality (plus an exercise pill) will put you out of business. It doesn't mean that there isn't money to be made each step of the way.
- Tichy 18y ago
  Genetically modified flies?
akeefer 18y ago
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.
- gcv 18y ago
  True enough. I deal with "enterprise" software all the time, and I found that it is all horrific. Terrible UIs, almost invariably terrible performance, chronic instability. I'm afraid that, if Steve is right and that to build something good it must be built for the builder, there will never be good "enterprise" software. Also: requirement gathering in that market is just as frustrating as Steve says it is in the consumer market. I've dealt with lots of people who ask for features and then change their minds or realize they didn't really know what they wanted.
- mattmcknight 18y ago
  "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.
bbgm 18y ago
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.
tidra14 18y ago
I think what the article was saying is: Use common sense And: People do not know what they want, or to be more precise, decisions of liking or not liking something are made seconds before the person becomes concious of their choice, so most of the people's desires are subconscious and what they say they like is simply a justification and not their true wants. (which has been proven through psychology research) Of course both the advices are sound, but man what awful and utterly terrible writing. The guy is patronising, his speech is in your face and he has no consideration whatsoever for my time. He babbles and rambles about useless stuff when I simply want to get to the point of what he is saying and move on. So to give him a bit of his own medicine, was he actually writing for himself? Or was he writing for others? The answer is rhetorical of course, he knows his stuff so there's no need to write what he knows unless it is aimed at others. So he is not writing about himself he is writing about others. Now that he wrote for others was his writing mediocre? Perhaps, I certainly think so, but was it how should I put it, popular? Well 64 comments from fellow hackers, loads more in his own blogg, probably loads of nutters linked to it. So would he care to define mediocre? I just do not know how anyone can read his blog to be honest. Hello by the way, my very first comment, I'm Andrew, Nice to meet you all :)
Jaytee 18y ago
I'm gonna quote Bruce Lee and apply it to everything here. "Take what's essential, discard the unnecessary, and make it your own." That's the point I got from Steve's post. And that's how I dealt with his rambling. Meta-great post.
misterbwong 18y ago
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.
randome 18y ago
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.

116 points by mqt 18y ago

signa11 18y ago

this (http://kerneltrap.org/node/5725 http://kerneltrap.org/node/5725) is soo much better.

ojbyrne 18y ago
More succinct, yes, interesting too, but I'd disagree with "better." It's like saying an apple is better than an orange.
- stcredzero 18y ago
  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.
  - signa11 18y ago
    not really true. what would you say about git ? it has no kernel components, no spec (at least not that i am aware of).
    - stcredzero 18y ago
      Linus wrote git for himself.
dcminter 18y ago
Interesting link. It's amusing that in the comments someone cites SCSI as proof that coding to a standard can be sufficient. The trade association holds "plugfests" ( e.g. http://www.scsita.org/news_events/plugfests/plugfests.html http://www.scsita.org/news_events/plugfests/plugfests.html ) specifically because coding to standards isn't sufficient and sometimes you have to actually try the things out with other peoples' hardware to find out if things actually work properly.
gaius 18y ago
Wow. I guess this is why Linux RAID sucked so badly for so long.

bdfh42 18y ago

I think that Mr. Yegge missed the real question - but the rant was worth it. I particularly liked "The easiest way to build a product that kicks ass is to start with someone else's great idea (camcorders, for instance), and take stuff away." I suspect what the "business correspondent" wanted to know was something more like: "My customer wants me to build him a new billing system. Their top managers have some defined strategic objectives but no-one I have met seems to actually know what this system should do in any detail. However, they can all detail the bad things that would happen if it did not do (whatever it is) perfectly from day one. Now how do I find out what to build them?" Now that question is the one that development teams face every day.

mattmcknight 18y ago
And would the answer then be, join the billing the team for while, learn their processes, and then build a system to make your job better and provide value to the project sponsor.

michael_dorfman 18y ago

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.

axod 18y ago
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.
- michael_dorfman 18y ago
  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?
  - stcredzero 18y ago
    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.
    - michael_dorfman 18y ago
      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.
      - 18y ago

edw519 18y ago

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 response below. After 10 minutes, I had the Magna Carta. This is simply too much wrong with this article to respond in the usual way. So instead, I'll just say this... Get this and get this good, fellow hackers: When anyone says "analysis" or "requirements gathering" is bullshit, there can only be one reason why: they don't know how to do it. Sure, there are antecdotes and case studies of people building great software without talking to users first, but they are in the extreme minority, and anyone proposing doing this all the time is doing a disservice to his readers. In order to find out what people need from software, you don't "grill" them, "interview" them, or "role play" (whatever that means). 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. How do you do this? Any way you can. Change uniforms and shovel shit with them. Do their job for a day. Put them together in a room, feed them, give them beer (optional), and get them to bitch about it. Identify every single data element related to their tasks. Connect tasks and data to objectives (You may find that half of what they already do is a waste of time.) 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. If he had, the data in this rant would have been very different. Sorry, Steve, I normally enjoy your columns. Do us all a favor and don't say something can't be done because you've never done it. Next time, write about something you've already done. Then we can all resume learning from you again.

DanielBMarkham 18y ago
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 incomplete in the real world "Code only for yourself" -- so everybody with a need now has to have a programmer with the same exact need? Wow. 6) Throw in some generally accepted wisdom ("find something good and take stuff out") as a way of tossing the crowd a bone 7) Profit! As a general rule of thumb, if somebody comes to you with a common phrase from software engineering and makes a sweeping statement (a friend just blogged "reviews are worthless!") then they are either pulling your leg a little bit or don't know what the heck they are talking about. The usual method of attack is to describe how something is commonly done and then disparage the concept by way of association.

stcredzero 18y ago

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 through too many minds always gets distorted in the process. I think you can do requirements gathering. But the right way to do it is to have smart actual users talking directly to smart actual devs. Even here, there is a chance for misunderstanding, but at least it's not compounded. (I suspect that the "telephone" game is an example of a nonlinear exponential process.) Unfortunately, middle managers defending their personal fiefdom will sometimes actually tell you that it's specifically not going to happen. In large organizations, upper management generally wants their representative to be the filter between the devs and the users, because software is generally an instrument of control. (Through workflow, even if the app has no explicit workflow framework, but that's another story.) Often in large organizations with a software project, devs and users will find some way to get together and talk face to face. It's a sign.

sapphirecat 18y ago
> 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.
- stcredzero 18y ago
  By "talking directly" I mean going to the floor where the software is actually used and hanging out with the users. The bandwidth is so much higher. Talking to them in a meeting room with no computer is almost a complete waste of time.

corentin 18y ago

We, the hoi polloi developers, work for industries (retail, transportation, insurance, etc.) we hopefully know some thing about, yet without having the same level of expertise (or even the same point of view) as our customers. He should get himself familiar with the concept of division of labor...

prakash 18y ago

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

axod 18y ago
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 :/
stcredzero 18y ago
"Eat your own cooking."

maxklein 18y ago

Over complicated business requirements are bullshit. But starting a product without researching first is a recipe for disaster, particularly if you are entering a crowded market.

edw519 18y ago
Over complicated business requirements are bullshit. What if the requirements are complicated? Go ahead and develop an arbitrage system, a medical claims processing system, or a repetitive shop floor control system without "complicated enough" requirements and see how far you get.
- maxklein 18y ago
  Over-complicated is the same thing as too complicated, which does not put a limit on how complicated a system can be.
  - mattmcknight 18y ago
    Over-complicated is also a tough guideline to follow, because how do you when you have "too much" complexity?
- bmj 18y ago
  My sense is that to someone outside the industry, such requirements would seem overly complicated. A few years ago, I worked for a company that did patient management software (including billing). In the effort to get the product to market, they neglected documenting the requirements of the billing portion. Over time, because of the requirements of our each of customers were different (depending on what entity they billed, the rules for the billing were different), the application turned into a mess of stuff that was never well-documented (fortunately, I didn't work on the billing app). Had they done a bit business requirements gathering before building, they could have likely saved time and money by designing more flexible software. It's also worth noting that this wasn't some big, lumbering corporation--it was a start-up.

deleted 18y ago

[deleted]

pongle 18y ago

Hmm, I'm not convinced about the "only build what you are going to use" argument. The best example I can think of is pace-makers (or any other form of life-saving equipment). A manufacturer of these devices cannot be a user, because they'd be dead...

stcredzero 18y ago
I'll bet that a pacemaker embedded software developer who personally knew patients with a pacemaker and hung out with them every day would be a whole lot more motivated.
- astine 18y ago
  Just to add to that: I imagine that the makers of the first pacemakers were doctors who were better in tune with the need than the patients. In fact, I'm pretty sure that doctor, not the patient, really counts as the target market. He's the one the diagnoses the problem (and understands the need); he's the one that actually orders the devices; he's the one that actually orders the devices. The patient generally only needs to know that he needs one, and that it's going to be installed. In the same vein, I'll bet that if actual accountants were to design a piece of accounting software, it would probably rock pretty hard. (Assuming of course, that the accountants in question were also competent designers/developers.)
jimbokun 18y ago
"A manufacturer of these devices cannot be a user, because they'd be dead..." Well, unless you're Tony Stark.

biohacker42 18y ago

Good rant, but I want to talk about dog poop. Surely there must be an enzyme cocktail that can evaporate poop! You would not use it indoors, only for outdoor use. But there must be something that will decompose dog poo super fast. Any organic chemists here?

kirubakaran 18y ago
Genetically engineered dogs that excrete sealed tubes will put you out of business.
- Leon 18y ago
  Robot dogs will put you out of business.
  - whatusername 18y ago
    Virtual Reality (plus an exercise pill) will put you out of business. It doesn't mean that there isn't money to be made each step of the way.
Tichy 18y ago
Genetically modified flies?

akeefer 18y ago

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.

gcv 18y ago
True enough. I deal with "enterprise" software all the time, and I found that it is all horrific. Terrible UIs, almost invariably terrible performance, chronic instability. I'm afraid that, if Steve is right and that to build something good it must be built for the builder, there will never be good "enterprise" software. Also: requirement gathering in that market is just as frustrating as Steve says it is in the consumer market. I've dealt with lots of people who ask for features and then change their minds or realize they didn't really know what they wanted.
mattmcknight 18y ago
"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.

bbgm 18y ago

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.

tidra14 18y ago

I think what the article was saying is: Use common sense And: People do not know what they want, or to be more precise, decisions of liking or not liking something are made seconds before the person becomes concious of their choice, so most of the people's desires are subconscious and what they say they like is simply a justification and not their true wants. (which has been proven through psychology research) Of course both the advices are sound, but man what awful and utterly terrible writing. The guy is patronising, his speech is in your face and he has no consideration whatsoever for my time. He babbles and rambles about useless stuff when I simply want to get to the point of what he is saying and move on. So to give him a bit of his own medicine, was he actually writing for himself? Or was he writing for others? The answer is rhetorical of course, he knows his stuff so there's no need to write what he knows unless it is aimed at others. So he is not writing about himself he is writing about others. Now that he wrote for others was his writing mediocre? Perhaps, I certainly think so, but was it how should I put it, popular? Well 64 comments from fellow hackers, loads more in his own blogg, probably loads of nutters linked to it. So would he care to define mediocre? I just do not know how anyone can read his blog to be honest. Hello by the way, my very first comment, I'm Andrew, Nice to meet you all :)

Jaytee 18y ago

I'm gonna quote Bruce Lee and apply it to everything here. "Take what's essential, discard the unnecessary, and make it your own." That's the point I got from Steve's post. And that's how I dealt with his rambling. Meta-great post.

misterbwong 18y ago

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.

randome 18y ago

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.