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

131–140 of 221 posts

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

#131

Post by themmes »

Thanks for sharing, I just quit my sideproject after a year of coding and find posts like this helpful to learn from that experience.

> Then I stopped, took a step back and looked at the product from the perspective of someone who would want to pay for it.

Though I think this is dangerous advise. You do not know what this perspective is like (unless maybe when your product is a “scratching your own itch”-type product) and therefor making design changes makes no sense. You will never know if users maybe even preferred your first “design”, or that there is a different blocker like landing-page, installation-instructions or anything really preventing them from starting using it.

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

#132

Post by meh2frdf »

Scarblac wrote: post #121
olooney wrote: post #33

Earlier quoted context omitted.

This is better than not breaking it down, but it's still not very good. McConnell advocates this approach strongly in his book on software estimation[1], and I've seen it work to some extent. It works for reasonably repeatable projects that are very similar to earlier projects you have experience with. But when we get into seriously non-trivial projects that are more "R" than "D"... well, it just isn't enough. The pr…

I have that now in a project. I have two things that need t o be made where I just don't know if I'm going to get them to work well within the larger design I have in mind. I wanted to prototype them in the summer but the backend wasn't ready so I only had very small mock data served in an unrealistic way. The only thing I can do is move them to the front of the project as much as possible, so we have the risky bits…

That’s why you do a time boxed spike, ie a fixed amount of time to do the investigation so you can work out your preferred approach. After you have sufficient knowledge then you can estimate.

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

#133

Post by tsimionescu »

AmericanChopper wrote: post #129
tsimionescu wrote: post #118

Earlier quoted context omitted.

What I have seen several times with that approach is a wonderful plan that needs to get scrapped about half-way through when the requirements suddenly change, for various market-related reasons. Some sketch of the end-design is always important, thinking about major components and future evolution, but a detailed plan has never been worth it in my line of work.

If you’re making radical changes to your design half way through, then you didn’t understand the problem you were trying to solve to begin with, and possibly didn’t define your requirements properly either. If small changes to your requirements mean you need to do significant redesign, then you didn’t design your solution properly. The most generous way to view what you described is that you’ve had to cancel your pro…

The problem I was alluding to is exactly one of requirements - requirements aren't always exact, and they may change in unexpected ways as time goes on. In my experience, this is relatively common when building products that have a long time to market: since there are no hard requirements to begin with, just guesses on what features would be useful to have, it is easy for different marketing and product people to have different opinions and change their minds on what is or isn't an important feature.

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

#134

Post by tsimionescu »

virgilp wrote: post #116
tsimionescu wrote: post #97

Earlier quoted context omitted.

The problem is that in many business domains, the absolute minimal viable product, or even a customer-worthy demo, is a 6 month long, 10-15 person project. If the market already has complete solutions available, releasing an app which does 5% of what other apps do + 1% that's different is simply not viable, and is likely to help you never get a second look.

Well, yes, kinda, sorta. If you go into a market that already has a complete solution available, and that solution works well, you need to be at least as good as competitors. But the way you go into a market is by figuring out what doesn't work. What is an unaddressed pain point. This is a hard thing to do by definition (that's why the payout of being successful at it is so big), but if you manage to do that, you don…

The view in my company at least is that even if you have a strong differentiator feature, if you don't have more or less all of the baseline features that all the established products are doing well, people will take a look at your MVP because they like your killer feature, try to use it, find out that it doesn't do all the things they need, and never look at it again, even if you do fill those features later on.

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

#135

Post by endymi0n »

pgt wrote: post #117

How did you manage to constrain the time overrun to only 4x? As a mercenary engineer, I've had to answer the estimation question many times. Whenever I've given estimates, it has only ever shot me in the foot. Spolsky might have figured it out, but I haven't. So I try to avoid giving estimates as far as possible and instead focus on demonstrating velocity of a working system they can choose to stop funding at any tim…

Having done hundreds of small to mid sized projects I take comfort in the fact estimating is a very distinct task that even the best of developers learn last.

I've got three tricks in my pocket that at least help me with this:

The first is that I go by the formula mentioned in "The Mythical Man-Month" — which is that the effort in larger projects is distributed as follows:

1/3 planning 1/6 coding 1/4 component test and early system test 1/4 system test, all components in hand

Developers tend to mainly estimate their coding time, which leads exactly to the effects mentioned. It also explains all the annoying situations with all the holdups once the project is "almost done", this is simply a systems test and will add another 25%.

The other is that I simply add 5-10% on top for each person involved into the project (dev, stakeholder, anything) for communication overhead. It usually holds true.

The third trick is meticuluous focus on lean delivery, which involves scoping down, early testing on as much as possible, hidden and pre-deadlines and setting tractable sub-milestones.

Unfortunately, all of these techniques don't accelerate the project, they just help you be more realistic. If you find something that accelerates complex projects, let me know ;-)

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

#136

Post by radicalbyte »

bcrosby95 wrote: post #105
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…

Some things can't really be broken down into it's trivialities unless you already know the answer. E.g. I worked on a warehouse app before. None of us ever had before. If you have no experience with any of this, how do you break down picking: SKU design (ours weren't just random numbers), barcode printers, and barcode scanners to be used in your software project? That part alone took us about 7 weeks. Including a com…

I do something similar to the OP when working on established systems.

The trick is to treat everything that you can't break down to a triviality as an area of research until you've solved that problem.

So, say, you plan three days in a sprint to research a certain requirement, the results being a set of small east-to-estimate features and maybe more tricky features.

If you're working in an area where your team have absolutely 0 experience then there's no way you can estimate anything accurately. In these cases I hope that you're working with a small team (2-3 developers and a BA/PO) who are highly experienced and work well together. Then you should run flexibly with features. Work Kanban style and implement the 80/20 effort/win features - and don't be scared to drop a feature if it's looking like it's not part of the 20% effort group of features.

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

#137

Post by meh2frdf »

jammygit wrote: post #53
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.

How do you do estimates for contract jobs then? Clients are very uncomfortable when you say “between X and 3X weeks”

Often it’s the assumptions that go into an estimate that are critical, and defining them along with the estimate. Often it’s problem and delays at the client side that delays things or makes them harder.

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

#138

Post by q-base »

mathgladiator wrote: post #88
generatorguy wrote: post #80

Earlier quoted context omitted.

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…

That is the hard part, but this is why it requires an inordinate amount of time combined with short term tactical work to keep things running. Most work can fit within quarters and get executed quickly, but it takes something else to have long term vision. The discovery process was paying attention and looking at what is actually the goal, and it generally requires the discipline to slow down and focus on the future…

Completely off topic, but somehow I find a daily commute via boat seem like a nice and cosy way of going to work. Where did you go from and to, if you mind sharing?

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

#139

Post by eberkund »

alttag wrote: post #47
andrewstuart wrote: post #46

Earlier quoted context omitted.

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

8 weeks => 16 months, 2 months => 4 years

???

Doesn't seem consistent

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

#140

Post by robert_tweed »

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…

I'm stealing this with the caveat that it could put pressure on a developer to work out requirements, which isn't always what you want. If used correctly, to remove "gold plating" from an MVP, this seems like a great technique.

Another estimation trick that I've found to be very effective over the years is to start with the same sort of task breakdown and finger-in-the-air estimates. Next, start to make a mental list of all the things that could possibly go wrong with each of those tasks. Add those to the list. Most developers with some experience don't add these initially because they don't consider them to be "tasks", but can come up with a huge list surprisingly easily when prompted. Now factor in all the extra time for dealing with those unexpected-but-will-definitely-happen issues.

The original estimate is your best-case, since almost all developers tend to estimate optimistically. The new one is the worst-case.

A good rule of thumb is that the worst-case is 16x the best case, so if you got less than that, it's a good indication you didn't think of enough things that can go wrong. If it does follow the typical curve, 4x the best-case estimate will be a good expected-case (75% chance of success).

What this manager did right was prioritising the tasks, because estimates are just the starting point. The next thing is to know what absolutely must be done for MVP and what is nice-to-have.

If you have 3 weeks to launch an MVP then that MVP needs to be achievable in about 4 days. Otherwise you are setting unrealistic expectations. If you actually finish it in 4 days (unlikely) then well done. You can start adding polish in order of priority, starting with a load test in production to find out as many "unknown unknowns" as possible.

Post reply on HN