Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

boxci.dev

Post reply on HN
Print view View original

61–70 of 221 posts

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

#61

Post by nl »

icebraining wrote: post #43
danpalmer wrote: post #7

Earlier quoted context omitted.

The trick is to break it down until it’s all trivial. That process takes time itself, but you can estimate that much more easily. I’ve recently found I end up giving an estimate of, say, 2 days to get a solid estimate, and then come away from that with 2-5 weeks of tasks that are no more than a day each. Estimates of a day are pretty accurate (for me). Another approach I had some success with was estimating the 80% l…

If you can break them down to such a lower granularity, doesn't that imply the software is trivial? To take an extreme example, how do you break down the software developed by Waymo?

If you can break them down to such a lower granularity, doesn't that imply the software is trivial?

No it doesn't imply this. One granular piece of Waymo's software is "develop a component that understands the external environment as well or better than a human". It's easy to say that, and it's even relatively easy to break that down into risk scenarios etc.

But developing it is.. non trivial. And there are parts in it which it was unclear if they were possible.

But that is because large parts of Waymo were a research project, not software engineering.

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

#62

Post by mettamage »

techsin101 wrote: post #54
msteffen wrote: post #51

I once had a manager who insisted on time estimates, but used them in a way that I actually found valuable. You'd write out all the tasks involved in a project add them all up, and then say "this will take T" Then he'd say, "okay, what would it take to do what you just said in T/2?" Then you'd cut stuff until you got to T/2. The project then, very often, would take me the original T. This seemed to work a lot better…

In UI design you do this exercise where you put everything in 4 categories. Must have, should have, could have and won't have. Take your idea and jam it into these for while being 100% honest. It does the similar thing as you mentioned. But truly like the idea

MoSCoW, I learned this studying CS

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

#63

Post by jariel »

danpalmer wrote: post #7
commandlinefan wrote: post #2

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.

The trick is to break it down until it’s all trivial. That process takes time itself, but you can estimate that much more easily. I’ve recently found I end up giving an estimate of, say, 2 days to get a solid estimate, and then come away from that with 2-5 weeks of tasks that are no more than a day each. Estimates of a day are pretty accurate (for me). Another approach I had some success with was estimating the 80% l…

The problem here is not specificity, it's 'unknowns'.

You run intro problems you don't foresee until you hit them.

The second unspoken Elephant in the room is 'changing requirements' which is the #1 reason for software delay.

Lastly, I would say that Engineers themselves have a tendency to overthink a lot of things and develop all sorts of micro-features that they might think are 'obviously useful' but really just represent bloat. Good example of this is when building an API for another team are the various overridden variations of functions. "Hey they'll obviously need an async version of that" when really it's not obvious.

So combine: unknowns, micro pivots and needless complexity ... and you have 500% over schedule.

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

#64

Post by transitivebs »

This is one of the core reasons why we've built https://saasify.sh, an extremely simple solution to launch FaaS-based businesses and start validating product / market fit in hours instead of months.

I agree with the author in terms of estimates and their assessment of the process, but the point I'd like to make is that the vast majority of those 12 weeks it took them to launch the MVP weren't spent on core, differentiating functionality, but rather on boilerplate that's common to every SaaS product.

Important but non-core features like billing, accounts, documentation, and a marketing site end up causing many projects like this to fail before they even get launched.

If you can launch MVPs like this significantly quicker albeit in a more constrained yet platform-agnostic way (e.g., using serverless functions as an abstraction), it becomes really powerful for makers like the author of this article to focus on core value and ship quickly instead of wasting time on all of this other stuff.

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

#65

Post by jacobolus »

buzzkillington wrote: post #60
jacobolus wrote: post #57

Earlier quoted context omitted.

Your heuristic that someone who has done a dozen previous software estimates will not take more than 177% of their current estimate to finish a “non-trivial software” project seems wildly optimistic to me. Consider that many software projects led by experienced software engineers go so far over time that they are never finished.

No, that's category 3, pi^2, or roughly 10 times the estimate. Category 1 is >I've written a script to get the data from tables 1 to 24 of this database, now I need to write one for table 25. It should take me an hour. >Oh look, it took me nearly 2 hours because I forgot that table is owned by a different user to all the other ones and I didn't have the right permissions.

So to clarify: what the top-level poster here is calling “non-trivial” you are calling “category 3”, and heuristically estimating that it will take 10x longer than anticipated.

But this (a) is still quite optimistic, and (b) ignores variance. The potential time a new research project could take is unbounded.

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

#66

Post by dboreham »

commandlinefan wrote: post #2

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.

Deluded people are everywhere.

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

#67

Post by commandlinefan »

bradknowles wrote: post #30
danpalmer wrote: post #7

Earlier quoted context omitted.

The trick is to break it down until it’s all trivial. That process takes time itself, but you can estimate that much more easily. I’ve recently found I end up giving an estimate of, say, 2 days to get a solid estimate, and then come away from that with 2-5 weeks of tasks that are no more than a day each. Estimates of a day are pretty accurate (for me). Another approach I had some success with was estimating the 80% l…

Breaking it down until it's all trivial is the most non-trivial part of the exercise. If everyone could do that trivially, then there would never be any problems.

And the most time-consuming.

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

#68

Post by cocoa19 »

drspacemonkey wrote: post #5
commandlinefan wrote: post #2

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.

>Yet for some reason people still insist that estimating non-trivial software is not only possible, but trivial. It's always maddening to get into debates about this stuff with project managers who believe this nonsense. I know the Fibonacci point scale is supposed to address this by giving PMs something , but I've only ever seen it turn into time-estimates-by-proxy. These days, I only ever give estimates in terms of…

Most maddening thing I've seen is PM translating agile points to man-hours because that's what upper management requests.

Same people: you must complete assignments in the estimated time, or else, be prepared to work overtime including weekends.

It drives me bonkers.

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

#69

Post by darkerside »

danpalmer wrote: post #7
commandlinefan wrote: post #2

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.

The trick is to break it down until it’s all trivial. That process takes time itself, but you can estimate that much more easily. I’ve recently found I end up giving an estimate of, say, 2 days to get a solid estimate, and then come away from that with 2-5 weeks of tasks that are no more than a day each. Estimates of a day are pretty accurate (for me). Another approach I had some success with was estimating the 80% l…

The biggest problem I've found with this approach is that it drives the prioritization process towards smaller and smaller pieces of work, because those can be accurately broken down and estimated. This means larger, but proportionally much more valuable, pieces of work do not get picked up.

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

#70

Post by mathgladiator »

commandlinefan wrote: post #2

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 really understand what they are actually doing and/or have the leadership to grow people to achieve.

It is not trivial in the least and requires a great deal of lead time to even understand the problem(s). This field is at its infancy, and I dont yet know if my insights can be replicated yet.

I'm thinking of writing a book where I illustrate thought exercises and career challenges that help people grow from junior to senior principal, but it is proving difficult.

Post reply on HN