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...
Business Requirements are Bullshit
21–30 of 87 posts
Re: Business Requirements are Bullshit
#22this ( http://kerneltrap.org/node/5725 ) is soo much better.
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 ) 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.
Re: Business Requirements are Bullshit
#23Good 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?
Re: Business Requirements are Bullshit
#24I 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 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 background. Even though I've been a hacker my entire professional life, I had the good fortune to be mentored by an industrial engineer from a user department. He did one thing extrememly well and taught me how to do it: solve business problems to make money. This is the stuff that is rarely taught in any book, much less one that is "considered by many to be a leading reference on the subject".
Shocking as it may seem, many books on business systems and IT offer very little and many are simply wrong.
I have not read Karl Wieger's book and feel out of place evaluating it. However, I did read the synopsis and all 45 reviews on Amazon. Nowhere did I see mention of any of the things from my OP that I know work every time. Instead I saw lots of mention of techniques like rational rose, entity-relationship diagrams, use cases, and modeling. As anyone who has successfully conducted analysis will tell you, these techniques were never actually designed to achieve results; their purpose is to control the people and the process, not the outcome.
I stand by my original criticism of Steve's article. He is dead wrong about analysis. He doesn't respect it, probably because he doesn't know how to do it. Your comment makes me wonder if the same holds true for you.
Re: Business Requirements are Bullshit
#25One 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…
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.
Re: Business Requirements are Bullshit
#26I 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…
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 you're writing for yourself. You must do all of it and do it well when writing software for others; that's how you insure that it's exactly what they want.
Re: Business Requirements are Bullshit
#27Over 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.
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.
Re: Business Requirements are Bullshit
#28Over 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.
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.
Over-complicated is the same thing as too complicated, which does not put a limit on how complicated a system can be.
Re: Business Requirements are Bullshit
#29He 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 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?
Re: Business Requirements are Bullshit
#30Earlier 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…
I interpret the post as just a long rantish way of saying: "If you want to write good software, you've also got to use it."
In my experience, there is a lot of software out there that is deemed valuable by management, produces good ROI, but is despised in some way by its users. I'd say the majority of it. (And I've been in many dozens of shops as a consultant.) That will fly for internal software for a big company, but not for a web startup.
Another way of saying it: really doing "systems analysis and requirements" right puts you in the user's shoes. That's the part that matters, not the artifacts produced by the process. (I'm preaching to the choir here, I know.) In fact, the "systems analysis and requirements" process matters not a bit, only the result, which should be getting the real user experience into the heads of development.