Or, “Is it at least the same as, or better than, what you have already?” Developers used to write software by first spending weeks or months gathering information, then disappearing for months or years to go off and actually write the software. However, people often found that what the developers finally ended up releasing – after having been away for so long – wasn’t what the client wanted, or what the market needed. So their time was completely wasted and the project was a complete failure.
Luckily, things are changing. In the web world, you can now make a new ‘release’ of your software with just the push of a button, which has shifted modern software development to focus on more “Agile” methodologies. “Release often. Fast development without too much formality. Small sets of changes. Small teams.” – This is the Agile mindset; the idea being that you write some code, get it out to your users quickly, get their feedback, make changes, and repeat. “Agile” is still a relatively new concept though – the “Agile Manifesto” was only released in 2001, so sometimes keeping true to the core concepts can be a challenge – especially for technology managers who are old farts like me.
At an old job I had quite a few years ago, I had a boss – the CTO – who was generally a great guy. Good technologist. Solid conception of how all the pieces fit together. But sometimes, I, or one of the other devs, would bring something up to him that “we should do” and we would inevitably run into the following trap –
Me: “Hey Boss, we really ought to do ‘x’ – it would make our lives easier and make us more money and be super awesome etc etc etc.”
Him: “Well, minion – that’s a really good idea. But if we’re going to do ‘x’ we might as well do ‘y’ – it’s the very same code! And if we’re going to do ‘y’ we really have no choice but to do ‘z’ – people have been asking for that forever now! And to do all of x, y, and z will take us a jillion billion frillion months. So let’s not do that now.
I called him on that pattern after a while and gave it the name “Mountaining Molehills.” I’ve seen plenty of other people in the industry fall into that trap, too. I’ve even caught myself almost doing it, here at BriteVerify.
So what I’ve found to pull myself out of the trap is to ask the question:
“Is it better than, or at least as good as, what we have already?”
Take a fresh look at ‘x’ – the first little thing you wanted to do, sitting on its own. And see if that even without ‘y’ and ‘z’, it’s at least as good as what you’re doing already, if not slightly better. And doing just ‘x’ might have you releasing something in a few weeks rather than a year. And it puts you on a path where you can do ‘y’, and maybe even ‘z’. But the whole point of Agile is that you may find once you’ve done ‘x’, that that’s enough for this release. It may turn out that you don’t even need ‘y’ or ‘z’. You might instead need ‘w’ – something you hadn’t even thought of yet.
What got me to thinking about this the other day was drafting out a project plan for a new product we’ve been talking about. I had initial release dates set up for 6 months away, with some dates set as far away as nearly a year. That set off alarm bells. I looked at each of the dates I had set, and saw that I could probably trim a few days off here and there, but nothing that was going to cut the whole thing in half.
It was then that I asked myself – well, what if I did just this one thing? It’s not what I want to do. It’s not what the product is “supposed” to be when it’s finished. But – is it at least as good as, if not better than, what we have now? Yes, it is – by far. And as a bonus, by just making tiny “sprints” like that I could get us to a released product much sooner.
So there was my answer: do it.
Fight through your perfectionist urges and do it – not the way you idealistically would like, but the way that will keep you moving forward in a much more practical way. Stay focused on the Molehills and before you know it, you may have even moved that Mountain.