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 this digital art work within a day, and here's what helped me...
(Sidenote: If you are interested in productivity, tech, and product topics, follow me on Twitter where I post about these things in an easy and fun way. I've also just started a bite-sized newsletter talking about all things tech that you can subscribe to here.)
1️⃣ Time boxing. This is where you allocate a set amount of time to complete a task, and then as soon as that time is up - it's pens down. In my opinion, time boxing rarely ever works in software engineering - often because the people who set the time limit actually want you to finish the work regardless of how many hours it really takes (which means you end up working on it in your own time), or YOU refuse to adhere to the timeframe because you're "just another hour" away from finishing the task (which means you end up working on it in your own time, because no, you aren't another hour away from finishing it 😅).
For this piece, I was following a digital art tutorial that was only free for the weekend - and because of timezones, that basically meant only Sunday for me. I knew that if I didn't finish the piece in time, I'd have to pay for the tutorial, so I timeboxed one day for it - and there was actually incentive for me to adhere to that deadline because, frankly, I don't like paying for what I can get for free.
2️⃣ Use your previous experience when estimating time. I'd followed tutorials from this girl before and knew that I would always end up taking about three or four times longer than however long her tutorial was. I would pause the video, adjust a bunch of things, rewind, and replay.
This tutorial was two hours, and I gave myself the entire day to paint the tiger - true to form, it took me around 8-10 hours to complete. I estimated a day because frankly, things always come up in software development that mean initial estimates are often underestimated, so I'm accustomed to adding a buffer.
3️⃣ Take breaks. While it may seem counterintuitive to saving time, breaks are important. At one point while working on this, I was fatigued - my shoulder was stiff, my fingers were cramping, and I was making lots of mistakes that I had to constantly undo. It felt like one step forward, two steps back. This is the time for a break.
I ended up taking two hours off to play Monopoly Deal online with friends, before getting back into it and pushing through the final hour of work. Coming back to it after a small break also meant I could see with fresh eyes which parts of the painting needed some tweaks. This often happens in software development - even taking a walk or a shower (or better yet, go sleep on it) will suddenly reset your brain so you finally figure out the way to debug your problem.
Now if only I could be as good at time estimation in my daily job...😂
Follow me @carmenhchung on Twitter for more coding thoughts & memes. 🙃
Top comments (40)
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!
Why the hell can I only click "love" once on your posts? You deserve a lot more than that!
Thanks so much Dave, really appreciate it! Also love your "go back to the drawing board" comment - it's super important for people (not just devs) to raise when things aren't possible early on, and to encourage re-thinking the solution (and sometimes the problem, haha).
Interesting. This might work for a one-man-army-permanent-job type situations or a greenfield project, but generally doesn't work for a freelancer/contractor working on an existing software/maintaining/rewriting or upgrading it. Besides, the client who's paying you doesn't really like if you shrug with an "uh I dunno" attitude. A rough idea is always appreciated by a client. A company coming to the client premises for a contracting business, giving an impression of having no idea about estimates, will be thanked and shown the door.
This is an ambitious stance at best, but like I said, it might work for permanent employees in a long-term job for number years. For others the article is very helpful.
Regards.
It heavily depends on what you refer as estimates. If I have a new client, they have an idea and a budget. They definitely need an estimate. However, it's not the estimate we, devs, immediately have in mind, like knowing exactly the amount of days for each specific feature. They need just a ballpark, a range, an idea for their product. For someone who has no idea about programming it's very hard to convert a budget into something more tangible. And it's fair. It's also part of our job as devs.
Some clients have hard discussions with investors, they need a product team with them to provide the necessary info. They might have deadlines. And we need to be able to master the scope, cut some corners if necessary, make use of 3rd party services to create workarounds and deliver value as soon as possible.
That's what we, Whitesmith.co do as a product studio. After the idea is aligned, we define the MVP or the PoC and we make the best we can with that budget (if possible and doable). We rollout the product, we gain traction, we get more funding, we keep developing in an agile way, always validating every step.
Essentially, we make sure we deliver the necessary value according to the needs of our clients. That's way different than implementing features within an estimate, because I agree with you on that. If there's no other way around, the feature should take the time it takes. Won't argue with that. But then we ask ourselves again, can we deliver value sooner?
Estimates are tricky. They are data points, they have different levels of precision, different levels of importance depending on the context and the business. If you work on a single product estimates will have different purposes from consulting. An even on consulting, their purpose changes a lot depending on the phase we are working on. We can easily estimate things that we know and things we know that we don't know. But what about those which we don't know that we don't know? That's when estimates really fail.
Putting everything in the same basket is a simplistic view of something highly complex as estimates.
If this works for you, that is fine. But how would you deal with the opposite, when a you want a painter to paint your house, and his answer is like yours? Would you accept this?
I would appreciate his honesty as builder's estimates are notoriously unreliable 😉
It's nice when the painter is paid by the hour and you don't knoiw how much you have to wait for it to finish, and how much money it will cost.
Any estimation is perhaps more accurate than no estimations at all. They might be given by previous experiences. And you can always add a dice factor onto it.
Based on mine, I can give a person a rough estimation (with a warning), which will be adjusted in time.
So what do you do in the real world, when PMO and stakeholders are demanding to know when their new feature will be available to users?
That is what I do. My jobs are in the real world
So, like other commenters have told you - you're very fortunate.
I've gone back & read the article that you reference, and while it makes a valid point (estimates are often used as a stick to beat the developer with), the logical conclusion is frankly, illogical (don't estimate).
That's like saying you keep losing at poker with good friends, so you stop socialising with those friends.
The Project team (PMs, PMO, call them what you will) have a very specific need - to communicate when feature X is likely to be with end users. It's also their job to manage expectations, and to allow for slippage etc, though many of them tend to forget that part.
So our take, is that developers put story points on things, to flag "how complicated we think this piece of work is, compared to another piece of work" - story points do not, ever equate to time. The estimate is, as that article suggests, usually wrong. So we don't have a problem with adjusting it when we get better information.
From there, since we use Jira, PMO have a button they can press that says "how many points per sprint do we achieve" - and then it's relatively simple maths to average that across a number of sprints.
So then, in Sprint planning, assuming all tasks have a "complexity estimate on them," Sprint Planning becomes a drag-drop exercise, and if the backlog is groomed properly by a Product Owner/Stakeholder/vaguely interested party, they simply drag the things from the top of the backlog into Sprints, can plan 6 Sprints in advance, and they know the time box that fits around a Sprint.
Heypresto, stakeholders know how long features will take to be in front of end users (with PMs managing that expectation in case of unexpected issues).
Then, and this is the part most companies get wrong, it's my job as Dev Manager to monitor the whole shebang. Are the team overfitting estimates in order to relax? Are the PMs pushing too much into Sprints? Do the git statistics match the complexity statistics? Etc. Etc.
But again, you're lucky, you don't have to deal with any of this.
Man, you're spitting fire!
You can also add this line.
That's good to hear. I've been feeing the same but due to being a junior dev I worry it just comes from a place of inexperience.
Experience definitely helps with estimation, but even extremely senior devs often get estimates wrong. I feel like "just another hour!" is a common refrain...even 1,532,742 hours later... 😂
Ultimately every problem is unique, else there wouldn't be a requirement to estimate. With uniqueness comes a margin of error.
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 😆
My team has to estimate work every sprint, which is expected of course, but when we're asked to estimate how long before a bug is fixed, I simply tell the asker that we won't know until we find the bug. They rarely insist on an estimate, but when they do, I will not budge... because it's obviously unreasonable to demand an estimate to solve an unknown problem. Luckily, the engineering leadership where I work are reasonable about this and back up the engineers when PMs make unreasonable requests.
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.
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!
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).
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
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!
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...
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.