Man your telling me. I planned on spending 4 months on https://appdoctor.io and ended up launching it after 1 year and 2 months.
It took 12 weeks to ship an MVP I thought would take 3
111–120 of 221 posts
Re: It took 12 weeks to ship an MVP I thought would take 3
#112I think it depends I work on a large enterprise product we are generally within 20% of the estimate. If some prominent team members were not aggressive in planing that figure would be smaller. Average age on the team is over 40 avg experience around 20 years.
Re: It took 12 weeks to ship an MVP I thought would take 3
#113nice way for marketing. You could have posted a SHOW HN a thousand times and nobody would care, but this is creative way for a succesful SHOW HN
Re: It took 12 weeks to ship an MVP I thought would take 3
#114Earlier 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…
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.
We have a great labor market. Don't be shy about quitting when things get cray-cray!
Re: It took 12 weeks to ship an MVP I thought would take 3
#115OP 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.
Please take this comment in good faith because I'm genuinely curious: why do you need a kube managed cluster of N nodes (an now 4x N) to host a static blog? I wonder what works goes on under the hood that this needs such scale.
The blog is just attached to the product site https://boxci.dev, thats the reason for using kube. Should be separately hosted but this was just simpler.
The static blog pages though are all cached via nginx so I was surprised I needed to increase the nodes & relicas. Short answer is I don't know, and will need to investigate, but I suspect it's because the kubernetes node instances themselves are fairly low powered, there's a low cpu limit on nginx, and perhaps nginx is doing a lot of work serving the js bundle to so many simultaneous users, which really should be hosted on a CDN (probably also the blog).
Re: It took 12 weeks to ship an MVP I thought would take 3
#116Earlier quoted context omitted.
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…
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't need 10-15 persons for an MVP... in fact I'd argue you actually can't truly do an MVP if you have a 15-persons team. You need the large team to expand the MVP, but to identify it/ have a customer-worthy demo, the 15 people will just get in your way.
Re: It took 12 weeks to ship an MVP I thought would take 3
#117How 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 time.
Some clients, especially from the construction industry, expect me to give them GANTT-chart style estimates down to the hour. Here is how I convey the software estimation problem to them:
If I write the same code twice, I done fucked up. So any code I write, is new code. If I can reuse code, I will, but that's not the code you're asking about. In your industry, you have built the same house many times before with the same team, on the same foundation. But you are employing me to design, architect and construct a new house that has never been built before. If it existed already, you would just buy it off the shelf instead of employing me.
So think of me as more of an architect than a labourer, and together with you as the client, we are embarking on a design that you're not quite sure you want yet, that won't collapse on a potentially unstable foundation.
Re: It took 12 weeks to ship an MVP I thought would take 3
#118Earlier 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…
For every project I work on, I make sure I understand the problem, define the requirements, design the solution, and validate any necessary design patterns before I begin planning the implementation. How long that takes depends on the scope of the project, but I have never seen a project save time by skipping that bit. I also end up being pretty accurate with my time estimates.
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.
Re: It took 12 weeks to ship an MVP I thought would take 3
#119I 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 can. Do your estimation normally. If you've done it a dozen times multiply by sqrt(pi), if you've done it a couple of times multiply by pi, if you've never done it before multiply by pi^2. I'm not off by more than 20%.
How can you have an accurate estimate when you're multiplying it by 10? A small error in your original estimate gets multiplied by 10. If I'm off by 10 days in the original estimate, that means I'm off by 100 using your method.
Also, I think by definition, a non-trivial project obviously hasn't been done by you many times before. Doing something you've done a dozen times is trivial in this sense.
Re: It took 12 weeks to ship an MVP I thought would take 3
#120Earlier 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…
Think about how variance propagates through that chain of work though,especially for tasks that are contingent on other tasks...
This is underappreciated. My experience on a carefully-estimated software project was that the median task would come in 20% under budget. However, we still ended up over budget.
Every iteration there'd be one or two small tasks that blew up to >1000% their original estimate.