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

171–180 of 221 posts

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

#171

Post by davnicwil »

oblio wrote: post #163
skrebbel wrote: post #93

Earlier quoted context omitted.

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 real short answer is: he doesn't, he could just use Github Pages or similar :-) I'm guessing he likes to tinker.

To be honest that's not it - as in my sibling comment it's just attaching the blog onto the site was the fastest way to go, given that I wanted to keep it on the same domain. The product just happens to be built on kubernetes already, use of kube is definitely not for the blog. I'm actually pretty surprised that nginx couldn't handle the traffic to be honest. Even with the fairly low resources I'd allocated it. It's just cached static content served right from nginx you're seeing there. Now I've seen that this setup isn't really appropriate (at least without being very expensive!), I'll spend the time to put it onto a CDN

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

#172

Post by LoSboccacc »

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…

probably it's because developers tend to estimate the technical part first and foremost. then comes prouctization, then comes integration.

if the estimate is consistently between 3x and 6x, that's what's likely missing.

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

#173

Post by mtlynch »

davnicwil wrote: post #50
mtlynch wrote: post #49

Earlier quoted context omitted.

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

Oh, thanks! I'm glad you liked it.

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

#174

Post by meheleventyone »

jacobolus wrote: post #65
buzzkillington wrote: post #60

Earlier quoted context omitted.

No, that's category 3, pi^2, or roughly 10 times the estimate. Category 1 is >I've written a script to get the data from tables 1 to 24 of this database, now I need to write one for table 25. It should take me an hour. >Oh look, it took me nearly 2 hours because I forgot that table is owned by a different user to all the other ones and I didn't have the right permissions.

So to clarify: what the top-level poster here is calling “non-trivial” you are calling “category 3”, and heuristically estimating that it will take 10x longer than anticipated. But this (a) is still quite optimistic, and (b) ignores variance. The potential time a new research project could take is unbounded.

Yup, padding estimates is akin to what you might do if you had a repeatable process but there was some predictable variance (e.g. illness, machinery maintenance, holidays) rather than a bunch of unknown and exploratory problem solving.

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

#175

Post by phito »

kstenerud wrote: post #98

The thing about estimating is that you can't factor in the things you don't know: - The tool you planned to use has a bug/defect that blocks you. - The people who said they could give you some information you need, can't. - You misunderstood or were misled as to the capabilities of a tool you need. - The parts you need don't actually fit together as planned. - The documentation you were relying on is wrong. - A deliv…

You can add personal problems that can affect focus to the list

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

#176

Post by r41nbowdash »

edoo wrote: post #8
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 do pretty well at it. My method is to identify all the components of a system and individually assign how many days I think I could do it in if I was really motivated. Then multiply by about 2-3 depending on your experience implementing previously similar modules. Then multiply by 2. I usually end up with a conservative time estimate where some things take longer and some shorter but overall it generally works. On…

i ran analysis on our codebase, most of the files had 40% rewrites, with some outliers being 90% rewritten. the file sizes followed linear distribution, usually from 100 to 2000 lines of code. when the 90% rewrite hit a larger files, it accounted for almost 50% of total effort put into development. what i got from this, for a single component i take the ideal estimate then multiple it x2, and do the same x2 project wide. there's additional friction when integrating outside components, but i'm rarely blamed for it, so i don't care that much to put it in estimates.

now the hard part is selling the idea to the management, like "here are our ideal estimates, lets multiply it by 4". when doing freelance work i usually bill for the ideal estimated time multiplied by 2, the rest being my risk, on the other hand any changes in the requirements, or miscommunication is a risk of the client.

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

#177

Post by meheleventyone »

k_ wrote: post #101
cocoa19 wrote: post #68

Earlier quoted context omitted.

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.

I had that too. Also they were negotiating down every last estimate while we were doing "planning poker" which was only a façade and was really us committing to unrealistic man-hours estimates unwillingly.

Or you get someone very senior in the company who rocks up in your planning meeting demanding to know the “real estimate”.

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

#178

Post by Kaotique »

endymi0n wrote: post #135
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 a…

Don't forget the sanity check at the end. If other people also add a lot safety hours then you will end up with an inflated estimation that is hard to sell.

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

#179

Post by mannykannot »

WrtCdEvrydy wrote: post #164
ido wrote: post #155

Earlier quoted context omitted.

> If you find something that accelerates complex projects, let me know Developer experience. I've been working as a developer for a living for 18 years & I thought I was pretty hot-shit 10 years ago already, but I can probably do more today in 4 days than I used to in 4 weeks (or 4 months a few years before that ).

This holds very true up to the architect level.

As learning curves generally flatten out, that is to be expected.

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

#180

Post by tsimionescu »

AmericanChopper wrote: post #145
tsimionescu wrote: post #133

Earlier quoted context omitted.

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

What your describing is exactly the problem that decent planning solves. I can only imagine two possible reasons for the type of pivot you’re talking about. Either the problem you’re trying to solve has changed (not very likely), or your understanding of the problem has. You can avoid that, and all of the time you’ll waste, but simply investing the effort required to properly understand the problem up front. This is…

To give some more context, I'm working in a medium-size, well-established company in its field.

The kind of problem we have when launching a new product is that we can have a well-defined list of everything that is required of the new product to be assured of successf - it's going to take 5 years to build that, with at least 20 people.

What can we cut and still have a successful product, that we can launch in say 1 year (or 6 months) with say 10 people? That is much harder to say, and different product leaders have different opinions, based on discussions with different clients. And the consensus opinion may simply change.

So sure, the architecture is generally driven towards that 5 year product idea, but the short term estimates are always going to be geared towards a specific subset of that. And that subset is easily subject to change, from one quarter to another. We won't throw away the design if that happens, but we will definitely throw away any longer-term estimates.

And charting out a 5-year plan that we would only 're-jig' as priorities change would be a recipe for certain failure - teams change, people leave, etc. You can't hope to have an accurate estimate on that time horizon.

Post reply on HN