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

181–190 of 193 posts

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

#181

Post by saalweachter »

pgt wrote: post #115

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…

One of my favorite shows is Grand Designs.

Building a house is probably the most understood human activities; as you stated, you can take a standard design on a normal building lot and throw up a house in a very predictable amount of time. If you've done it enough, you can write down a schedule of when every piece of material and every trade needs to be on site.

Grand Designs always involves some combination of unusual design, unusual sites, and unusual techniques, and frequently inexperienced builders. People set out to accomplish something grand, and usually succeed, but it takes much longer and more money than expected, and especially more than constructing a conventional house on a conventional lot.

Now, besides echoing your point that many novel software projects are much more akin to a Grand Designs house than a cookie cutter ranch in a Midwestern suburb, in Grand Designs one concept that is proved true time and again is that once you are out of the ground -- once you have your foundation in, your gas and water and sewer and electric hookups -- the hard part is over and the job will proceed much more smoothly. It's hard to estimate before you get out of the ground, because the ground is filled with unknowns and unforseen problems. You might still misjudge how long it will take you to finish, particularly the finicky details that always take forever, but this is purely a failure of estimation; an experienced builder could predict the time to spackle, trim, paint, install flooring and built-ins accurately, you just didn't realize it. But under the ground, there are all sorts of problems with rocks and water tables and pipes and whatnot you can't predict.

Do we, as software engineers, have a similar inflection point in our software development? Do we ever get "out of the ground", to the point that most of the unknowns are known and we have a predictable (if still great and difficult) amount of work remaining?

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

#182

Post by antoniuschan99 »

pgt wrote: post #115

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…

This is a great analogy on why it's so difficult to estimate: https://www.quora.com/Engineering-Management/Why-are-softwar...

Estimating should be fun, plus there are various ways, such as estimating as a team (majority wins), t-shirt sizes, etc

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

#183

Post by commandlinefan »

jdc wrote: post #73
mathgladiator wrote: post #69

Earlier quoted context omitted.

I do it well, but only after I completely understand the problem. For instance, I wrote out a series of design documents, then gathered buy in for management to start hiring. I told them that this will take 2 years to complete, but we can start realizing value in the first six months. Every timeframe was hit without crunch, and everything landed roughly on schedule. The problem is that most people I've met dont reall…

How long does it take to understand the problem and write design documents?

According to every project manager/“agile coach” I’ve ever worked with, that would be part of a one-hour “grooming meeting” and if it takes longer than that, you must just be an incompetent developer, in need of more “coaching”.

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

#184

Post by marcosdumay »

andrewstuart wrote: post #46
riantogo wrote: post #44

Earlier 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

Except if you are in sales. If so it's 1/2 of what the last person said, or optionally 2 weeks.

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

#185

Post by marcosdumay »

amirathi wrote: post #171

It's astonishing how many developers resign to the idea that "estimating software projects is impossible". It's impossible when there are either, - Technical uncertainties (e.g. self driving cars) - Human uncertainties (multiple different teams building single large software system) - Scope uncertainties (we don't know what we are actually building until we get into the weeds) Outside of these we should be able to ma…

Scope uncertainty is always larger than the certain part. It's often nearly all of the scope.

Technical uncertainty is also more common than not, unless you are using a dying platform, it will change between the estimation and implementation.

Human uncertainties are an avoidable one, if you work alone. If you are in a team, they are also certain.

Or, to put it shortly, yes it's perfectly possible if you are doing a university project alone in an old platform without an active community.

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

#186

Post by mitchtbaum »

robsun wrote: post #143

In my career I have estimated a lot of project. I tried different techniques and I find https://en.wikipedia.org/wiki/Program_evaluation_and_review_... is the most accurate one. If I was asked to give some hints, I would say: - in optimistic and pessimistic cases don't fear to use extreme values - don't estimate on your own, take reasonable amount of developers with variety of experiences - don't give exact value to…

Yes. I was about to link this too.

From my experiences, I've found that 3x my initial "estimate / goal / ego trip timeline" gives the most realistic picture. Sometimes I can hit my best; most often things come up. It took a little while to accept, mostly because I wanted to do my best always and be able to promise and fulfill it. But Reality hit back, and I had to adjust.

It's hard to see the network effects of each micro-interaction in long range projecting, but once you really break down how long each thing could take, how that would affect each other related part, and who/what else is involved at each step/layer, it clears up the fog.

https://en.wikipedia.org/wiki/Fog_of_war#Military

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

#187

Post by marcosdumay »

davnicwil wrote: post #113
skrebbel wrote: post #91

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

> Should be separately hosted but this was just simpler.

Probably shouldn't. If you are already managing an automated environment, creating another environment that is easier to manage has nearly no upside.

Unless that phrase was meant to use the CDN you talk about later, but again, do you need a CDN to solve the easiest part of your infrastructure? (Or rather, do you have enough traffic so that it isn't the easiest part?)

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

#188

Post by davnicwil »

marcosdumay wrote: post #187
davnicwil wrote: post #113

Earlier quoted context omitted.

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

> Should be separately hosted but this was just simpler. Probably shouldn't. If you are already managing an automated environment, creating another environment that is easier to manage has nearly no upside. Unless that phrase was meant to use the CDN you talk about later, but again, do you need a CDN to solve the easiest part of your infrastructure? (Or rather, do you have enough traffic so that it isn't the easiest…

Yeah my phrasing wasn't that clear there but I essentially meant hosted as in cached on CDN servers, just to reduce load on the nginx instances. Though my best guess at the moment for what was causing things to be slow was just sending the JS bundle to so many simultaneous users. Putting that on a CDN may be enough.

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

#189

Post by davnicwil »

rkangel wrote: post #147

I agreed with everything right up until the "extra time for design" section. I spent last year building a startup and have thought a lot about MVPs. Coming from a background of building big expensive systems, it took a lot to shake the mindset of "do it right from the ground up". My cofounder did a great job at pushing me towards the absolute minimal solution to learn what we wanted to learn - I don't need to spin up…

> What was the problem with launching, and then deciding that design was the next priority and working on it while your product was running?

Great question, and one I asked myself when I was about 2 weeks into the redesign :-)

On reflection, basically no, you're right, there was no reason I couldn't have shipped and then improved the design in the meantime. The thing about it not being good enough for people to pay for was just my opinion - not tested with real customers.

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

#190

Post by chrisweekly »

mathgladiator wrote: post #88
chrisweekly wrote: post #81

Earlier quoted context omitted.

A 2-year horizon -- even for massive, strategically sound projects -- is a non-starter, simply untenable in virtually every situation I've encountered in my 21-yr career in software dev and mgmt and consulting. Not saying you're wrong to think and advise in those terms, just that the opportunity to do so is exceedingly rare. Big public companies tend to be overly constrained by quarterly myopia, and startups usually…

I think it depends on scale and the inertia involved, and my original point was that accurate estimation is possible. There are many other challenges as you point out. I am currently on year two of a five year project. The key (and part of the essential difficulty) is finding quarterly or six month valuable deliverables that help ease anxiety of everyone involved. It is not easy, but it is possible. While all this is…

Right on. Good luck!
Post reply on HN