As a software developer, getting time estimations for building features is often a tricky part of our daily work. One Sunday last month, I finished...
For further actions, you may consider blocking this person and/or reporting abuse
From 25 years of development experience, I've found it is best not to estimate - at all. Estimation just wastes time.
This is very true:
(quote is from here)
Hmm that's an interesting approach. So if that's the case, what do you tell product managers, your customers, or management, when they ask you when the feature can be launched?
At work, I tell the PMs that I don't know, they then put a time on it themselves, and it just takes as long as it takes - I'm not going to waste my time estimating - or worse, rushing out poor quality products to meet arbitrary deadlines.
Outside of work, all my clients for freelance work have always been happy with just seeing progress from time to time - and a good final result when it's ready
Interesting! I think you're really fortunate to work in a place where you can take as much time as you need. In my experience, it's not very common for most workplaces - even if it's just because other colleagues (sales, communications, marketing, customer support etc) need to know when something will be launched so they can prepare their end of the work. Management in particular, I've found, need to give at least quarterly updates to the Board on how things are progressing. You're super lucky! :)
You can do it at any workplace. Stand up for yourself. If you produce good work you'll be valued. Don't waste time on activities that are detrimental to the production of a good final result.
Deadlines and being held to estimates almost always results in inferior code which ultimately makes the project take longer as there are more issues and technical debt to address - not to mention the time spent estimating!
I agree spending time estimating can be annoying, and that badly-estimated deadlines are very often dangerous, and detrimental to code quality.
I think we'll need to agree to disagree on not doing estimates at all though. I think being a good team player means keeping the rest of the company informed of when they can expect a feature to launch. In my experience, partnerships needs to prepare workshops for partners (and customers, in my current situation), communications/marketing needs to get media releases ready, and management needs to inform investors/the Board about how their money is being spent. It's unfair on them to suddenly spring a feature launch and expect them to scramble to get their work done, especially if there's time-sensitivity to what they do (i.e. they need to get their media releases/workshops done within a week of the feature being launched).
But again, that's just my experience - if you don't have people relying on your time estimates, then by all means, estimates are pretty pointless!
Sure, time estimation hard for a feature, but at least it is possible to do!
I get asked quite a bit about estimating the length of a debugging session. Usually I'll reply something along the lines of "I can tell you when I know what is wrong" or "between 5 minutes and two weeks"
Others in our software department has started using that last one, when they get pressed during debugging, which has earned us a bit of a reputation among the PMs 😆
Haha I've also heard some devs say "How long is a piece of string?" when asked how long something is going to take. Debugging is such a tricky one, because like you said, it's so hard to estimate when you're not sure what the issue is (and if you were sure, you probably wouldn't be debugging!).
I don't understand this "How long is a piece of string?" but reading it, it occured to me that if I don't have a map and I stand at one end of the road then in order to estimate how long it is, or how long it will take me to walk to the other end, I actually have to walk to the other end.
Yeah, "how long is a piece of string" is a pretty bizarre English saying in my opinion! There's a pretty interesting account on the etymology of the phrase here: english.stackexchange.com/question...
I said "How long is a piece of string" at least 5 times today.
I also said "what you want to achieve is not feasible, go back to the drawing board" at least twice.
That's a good one too. I'll totally start using it 😆
Respectfully, this article's title is misrepresentative because you're really talking about work efficiency, not estimation accuracy. That said, we should be estimating effort, not time. Except for the most trivial changes, time estimations are notoriously unreliable (I won't go into all the reasons for this, but there's plenty of info online if you want to research it). This is one of the big reasons Agile replaced Waterfall as the preferred software development philosophy.
So, I'm not suggesting you change the content of your article, but I think a title change would more accurately reflect the article's content.
I personally cannot correctly estimate anything that takes more than 5 minutes and even then I miss the target.
What works for me is when I have real dead line. For example I have a presentation to give and people have already signed up.
My suggestion is to always start by giving an estimate to how long it will take to estimate the project. That might give a perspective.
Oh and BTW, there is a whole movement about noestimates. I think it is worth exploring it.
Of course I'm not saying I never know - I definitely know sometimes, but then that is not an estimation. By estimation I mean attempting to break a largely unknown task down and come up with a time or approximate time it might take. This is what I have found is ultimately futile and a waste of valuable time that could be spent just getting on with it
Oh yeah - if you have no clue about the task/it's largely unknown, then estimating is often just plucking a random number out of the air, which is not helpful. We have R&D sessions every fortnight where we sit down and try to actually eliminate most major unknowns on upcoming tickets, to try to put us in a position where we can estimate more accurately. Sometimes it works...sometimes it doesn't (you can't always eliminate every unknown, even when doing prep).
Thanks for the interesting article! I very much like the advice of taking past experiences into account when estimating.
I've found PERT estimation technique to be quite useful in estimating, I think I picked the recommendation from the Clean Coder. Do not give a single number as estimate but three numbers: one for optimistic estimate, one for the most likely, and one for the pessimistic. If the effort is wildly difficult to estimate, it shows up in the numbers.
Also remember that estimation is not the same as committing to a date. If you commit to a date, then other people will make their plans depending on your commitment, and you must get the job done. I think that's just professional behavior for a software dev. If you are unsure, don't commit. It's much better to say "it's probably ready next week but could take up to four weeks" than make your boss happy by saying "it'll be done next week" and then go to them in a week and say it'll take three more weeks.
Finally, we'll all miss deadlines. The important thing is that when you see a deadline approaching and you know you'll miss it, you should immediately notify every stakeholder you'll miss the deadline so they can take that into account.
Love this response!
Try this technique. A little more quantitative than this article's recommendations. We use it at Northscaler, Petter's company. Works pretty well. pettergraff.blogspot.com/2014/02/e...
I would love to know about that art tutorial :) I am also learning digital paintings.
Oooh yay! So I follow Art With Flo on YouTube (free tutorials that are more suited to beginners), but she also has a Pateron page with heaps of paid tutorials for more intermediate to advanced levels. She released this tiger tutorial for a weekend for free, so if you're interested in the occasional freebie, I recommend signing up to her mailing list.
(Btw, I don't know her, or have any affiliation with her.)
I follow her on YouTube. She is very good. I tried some of her tutorials on YouTube too. Thanks Carmen :) Hope to see more art works for you!
I have has my fair bit of missed estimates. Then I read about PERT in one of Uncle Bob's books. It did do some part of the estimating process and it asked accurate questions.
So, I ended up making this small node CLI package that you can run with npx
The answer to give to the client is "between 2X and 3X" where X = your estimation where everything goes well. Because not everything will go well.