So I haven't written a post in a while, but no, that's not the reason for the title. I've just been concentrating on other things and haven't felt sufficiently motivated to write about anything.
But then I read this post from Steve Yegge on Stevey's Blog Rants. His title was "Business Requirements are Bullshit" which, while clearly designed to catch the eye, doesn't entirely represent what it was about.
Steve's post was aimed at people developing a new (or better) product to take to market. He wasn't talking to consultants or employees who are producing something to meet a specific company's business needs, but someone who was creating something new to fill a perceived hole in the market.
His point (adapted from Warren Buffet) was that you should build something you already know about; something that actually meets your needs. If you're doing that, then you already know what you want. You know what compromises you can make and what the unspoken and tacit deal-breakers are. If you're trying to gather business requirements from a group of people who may or may not want the product while trying to understand what it is you're actually making, then you're probably going to fail.
It sounds like great advice, but right now, I'm not in the category of people building something new to take to market. I'm in the other group. The stuff I build and maintain (and now I'm going to slip back into software) is supposed to meet an immediate business need for a specific client. It more than likely won't be used by me, but I have to build it anyway.
So can Steve's advice be applied to my situation? Sure it can, to an extent.
Steve's main point was that if you're not investing in something you understand, then you're walking into very dangerous territory. As an end-to-end software developer, I'm aware that it's difficult to know exactly what the customer wants. Sure, you can grill every potential user for days, you can write a comprehensive list of requirements, you'll check it and recheck it over and over again to make sure you know single possible piece of functionality that they want and need. But when it comes to the crunch, no matter how much work you've done, you'll start getting negative feedback about some specific things that you hadn't thought of and the customer hadn't mentioned.
That complex report you were asked to include, the one with all the tables and forecasts and things? It turns out that 10 different people print that 20 times a day. So even though it's perfect, it takes 15 minutes to run each time, and they can't wait that long each time.
So how do you avoid this? In my experience, if you want to write truly useful software, you need to understand why each piece of functionality is being written. Spend a lot of time with the clients and find out what it's like to be in their shoes. If you see how they operate day-to-day you'll start to get an idea of what they actually want, not what's written in the requirements doc.
Steve's advice was that you shouldn't invest in what you don't understand. So if you have to produce something you don't understand, make a genuine effort to understand it first. You might not be as enthusiastic about or deeply involved in the business your client is in. But by honestly trying to see what they're trying to achieve, you'll learn what they really want your software to do for them; over and above the list of required functions.