Live data from Hacker News

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

boxci.dev

41–50 of 221 posts

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

#41

"What's the idea for Box CI? A CI service that does everything for you, except for running the builds." Marketing advice: define "CI" near the top of the first page. The word "Integration" is not on the page either. I am familiar with Continuous Integration but not the abbreviation CI. Adding to the confusion, the font on (most of) the home page is sans serif, so CI cee-eye looks like Cl cee-ell. Moreover, you mentio…

Thanks for this. Yeah you're right - it's that thing of when you are so focused on something for ages, lots of things about it seem obvious to you that aren't necessarily at all to other people coming in cold. This is useful feedback.

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

#42

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…

I'd extend this by aiming to have each trivial step be a useful result that can be immediately released to market. If you can't make every step useful, try to get as many as possible useful with a minimum number of steps between useful results. Put a hard estimate on the first few trivial steps, but recognise that it's largely guesswork beyond that. If the trivial product can be released and start earning money then that reduces the pressure for accurate longer term estimates, as the earnings can fund the uncertainty. Recognise that this is an unachievable ideal, but it is at least worth striving for since even an imperfect attempt will deliver some benefit.

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

#43

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…

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?

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

#44

Developer to self: "It'll take me about a week" Developer to development lead: "It'll take about two weeks" Development lead to project manager: "It'll take about 4 weeks" Project manager to self: "It'll take double that plus 2 weeks" Project manager to management: "It'll take 12 weeks" Management to client: "It'll take 8 weeks" Actual time taken: 16 weeks.

Client: Wow, this is the first project that took only 2x time. We usually anticipate 4x.

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

#45

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.

There is also too much given to the importance of hitting the date over hitting the product/market polish, value and fit needed for success. People forget a project was late if it succeeds, they never forget a project on time that failed because it was rushed, buggy and not polished production.

Discipline and time estimates are important, but not more important than a product setup for success. One that is easy to sell and market because it has value, is polished and a good experience.

Game development notoriously is late, and as long as the developers have time to finish it right people forget. Everyone knows when a game company and the business/marketing/financial side pushes out an incomplete or buggy product, it can permanently harm perception.

Valve Time is something that is really common game development where engineers/developers/designers/product people are still in charge and making good solid product. [1] Technology, innovation and especially game development needs time to make it fun, a good experience and a solid product.

Creativity can't always be rushed, there must be "open" and "closed" modes of development, not crunched in "closed" only modes. John Cleese has an excellent talk on managing creativity and I recommend all people I work with watch it, very valuable insight. [2]

[1] https://developer.valvesoftware.com/wiki/Valve_Time

[2] https://www.youtube.com/watch?v=Pb5oIIPO62g

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

#46

Developer to self: "It'll take me about a week" Developer to development lead: "It'll take about two weeks" Development lead to project manager: "It'll take about 4 weeks" Project manager to self: "It'll take double that plus 2 weeks" Project manager to management: "It'll take 12 weeks" Management to client: "It'll take 8 weeks" Actual time taken: 16 weeks.

Client: Wow, this is the first project that took only 2x time. We usually anticipate 4x.

>> We usually anticipate 4x.

All software estimation boils down to the long established scientific methodology:

(2 X what the last person said) optionally plus 2 weeks

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

#47

Earlier quoted context omitted.

Client: Wow, this is the first project that took only 2x time. We usually anticipate 4x.

>> We usually anticipate 4x. All software estimation boils down to the long established scientific methodology: (2 X what the last person said) optionally plus 2 weeks

Years ago I worked with a developer who had a different methodology: 2x, then bump the unit of measure. Thus, 1 day -> 2 weeks; 2 weeks -> 4 months. It's been remarkably accurate over the past couple of decades.

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

#48
post #17

Interesting writeup! Thanks for sharing. >Seems easy right - it's a CLI - just document every option and you're done in half a day. That's what I thought too. >But then you realise that each individual option is its own thing that requires thought to explain, and crucially, interacts with all other options. It's not enough to explain it in isolation. You need to tie everything together. You need examples. You realise…

Yep, the good old "build it and they'll come" trap for the naive engineer that I've stepped into myself. Thankfully, having read Rob Walling's book now I know that marketing comes before code: https://news.ycombinator.com/user?id=rwalling

It's a bit dated now, but most of the advice is still relevant to solo engineers looking to turn solo founders.

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

#49
post #48
post #17

Interesting writeup! Thanks for sharing. >Seems easy right - it's a CLI - just document every option and you're done in half a day. That's what I thought too. >But then you realise that each individual option is its own thing that requires thought to explain, and crucially, interacts with all other options. It's not enough to explain it in isolation. You need to tie everything together. You need examples. You realise…

Yep, the good old "build it and they'll come" trap for the naive engineer that I've stepped into myself. Thankfully, having read Rob Walling's book now I know that marketing comes before code: https://news.ycombinator.com/user?id=rwalling It's a bit dated now, but most of the advice is still relevant to solo engineers looking to turn solo founders.

I like that book too! I wish I had read it before shipping that first MVP.

My notes: https://mtlynch.io/book-reports/start-small-stay-small/

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

#50
post #49
post #48

Earlier quoted context omitted.

Yep, the good old "build it and they'll come" trap for the naive engineer that I've stepped into myself. Thankfully, having read Rob Walling's book now I know that marketing comes before code: https://news.ycombinator.com/user?id=rwalling It's a bit dated now, but most of the advice is still relevant to solo engineers looking to turn solo founders.

I like that book too! I wish I had read it before shipping that first MVP. My notes: https://mtlynch.io/book-reports/start-small-stay-small/

Follow up to my other comment, read your post and it's extremely entertaining - found myself laughing at (you can probably guess) the estimates part and a lot of the other stuff in there I know so well I felt almost as though you were writing my own thoughts better than I could :-)

Very cool to hear from other bootstrappers / solo founders like yourself talking about things they've done, successes yes but also failures and lessons, and that was also my aim with this post. I feel like it's a pretty small niche within the much larger overall 'startup' world.

Post reply on HN