Over the course of my life I've designed and built many products/projects. Not a single one that had deadlines imposed by the customer was late. It might deviate on non critical feature set but the main course has been always served properly.
I suspect customers that asked you to, say, build a new inventory tracking tool that interfaces with their existing enterprise infrastructure (SAP, Salesforce, etc) didn't ask you to do it in 2 weeks.
So what was asked was probably -reasonable-. If it wasn't, you probably would have dropped the customer/left the company out of frustration.
If it was reasonable, for a sufficiently fully featured solution that you COULD drop features and still have an MVP, then I would fully expect you to do so.
That's PM Triangle 101; you can give on features while keeping cost and time fixed.
That's just how we handle the fact that estimates are wrong, but we have to keep a date (we drop features, or bring on more people if the work is sufficiently parallelizable). This article is about the estimates being wrong.
>"That's just how we handle the fact that estimates are wrong"
Estimates are not wrong. We agree upfront what is guaranteed to be delivered by deadline. The rest is optional. I might do it if I am significantly ahead of schedule or should they decide to continue with my services after initial delivery. Sometimes they order initial product but then prefer to maintain it themselves.
I know, I'm supposed to be modest but it is the truth. And I did not mean just me personally. Some things I did on my own and for some I had to involve team.
I think one of the reasons is that while I am reasonably good at architecture and programming in general I do not really get hung up on processes / languages / tools / technologies etc. What makes me tick is when I see the product working and serving people. That's the only thing I really interested in.
> I know, I'm supposed to be modest but it is the truth.
I don't think you were downvoted because you were immodest (although I'm sure it didn't help) but because your comment doesn't contribute much to the discussion.
Do you have any comments on the content of the article? Do you have any estimation techniques to share? What were the deadlines based on?
>"People estimate the median completion time well, but not the mean."
I do not estimate either. I estimate guaranteed delivery date and what functionality will be delivered by such date.
My "special" estimation technique is probably that I do not always do things in prescribed way. I am not afraid to look outside and find ways that would bring solutions faster (sometimes by much) than the standard recipe.
Here is the example of the unconventional way I used to save someone's butt in 2 weeks when the other company (Certified consultant shop charging $300 per hour per developer) could not do it in 2.5 month
https://news.ycombinator.com/item?id=21055881
What kind of things do you make, how well do you know the technology/domain, what are the customers/users like, and how long out are the deadlines set? Why do you think you're so successful when so many other people have problems with estimating schedules?
I made various things. Two examples to show the range - Enterprise grade business process middleware for Telcos. Software and microcontroller firmware for law enforcement. And then everything in between.
I have never really thoroughly analyzed why I am successful with the estimate and delivery. I think I'd be way more interested in it if I was late. Since I am not I do not really care. I just am and this is enough for me.
I am eternally grateful to my University (nothing to do with comp science btw) and teachers though who taught me not to blindly remember the rules but how create those. I guess this helped me to become who I am.
