"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…
It took 12 weeks to ship an MVP I thought would take 3
41–50 of 221 posts
Re: It took 12 weeks to ship an MVP I thought would take 3
#42I 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…
Re: It took 12 weeks to ship an MVP I thought would take 3
#43I 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…
Re: It took 12 weeks to ship an MVP I thought would take 3
#44Developer 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.
Re: It took 12 weeks to ship an MVP I thought would take 3
#45I 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.
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]
Re: It took 12 weeks to ship an MVP I thought would take 3
#46Developer 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.
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
#47Earlier 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
Re: It took 12 weeks to ship an MVP I thought would take 3
#48Interesting 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…
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
#49Interesting 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.
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
#50Earlier 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/
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.