May 23, 2015 - Marco Behler
Another day in the office. Another day of boss-storms-into-the-room-with-a-crazy-feature-request. You don't even properly listen to his actual feature request anymore:
“Marketing now desperately needs feature blah blah blah. Should not take too much time, I mean there are already existing libraries for that, right? Plus you guys are super smart! We need to be ultra fast, first-to market!….three weeks?! Need a reliable estimate for go live in an hour. Bye!”
Can you see what tricks - maybe even unknowingly - your boss is pulling on you?
That feature request might seem a bit hyperbolic, even though I have seen a ton of variations like that in real life customer scenarios.
It displays every warning flag that you as a programmer need to recognize and then immediately push back on. Do not blindly accept those jabs thrown at you .
Let us have a look at each warning sign in turn.
This one is actually a double-edged sword. On one hand, an astounding number of developers tends to reinvent the wheel and shy away from off the shelf solutions. Registering and logging in users? Let’s write a new user management from scratch! In a way this almost seems obvious, looking at the word “developer” instead of "maintainer".
On the other hand it gets equally counter-productive, when business suddenly decides that they somehow 100% know that there are already existing, easily custom-fitted solutions, which you might even have programmed yourself. As something similar is already existing, duplicating that effort or integration cannot be that hard.
It does not matter how many libraries exist or how many similar requirements you already implemented. The overlap in functionality and re-use can only been seen after proper requirements work, not before.
What you have to reply: “I can only tell after careful analysis and requirement deconstruction, if and how useful those existing libraries/solutions are going to be”.
This one is tricky and I fell prey to it myself once or twice at the beginning of my career (maybe I still do? :) ). Be wary if someone suddenly starts to stroke your ego.
It is especially dangerous when you are a freelancer/agency and your client tries to pull this on you. Your client simply wants to save money by appealing to your ego and your alleged rock-star skills to literally bake that pizza in 30 seconds instead of the usual 10-12 minutes. Because if you are so smart after all, what's the big problem?
Should you agree on that "estimate" and then nevertheless need the usual 10 minutes, I can almost promise you that your ego will not go crawling back to the client and go “sorry, I was not so smart after all, it took me 10x longer”.
What you have to reply: “The complexity of this requirement unfortunately has nothing to do with super smartness. Sure, I can promise you that fresh, Italian pizza after one minute. But you probably would like it in the oven a bit longer, wouldn’t you?”
Can you recognize them yourself? Alright, here we go:
The Appeal To Being The First To Market – “We need to be fast…three weeks?!”
The Appeal To Engineering Prowess – “Need a reliable estimate on possible go-live in an hour”
Sorry for being such a tease, but the article is already getting rather long and I talk about the remaining two and much more in detail in my upcoming book "Customer Requirements", which will be in EAP starting 30.05.2015.
Head over to the book's page and judge for yourself. Constructive feedback, both positive and negative is always more than welcome!
Otherwise, stay tuned for the next articles in the requirements series!