Software project estimation is like drawing a spiderman
Please check this out first (feel free to skip around):
Have you noticed, that drawing a spiderman is very much like building a software project? No? Here's why I think so:
You are an SWE and let's say you have a manager or PM asking you: “How long will it take you to draw a spiderman (“implement X”)? And they are waiting for you to give them an estimate like there's just one definitive way to write a spiderman.
In my experience what tends to happen is that developers just respond with some guesstimate: “Yyyy... I would say... 60 seconds?”, usually on a lower end of the scale.
Ignoring all the other problems with software project estimation, once you realize that there are multiple fundamentally different approaches to drawing a spiderman, each yielding qualitatively different results, you can see that this conversation is backwards.
The right approach is to respond with, either:
- “What kind of spiderman do you need?” or
- “If you tell me how much time I have, I can tell you what type of a drawing I can deliver”.
There's a huge difference between quick and rough prototypes (“10-second spiderman”, as I call them), through more reasonably robust software solutions (“1-hour spiderman”), and a business-grade, scalable, high-quality software projects (“1 day or more spiderman”).
I think just being mindful and explicit about this aspect of software development, can help the communication between technical and bussiness people. An the metaphor here should be very natural and understandable to both sides.