It took 12 weeks to ship an MVP I thought would take 3 • Hacker News Board

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

#11

Post by edgarvaldes » Thu, Nov 07, 2019, 11:16 PM UTC

wikiman wrote: post #6

drspacemonkey wrote: post #5

Earlier quoted context omitted.

>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…

This 100% this. I run my teams via "Kanban" (I don't know how kanban it actually is, but that's what I call it). The only question I ask around prioritization is "Is it worth doing?" If the answer is yes, I ask the stakeholder if they care how long it takes. If they do, I ask for a range and give a best estimate if it's achievable. If the answer is no, I ask why they care how long it takes if it's the most important…

> don't know how kanban it actually is, but that's what I call it

We also work with a Kanban-like methodology. Basically a pull system with a hard limit on WIP.

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

#12

Post by a_wild_dandan » Thu, Nov 07, 2019, 11:20 PM UTC

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 think this is due to people adhering to a bad implicit analogy: "Estimating software construction projects must be like estimating other types of construction projects, e.g. bridges or cars." The problem is that most software projects don't have a myriad near-identical existing solutions from which to source a project's duration. We aren't making a building with the exact same floor plan, using the exact same crew size with the exact same skills, in the exact same regions, using...You get the point. It's just a bad comparison.

Most software projects are more like R&D than construction. For the adventurous analogy, software is like hiking an unknown trail. You might generally know where you're going, but you can't foresee the river, detours, and feral hogs you'll have to battle to reach the end.

You simply can't estimate software the way you can more tangible products. You can do Scrum planning poker and pretend your're not playing Numberwang, if that makes you feel more in control.

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

#13

Post by pas » Thu, Nov 07, 2019, 11:22 PM UTC

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.

Estimation needs a baseline. Predicting the time needed for a greenfield (from scratch) project without some experience working on that project with a fixed team ... will lead to misery.

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

#14

Post by mgbmtl » Thu, Nov 07, 2019, 11:26 PM UTC

A colleague from a previous job once told me: "when a developer gives you an estimate, always double and add one of that unit" (estimate = 2n+1). He told me this after a while, because he would often nag me to clarify if I meant 7h or 1 day.

i.e. if you estimate 7h, then calculate 2x7+1 = 15h.

If you estimate 1d, then calculate 2x1+1 = 3d = 21h.

It's a silly joke, but it also gives insight about how we perceive time and the elasticity of estimates.

And of course, instead of multiplying by 2, you multiply by a time factor that depends on the risk factors involved (which are also guesstimates, but for me 'x2' would mean a rather low risk factor).

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

#15

Post by henryfjordan » Thu, Nov 07, 2019, 11:26 PM UTC

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…

You cannot, by definition, break down a non-trivial project into trivial parts without having at least 1 non-trivial part in there somewhere

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

#16

Post by seph-reed » Thu, Nov 07, 2019, 11:28 PM UTC

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.

It's magic, but I'm actually pretty good at it. Pretty much every time I'll say the number, my boss will be unhappy and get me to say a lesser number, then it'll be what I predicted. I have a method, but I'm pretty sure it's just magic.

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

#17

Post by mtlynch » Thu, Nov 07, 2019, 11:31 PM UTC

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 from doing all this that there's a simpler way to name or combine options, you go back and make that change and have to update all the examples, explanations, etc.

You question whether your MVP at that stage was viable, but when I read this, I wondered whether it was actually minimum. Is it possible that you added too many options and your MVP would have been easier to ship if it had been more limited in scope?

>The product did not look like something anyone would want to pay for

One pitfall to look out for is that you probably can't accurately predict what customers pay for until you talk to a real customer. Maybe things like aesthetics that seem important wouldn't actually be important to a customer if your product solves their problem. A designer gave you feedback, and they no doubt have valid expertise, but they're also not your customer.

I had the experience of shipping too late last year:

https://mtlynch.io/shipping-too-late/

tl;dr of my takeaways:

* Even if you've been warned about startup pitfalls a million times, sometimes you just have to make the same mistake to learn it.

* The goal of the MVP should be to get something in the customer's hands ASAP so you can hear their feedback. If you focus on polish and design, you might be polishing something that nobody wants.

* Question whether your "must haves" are actually just ways of delaying scary conversations with customers.

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

#18

Post by notjustanymike » Thu, Nov 07, 2019, 11:31 PM UTC

I've gotten pretty close with two 4 months projects this year (2 weeks off in both cases). It took two weeks of planning, research, and understanding roadblocks to get to that point.

It's doable, really, and it feels an awful lot like waterfall when you're in the moment. The most important steps were:

1. Write it down 2. Don't keep it to yourself

Everyone else is smarter than me and provided immeasurably good feedback.

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

#19

Post by davnicwil » Thu, Nov 07, 2019, 11:35 PM UTC

OP here - this is a sidebar but the HN hug was making the page load really slowly (~10s for me) even though the blog part of the site is cached. Anyway, because I'm using kubernetes all it took to fix it was bumping the nodes in my cluster, 4x the replicas, kubectl apply and it's snappy again! All done in about a minute. What an awesome tool kubernetes is.

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

#20

Post by m0zg » Thu, Nov 07, 2019, 11:36 PM UTC

That's why, when people ask me to estimate work, I tell them that if they need a hard deadline things will (counterintuitively) take much longer, and try to convince them that hard deadlines are bullshit. If you want a hard deadline, I have no choice but to allocate a huge amount of buffer time, at least twice the "aggressive" estimate so that if shit doesn't go as planned (which is what usually happens) I don't miss the deadline. And I have to plan for the worst possible kind of excrement hitting the fan, which is not realistic. And then, in spite of that, people are still under more stress, because procrastination being in human nature, hard shit gets done last, and there's more in it that can go wrong.

Consider instead shipping stuff incrementally, feature by feature, when features are done, without any hard deadlines. Both the speed of delivery and quality will be improved compared to hard deadline driven development.

Plans are worthless. Planning is indispensable.