The Requirements Were Not Well Defined.
As a part of my job role; I conduct interviews.
Tons of them.
If you read this blog; you probably know that one of my favorite interview questions is - talk about one colossal failure that you were associated with in your professional life.
The idea is simple: If you have not failed even once; you have not taken chances with your professional life. You have played it safe and you have avoided building remarkable stuff by resting the realms of mediocrity.
Put simply; you are what we call a 501 programmer.
Every once in a while however; I will find a developer sitting on the other side of the table; who; when asked this question; knits his brows; look up at the ceiling; pretends that he is trying to think of a failure really hard and then comes up with a random project name.
Ask him what was wrong with the project and watch him give random excuses with full blown jargon meant to point a finger at someone other than him.
The most common one of them all: 'Requirements were not well defined by the customer'.
Requirements were not well defined by the customer along with lack-of-process continues to remain the biggest and the most convenient excuses for most failures or fu@#kups that we as programmers are involved in.
After all these years of software development; we continue to work with customers who just cannot seem to be able to 'define requirements' for a simple payroll processing system.
Doesn't something about the whole requirements-were-not-well-defined arrangement thing sound terribly strange or fishy every time you hear it?
They Didn't Tell Me What To Build.
If you are a non-programmer; who is not associated with the world of software development; you are probably knitting your brows right now as you read thing and wondering - 'But Pops; if your clients want you to help them with their problem; how can they not tell you what their problem is?'.
To be honest here; the problem usually isn't about the client not telling you what the problem is. The problem is that over years of BDUF development; we as developers seemed to have changed our definition of requirements from a 'definition of the problem that the client has' to 'instructions on the bare minimum that I need to do to make this project successful'.
More often than not; when a young and budding programmer; who has seen his whining seniors do this; tells you that his project failed because the requirements were not well defined; what he is basically telling you; is that his client did not give him a step by step list of the bare minimum task-items that he needs to do to get the project successfully completed.
Seth Godin in one of his recent posts; describes the problem much more articulately than I will ever be able to describe it. He explains:
"What do you need me to do?"
This is a question that defines the person asking it. It is very different from, "here's what you might need..."
If you ask people for the next task on the list, if you allow them to define the thing they are buying from you, you have abdicated responsibility.
Your work product becomes dependent on the insight and guts of the person giving you an assignment. This is especially dangerous for consultants and freelancers, because the answer might be, "nothing." Or it might be a paying gig that's profitable in the short run but a career deadener over time.
Far better to reach a level of confidence and skill that you can describe solutions rather than ask for tasks.
The guys at 37Signals take this concept to the next level. They believe in showing some tough love to their clients by not letting the clients dictate exactly what they want from a product. In their classic book; getting real; they explain:
As a software development company, you have to act as a filter. Not everything everyone suggests is the right answer. We consider all requests but the customer is not always right. There will be times when you just have to piss some people off. C'est la vie.
Related to this, it's critical that you as a development company love your product. And you won't love your product if it's filled with a bunch of stuff you don't agree with.
That's yet another justification for vetoing customer requests that you don't believe are necessary.
Steve Yegge even ventures out so far as suggesting that business requirements are Bullshit:
I learned a lot about the Fine Art of Building Shit that Nobody Wants back at Geoworks, when in 1993-1994 I was the Geoworks-side Engineering Project Lead for the HP OmniGo 100 and 110 palmtop organizer products. Both of them launched successfully, and nobody wanted either of them.
People spend a lot of time looking at why startups fail, and why projects fail. Requirements gathering is a different beast, though: it's a product failure. It happens during the project lifecycle, usually pretty early on, but it's the first step towards product failure, even if the project is a complete success.
Self-professed experts will tell you that requirements gathering is the most critical part of the project, because if you get it wrong, then all the rest of your work goes towards building the wrong thing. This is sooooort of true, in a skewed way, but it's not the complete picture.
The problem with this view is that requirements gathering basically never works. How many times have you seen a focus group gather requirements from customers, then the product team builds the product, and you show it to your customers and they sing: "Joy! This is exactly what we wanted! You understood me perfectly! I'll buy 500 of them immediately!" And the sun shines and the grass greens and birds chirp and end-credit music plays.
That never happens. What really happens is this: the focus group asks a bunch of questions; the customers have no frigging clue what they want, and they say contradictory things and change the subject all the time, and the focus group argues a lot about what the customers really meant. Then the product team says "we can't build this, not on our budget", and a negotiation process happens during which the product mutates in various unpleasant ways. Then, assuming the project doesn't fail, they show a demo to the original customers, who say: "This is utterly lame. Yuck!" Heck, even if you build exactly what the customer asked for, they'll say: "uh, yeah, I asked for that, but now that I see it, I clearly wanted something else."
If there is one thing that is common between advice coming from Seth Godin; 37Signals and Steve Yegge; it is; that you cannot be letting the customer define your requirements. The first step to building a successful product; is living the life of your costumers; feeling their pain and understanding their problems really well; before you even think of building a product for them.
It Is Just A Lame Excuse. Seriously.
Requirements that are not 'well defined' are a convenient excuse for all your failures. As programmers we are so used to blaming the process and the requirement and then believing our own lie; that we rarely look back to reflect on the real cause of our failures; reflect on them; and learn from them. We don't even feel the need to practice the craft of building good software.
Next time you think back on one of your failed projects; if you find yourself blaming the customer or your business-analyst for requirements that are not well defined; stop; and reflect on how you could have understood your customer's pain and given them a genuine solution for the problem.
Saying that the requirements-were-not-defined basically puts you in the same bucket as thousands of other outsourced bodies-with-their-brains-switched-off working out of Indian body shops; and that; dear reader; is something no genuine programmer worth his salt should strive to become.
Next time you are working on a product; either build something which solves a problem you yourself have; or live the life of your client; connect to them; take time to understand their problem; feel their pain and add a little bit of yourself to the solution you give them.
I wish you good luck.
@BuildersAtWorkBookNotice
Comments are closed.