Always been curious how “workload” is assigned and estimated for software engineers.
In: 92
It’s mostly based on our own estimates and how well we meet those estimates. But it’s also measured against our peers’ and leads’ estimates. If we consistently estimate higher than other coders (and we take longer than other coders) then we’re probably not being as productive. It’s tough though – one of the hardest things to learn as a software developer is how to give time estimates for something which you don’t know much about. Like – I’ll be asked to estimate how long it will take to add a feature to a program when it’s not a program I’ve ever worked with, it’s not a business process i’m familiar with, and it’s not a customer I’ve worked with before. This kind of thing, to some degree, happens frequently.
As a young coder you often start out making bad estimates, because you know what it’s like to do something from scratch so you use that as your basis. Maybe you need to add a field to a webpage – nothing complicated. So you say it’ll take half a day, figuring it should only take an hour so you’ve padded a full 3 extra hours in. But then you look and you find that the page is being automatically generated from some other code. And that code references a database view. And that view is a complex reference that filters out based on a myriad of factors. Plus the layout of the page is standardized using some templating, and changing the template to accommodate the new field will break other pages. And none of this is documented, in fact it took you two hours just to figure out what tables in what databases were involved, and whether or not you had the permissions. You’re also unsure which environment is right, the code points to (local) and the dev environment points to dev, but the test environment seems to point to both dev *and* test in different connections and the layout is entirely different. The code that’s in production doesn’t seem to match anything in the test environment or the dev environment. Now you’re 3 hours in and you haven’t even started adding the field.
Then you end up over-correcting. Suddenly your boss is worried why you think every minor change is going to take at least a week. You keep talking about “unknown unknowns” as though they’re the boogeyman. You question whether time is real.
Eventually you end up where I am now (I’m about 12-15 years in, depending on the measure) where you have a good sense of what the factors are that will go into the estimate – you can give me that same “add a field” scenario and I can tell you it’ll take me somewhere between 2 hours and 2 days, depending on what the code is like and whether there are unknown problems that need to be fixed first. Particularly cases where (and it happens more than it should) the code that’s deployed on production doesn’t match anything we have in source control and we’re going to need to reverse engineer it with a decompiler.
So as I get more experienced, my estimates get more realistic in both directions and they also are able to come with contingencies – I can tell you not only how long it’ll take but I can tell you why it could take longer, and when I’ll know how long it will take.
Latest Answers