Personal Insights
software development task estimations discussion
Dear community, by accident I found this article called “Why are software development task estimations regularly off by a factor of 2-3?“. I really like the chosen comparison in the article. The situation should sound familiar to us developers, even if it has nothing to do with hiking in our case 😉 That’s why I wanted to share the article with you.
Building on the article, I would like to start a little community discussion: What helps you to estimate the effort as realistically as possible? I’m now deliberately not writing what helps me and I am curious what you have to report. Feel free to comment. Many thanks in advance.
Best regards, thanks for participating and stay healthy
Michael
Hi Mickael,
estimation is a so complex subject. Before having a job of management of a development team, I was totally convinced it is play wih dices.
All my development had been done in best-effort, with estimation like 1 week, 2 weeks.... and at the end it is 4 weeks 🙂
I work with several companies, each of them have a beautiful Excel file, with from several inputs determines the complexity of the development. The input could be more or less detailed. But the result is more or less the same.
This indicator means nothing, because it depends of the team. You have people working really fast, other people really slow, and you also have the number of rewriting needs for some developpers. You could apply some performance indicator on your developpers.
But I think, all this only gives you a price indicator of a development, not a scheduled availability date.
Through the concept of the TDD you could also imagine a way to identify the time needed. You need a technical architect, design the necessary class/interface/table/... identify the Test to be done. Through the test & the number of class & public method, you could have a better time estimation. But it needs to have enough time to do this architect job.
Fred
If TDD is used correctly, it definitely helps. After all, it assumes that the architecture in connection with tests is dealt with intensively. This preparatory work alone makes a lot of things clearer. And therefore easier to estimate.
Figure out how long you think it will take. Double it, and use the next unit up. So - 1 hours -> 2 days. 3 days -> 6 weeks. etc.
The main reason why software development is hard to estimate is that much of the work is R&D. That means often "it takes as long as it takes".
and even when the R&D quota is otherwise limited, the specs are hardly ever defined well enough to make a difference 😀
Reminds me on a Ken Williams (Sierra On-Line) advise:
"One hour projects take one hour to complete. Four hour projects take a day. One day projects take a week. One week projects take a couple of months. And, six month or longer projects tend to never complete."
Very good point: R&D. That's what I hate quite often in the past. Someone sold a project an he/she knew very well that nobody in the company had the needed knowledge to do it. Building the knowledge before was no option: Why investing time in R&D when customer will pay you for the same thing? Just wait until a customer is found and then do your R&D. Terrible...
I go about estimations rather pragmatically. As we only work with full days I tend to round up to the next full day. Estimations are used to both guesstimate how long implementation will take but also to make an offer to the requester of how much the development costs. As only the actually used effort will get billed, adding a bit of a buffer doesn't really hurt but of course shouldn't be too outlandish.
If the change is required for badly written code, it will tend to be a higher estimate than for a cleanly written program (or a program one is already rather familiar with). In some cases where more work is expected and/or more people/groups will be involved we sometimes go for a pre-project of a couple of days to then prepare a more detailed estimation of effort, after taking a closer look at the feasibility of the request.
Cheers
Bärbel
Fits my belief: everything starts with a day, not an hour 🙂
It depends, in my opinion, about the environment, as Bärbel Winkler already hinted in her previous reply: it's quite different if you have to start from blank canvas or if you have to dig ages of old stratified code (and yes, many many many companies still have such complexity).
If i can, I estimate some time to "analyze the requirements" at high level (aka, is it clear? are there possible hidden pitfalls?), then i provide an evaluation for the fine analysis and its reworks (usually material time for analysis +20% for reworks)Â and, once approved, i provide the numbers for development (material time + 30% for reworks).
Of course, i'm speaking about something more complex than "add a column in this ALV", even if we all know that a stratified report in spaghetti code can be quite challenging to add a single column.
Not really scientific, but, basically, i go for thumb rule.
"Add a column in this ALV": With words like this begin some horror stories that ABAP developers still worry about after 20 years when they think back on them 😉
Presumably, "not really scientific" is very typical of everyday life. I mean, who really practices the function point method or a planning poker (scrum poker)? Mostly there is no time left in everyday work.
I think you nailed the issue: there is no time left. Everything is urgent, everything is required for 2 weeks ago.
Everyday i overwork 1hr / 1,5hr just to keep up with paper work and to try give all the answers, trying to correctly estimate the workload, but also priorities keep changing and...it's a dog biting its tail.
I think that this one summarizes it:
The ExpertÂ
Total madness. Humor doesn't help either 😉
I take an estimate * 2.5 Round up to days.  Now with that said - the estimate has to be in man hours, unless it is the only thing you are working on. If it's the only thing your working on still figure about 1 -2 hours a day of questions.
Then I organize by priority and let everyone know what they are going to get and when. If my priorities shift - I reorganize and at a minimum let my boss know it will be late and why. And why it really isn't late because I'm working on something else.
It's a constant moving target until someone says we have to have it and let everything else slide.
Now throw it all away because it's a big project and you have to be done by xyz. At that point, I try to get more help. That doesn't always happen. Then the work hours increase to meet the date. BUT be aware of burn out. It's real. So after that ramp up, you'll need to settle back down to normal hours. Otherwise people will just assume you are going to work that hard all the time. I'll give you a hint it isn't possible.
My moving target. I start with a document / strawman if possible, and have everyone approve it. As it changes I add hours. They can make the decision if the new functionality is worth the hours. Make them aware of other projects that will not get your time...
So there is no clear path.  Everything is always moving UNLESS you can truly work on only that task. And you build in some time for added/changed features.
It is exactly like that. Unfortunately, constant reorganization takes time and effort. Sometimes you are tired of reorganizing and only then do the actual work.