- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
You must log in or # to comment.
Interesting read!
My key points are:
So how do I estimate, given all that?
I gather as much political context as possible before I even look at the code.and
Finally, I go back to my manager with a risk assessment, not with a concrete estimate. I don’t ever say “this is a four-week project”. I say something like “I don’t think we’ll get this done in one week, because X Y Z
bruh, so it’s not me who was stupid all this time for not being able to put an estimate for large initiatives. It always feels forced to give an estimate.
Definitely not just you! This author is 100% right.
One of the main jobs of a software developer is continually trying to convince people estimates are kind of stupid.
If we already knew exactly how to build something, we would have built it already.
The whole point is that it doesn’t exist, and there are a lot of inherent risks when building something that doesn’t already exist! Like, duh.
The issue, of course, is that everyone not in software thinks it’s like traditional manufacturing and not research and development.
How to estimate:
- Give a range and confidence rating
- Track all estimates and how long it actually took
- Refine future estimates to more closely match past features with similar complexity/effort required
This is entirely true for certain types of development. There are plenty of coding jobs where you are constantly writing and rewriting the same type of thing over and over again. UI development, web page development, ect. Any place we you have multiple “customers” wanting a similar thing done, but with a different look or aesthetic. Or maybe you work for a company that makes stuff that needs to be refreshed every so often to avoid looking antiquated.
But then there’s also lots of people who are constantly doing things that they have never done before. I am not even talking about the poor suckers out there right now have having to “add AI” to random shit right now without even having a clue wtf that even means. You have plenty of people doing what is essentially “we want you to do this thing we have never done before”. How do you estimate time on a ticket that essentially says, take this 30 year old pile of code that has been hacked and rehacked by dozens of people (all who have either retired or left the company to escape this dumpster fire you are being handed) and “fix this bug” that has been around for a decade. It’s been there for a fucking decade. When the first version of this ticket was originally generated it was done in a ticketing system that has been replaced by 2 generations of ticketing systems since then. Whatever the issue is, it’s a big enough issue that it can’t be answered with “can’t do/won’t do”, but at the same time everyone who has been assigned it in the last decade has at best created half ass work arounds. Good luck with pulling a number for how long it is going to take you to figure out what the bug even is, much less how to fix it.
Depending on how stable your work, environment, and risks are, the range size and confidence rating may change a lot or reach refinement limits quite fast.
The only way to estimate work is to make up a number and then log everything that prevents that from happening to put forward a case when the “why?” question comes up when the deadline hits. Then prepare for being told you are making up excuses and being negative and not flexible to all the challenges that you just listed and that you need to manage time better and potentially think about outsourcing some work to people who lie better than you.
Take how long you think it will take, double the number and increase the units (at least until you’re senior). e.g. 2 days -> 4 weeks
I…. am not actually sure if you’re joking or not.
I normally use the Scotty method - multiply by four.
I…. am not actually sure if you’re joking or not.
Bit of Column A, bit of column B…
Maybe it should have been ‘Take how long you think it will take at first blush’. Scotty’s method is good with a bit more experience.
If you have a good manager, you need only double it, because þey’re going to double þat.
