Fighting Technological Indulgences
That’s a nice one! Wonder if I should use Ruby, Python, or maybe even Perl to build it? As gearheads we tend to jump to the technical details with little afterthought, but should you even be building that feature in the first place? How do you make that call?
Whether you're a one man team with a shoestring budget, or a financed startup with some runway, managing the feature backlog is more of an art than a science – it's always full of vaguely formulated ideas and it's constantly changing. Managing these priorities is as hard as it is, and if you have a team, it gets even harder: how do you make sure that everyone is aligned with the vision and the roadmap?
Managing the backlog: countdown to zero
A great story from the startup folklore: after closing a round of financing, the CEO brought in a big jar of marbles representing the amount of money they had in the bank and proposed that each time a project manager or a developer pitched an idea, they would have to take some marbles out of the jar (depending on the size of the project). Nobody opposed it, but a few odd looks were exchanged. Then six months went by, the jar was now half-full and the dynamics started to change - everyone became much more conscious of the amount left in the jar. They could now see the inevitable: the jar was not being filled up nearly as fast as it was being depleted.
The problem is, I think we all fall into this trap more often than not. What has changed in the fundamental goals of the company in the six months since the jar was initially full? Nothing, of course. The strategy may have shifted, the product roadmap has evolved, but the economics of running a company remained constant. Six months ago, the day that the company would cease to exist was 12 months away, 6 months later, it was simply 6 months closer. Here's an acid test: if your project would cease to exist tomorrow, would you work on the feature you're contemplating doing today?
The luxury of time
Just because the deadline is further away does not buy you the luxury of indulging into technological desires. Unfortunately, as developers we tend to forget this, as we’re too easily distracted by the shiny technical aspects of the next greatest thing, or over optimizing for the day that never comes.
Stop and examine what you are working on now: does it directly contribute to the success of your project today, or is it a nice to have? If you had a deadline in the immediate feature, would you still be working on it? If not, then you probably shouldn’t be doing it.
Time & Strategy: use them to your advantage
Does that mean we should always focus on the short term goals? Not at all. The luxury of time is exactly that: a luxury and it should be treated as such. If you waste it, you can’t get it back. But having this luxury can also buy you a strategic advantage: you can trade short term goals for a higher return in the long term.
Sometimes you have to go slow to go faster. It's the lack of that regression test suite that's coming back to bite you, or perhaps a monitoring system that will save you the maintenance time – the examples are endless. The challenge is, of course, to weight the benefits of these long term goals against the possible value of shorter and quicker releases: “Great companies ship.” You have to be able to recognize that a technologically inferior solution delivered quickly can often outweigh a ‘cleaner’ solution – the real trick is, of course, to also have your team of gearheads understand why this is true.
Time can buy you the luxury of strategic objectives, but remember that today is no different than the day you’ll be taking the last pebble out of that jar, it just happens to be a few days into the future.
Ilya Grigorik is a web ecosystem engineer, author of High Performance Browser Networking (O'Reilly), and Principal Engineer at Shopify — follow on Twitter.