Live data from Hacker News

It took 12 weeks to ship an MVP I thought would take 3

boxci.dev

71–80 of 221 posts

Re: It took 12 weeks to ship an MVP I thought would take 3

#71
I really wish the estimation process would get turned around. Let stakeholders decide when they need it, and engineers are responsible for delivering the best version they can on that date. As the project unfolds, stay in close communication and make timely decisions about what tradeoffs are acceptable.

My estimates get accurate once I know where we are on the spectrum from quick and dirty to pushing the boundaries of what's possible. There's a 3 month version and a 3 year version of a lot of ideas.

Re: It took 12 weeks to ship an MVP I thought would take 3

#72
My personal experience is that traditional software estimation techniques don’t work when done for a MVP situation. Yes it’s frustrating like hell to not know how long before your money, patience and interest runs out. In a non MVP situation some estimation models work, some 40% of time. But managers make it look like they work all the time. Cutting scope to hit deadline doesn’t count.

Re: It took 12 weeks to ship an MVP I thought would take 3

#73
post #72

My personal experience is that traditional software estimation techniques don’t work when done for a MVP situation. Yes it’s frustrating like hell to not know how long before your money, patience and interest runs out. In a non MVP situation some estimation models work, some 40% of time. But managers make it look like they work all the time. Cutting scope to hit deadline doesn’t count.

Also the Viable part of MVP is subjective. As you build the MVP, your idea of what is viable changes. This needs to be accounted for. The minimum product has to be viable for a paying customer. If the MVP is not a paid product the you can get away with less polish, not so with paid products.

Re: It took 12 weeks to ship an MVP I thought would take 3

#74

I can’t accurately estimate non-trivial software. I’ve never met anybody who can accurately estimate non-trivial software. I’ve never seen anybody claim to be able to accurately estimate non-trivial software. Yet for some reason people still insist that estimating non-trivial software is not only possible, but trivial.

I do it well, but only after I completely understand the problem. For instance, I wrote out a series of design documents, then gathered buy in for management to start hiring. I told them that this will take 2 years to complete, but we can start realizing value in the first six months. Every timeframe was hit without crunch, and everything landed roughly on schedule. The problem is that most people I've met dont reall…

How long does it take to understand the problem and write design documents?

Re: It took 12 weeks to ship an MVP I thought would take 3

#75
Aty place we don't estimate time at all. It's nearly impossible. But value of the fix or feature is loads easier to estimate and measure. Bug $X is worth $10000, dedicated $5000 to fix it. Check progress. Dev says almost done? One more cycle. Still seems far? Punt.

I'm always confounded when managers want a time estimate but cannot provide a value estimate.

The goal is the same: fix important/urgent bugs, develop product and keep good close velocity.

Re: It took 12 weeks to ship an MVP I thought would take 3

#76

I can’t accurately estimate non-trivial software. I’ve never met anybody who can accurately estimate non-trivial software. I’ve never seen anybody claim to be able to accurately estimate non-trivial software. Yet for some reason people still insist that estimating non-trivial software is not only possible, but trivial.

Developers are optimists.

Re: It took 12 weeks to ship an MVP I thought would take 3

#77

I can’t accurately estimate non-trivial software. I’ve never met anybody who can accurately estimate non-trivial software. I’ve never seen anybody claim to be able to accurately estimate non-trivial software. Yet for some reason people still insist that estimating non-trivial software is not only possible, but trivial.

I feel that to get accurate estimates you need the same people using the same tech stacks producing roughly the same solutions week in and week out. I imagine something like making slightly interactive marketing sites using Ruby on Rails every time, Active record every time, etc. These estimates will be perfect.

On the other hand, for a complex SaaS back end and front end doing something unique, a complex system to which you are being asked to add something groundbreaking, where you need to pay off various tech debt as you go in order to get the job done, where you are negotiating the requirements as you go along, and finding dead ends and impossible things that you can't do that you thought were simple and vice versa - I think it is hard to estimate. I think in that case estimation is a waste of time and it should be thought of like a "value train". If there is a genuine deadline (rocket launch) then best to manage it well with appropriate large buffers and dependency management. I don't see this being done anywhere, it is usually the business trying to haggle down the engineers on their estimates (even though the engineers are paid a salary so ???).

Re: It took 12 weeks to ship an MVP I thought would take 3

#78
post #74

Earlier quoted context omitted.

I do it well, but only after I completely understand the problem. For instance, I wrote out a series of design documents, then gathered buy in for management to start hiring. I told them that this will take 2 years to complete, but we can start realizing value in the first six months. Every timeframe was hit without crunch, and everything landed roughly on schedule. The problem is that most people I've met dont reall…

How long does it take to understand the problem and write design documents?

3 to 6 months... maybe longer. The key is to focus that time towards collecting data to help sell to stakeholders.

Re: It took 12 weeks to ship an MVP I thought would take 3

#79

I can’t accurately estimate non-trivial software. I’ve never met anybody who can accurately estimate non-trivial software. I’ve never seen anybody claim to be able to accurately estimate non-trivial software. Yet for some reason people still insist that estimating non-trivial software is not only possible, but trivial.

Many people have the ability to estimate non trivial software, given the number of software products which ship on a schedule and don’t slip. Things like features announced at big conferences. Granted, the companies that do this can add people to projects as necessary, so they can work with months rather than man-months.

Re: It took 12 weeks to ship an MVP I thought would take 3

#80

I can’t accurately estimate non-trivial software. I’ve never met anybody who can accurately estimate non-trivial software. I’ve never seen anybody claim to be able to accurately estimate non-trivial software. Yet for some reason people still insist that estimating non-trivial software is not only possible, but trivial.

I do it well, but only after I completely understand the problem. For instance, I wrote out a series of design documents, then gathered buy in for management to start hiring. I told them that this will take 2 years to complete, but we can start realizing value in the first six months. Every timeframe was hit without crunch, and everything landed roughly on schedule. The problem is that most people I've met dont reall…

Isn’t The hard part understanding the problem and writing the design documents? That is the task which takes the unknown amount of time. Once the roadmap is in place and people are assigned to build the things that have been designed the problems that occur are much more concrete. Unless there is some oversight or omission in the design, change in the requirements. Etc.

How long was the discovery and design document phase on the 2 year project?

Post reply on HN