How long is that going to take? No doubt many of you engineers have heard this question when a product or marketing guy or pointy hair boss comes wondering when their feature will be done. Let’s look at some of the reasons why these people care about schedules:
– There is a marketing promotion planned
– They made a backlog and list of features to develop stretching out for the next year or more
– Bean counters need to know how much you programmers are costing them
– There is an earnings call where your feature is going to be announced (can’t tell you how many times this happened to me…)
Here’s the problem: The only time you can accurately estimate when software will be completed is when the scope of the project is very small. Anything larger than “a few days” estimate is likely way off. When these “higher ups” mandate schedule, everyone ends up working ridiculous hours and it kills productivity afterwards. Large backlogs also tend to contain a lot of features that provide little value, are someone’s pet project or will never get done. So what was the point in making that backlog and plan in the first place?
As an indie developer, I like to track my ideas in Trello, which is a nice card based solution for tracking tasks. For You Doodle, I have an ideas column where I brainstorm, a “in progress” column where I list the features I am working on, and then a DONE column which I archive periodically as I release the next version of You Doodle. If a feature looks like it will take longer than a day or two, then I split it out into smaller sub-features until I can confidently say I can do this feature given a full days worth of work. Every couple of weeks, I send whatever I’ve done to Apple as a new version.
Has there been cases where the feature has taken longer than a day? Sure. The collage / frames feature took 16 hours and ended up being a marathon coding session until 4 a.m. But that has been the exception rather than the rule, and I should have broken it up into smaller chunks.
My in progress column always stays at two cards. The top card is the one I am working on, followed by the next card which is on deck. When I finish the current feature, it goes to the done column, the next feature card moves up, and then another card gets dragged from ideas into in progress. At any time I can swap out the in progress or on deck card with a new card. I’ve done this many times based on user feedback or when I find bugs.
When I implemented multi-peer drawing with nearby iOS devices, it was a huge task. I had to basically write code to automate just about every function in You Doodle so that that function could be called by a network handler. This ended up taking me well over a week, but I was able to break out the pieces of the app to automate into separate features and do the most important tools first (like the brush). At any time I could have shipped my multi-peer drawing with a limited set of features. I didn’t end up doing that though, I shipped with every tool working and automated.
The correct answer to the question “How long will that take?” is that it will be done today. If the feature is too big, split it out into smaller features that each have deliverable value to your users. As an indie developer, I can’t fathom working any other way.