In my experience estimating how long a software engineering task will be is hard. I think this is often the case with software engineering tasks in a way that it isn’t for other disciplines.
More design than assembly
A quick internet search suggests a beginning bricklayer might lay 250 bricks per day, an intermediate 450 and a good one 500-900. Given a length and height of wall it doesn’t sound too hard to predict how long it takes to build a particular wall. Something that has a more complicated shape or pattern will slow things down but in a consistent way.
Some types of coding might be similar. I’ve not done this professionally but I think creating standard sorts of web pages could be quantified. A particular sort of page takes a know number of hours to make. Once you know what sorts of pages are needed it’s “just” a matter of adding up the hours. Note, I’m talking about “standard” web page here but there are probably all sorts of non-standard ones as well. I really haven’t worked in this industry.
Most software engineering I’ve been involved with doesn’t seem to have these known components. I’m not assembling known components. I’m researching components, deciding which ones to use or creating them for scratch. Sometimes what I’ve been asked to make isn’t even possible, at least not in the way that was originally envisaged. If I do have a task that is repetitive enough for easy prediction then ideally it will be automated so that the repetitive parts are done in minutes by a computer. Then you are back to estimating the hard parts.
How can you assign timescales when there is no previous work you can compare it against? Normally this comes down to an intuition built up over your career. As things sound easy, medium or hard to you they get estimated as days, weeks or months. You could say, “It’s more an art than a science.” I find that unsatisfying.
Can planning help?
I’m sure more up front design can help in some circumstances. Often tasks that are entered in to the backlog are very vague. In theory these are meant to be updated with more detail as they get towards the top of the backlog but often aren’t updated. Creating extra tasks for research or prototyping can help or at least constrain the uncertainty. These upfront uncertainties are shorter and, once you know what can be done, future estimates will be more certain. Doing all your design up front sounds like the waterfall model and that has it’s own problems.
However you will always have unknown unknowns. If you started planning a game you might set aside time for graphics, sound, controls, AI and gameplay. Would you remember to set aside time for making a Steam page and making a trailer? Maybe you would first time round, maybe not, there’s bound to be something unforeseen.
A poor feedback loop
I don’t think that developing an intuition for estimation is easy but that shouldn’t really be a surprise. Often a task is estimated, sits in the backlog for weeks, is updated to reflect decisions but the estimated is left unchanged. Next the task is started, the coding takes days or weeks, then testing and perhaps another round of fixes. Finally the task is closed. Was the estimate good or bad?
(I’d love to have some better references here. Instead there is a vague memory of a YouTube video, perhaps from GMTK, where a video game player has to play basketball in the middle of a mission. However every time they fail the shot they’re taken back to the very start of the mission. I can’t remember enough detail to find it. I’ll start again…)
Imagine you’re playing Angry Birds. You line up your bird, pull it back and release. Instead of showing you what happens with that shot the game requires you to make all your other shots. Then the game waits a month. Finally it shows you the results of each shot but in a random order. I don’t think this would be easy or fun to play.
Something is easier to learn if you can quickly go between the problem and the result. You can adjust your approach to the problem and then evaluate how you’ve done. When estimating for a task there can be a huge gap between the initial estimation for the task and when the task is actually finished. Not only that but often we only have a vague notion of how long the task took. We’re normally paying more attention to whether the tasks works. It’s just not set up right to be easy to learn.
In the end
There are a lot of methodologies out there and a lot of companies trying to sell technologies but I’ve not worked with anything that solves the problem. I’ve got some of my own ideas which I’ll write about later.
Leave a Reply