Live data from Hacker News

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

boxci.dev

201–210 of 221 posts

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

#201
post #86
post #59

Earlier quoted context omitted.

I think most software falls into this category these days. The majority of software based companies are automating processes that humans can or could do manually - they're just being integrators, linking things and tasks together in useful ways. I don't have a statistic, but I'd be willing to bet the majority of code in existence is not algorithmic in nature.

I agree. I've been writing code for 20+ years. It's all been BPA code. Only once, very early did I do any complex algo.

BPA?

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

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

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

#203

Earlier quoted context omitted.

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.

You're almost never wandering into complete unknown. Your original estimate already encompasses your uncertainty; padding it protects you from optimism.

Right but the padding is basically an estimate of how certain you are about your uncertainty. So not only does the original estimate not encompass your own uncertainty but it's completely arbitrarily scaled by multiples of the original estimate. Which is rather to say the original estimate is completely useless. Not to mention the OP is never more than 1/5 of this greatly inflated estimate off!!!

Whereas padding in a more assembly line like situation can actually be measured and forecast from historical data.

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

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

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

#205
post #74

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

#206
post #138

Earlier quoted context omitted.

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?

I used to commute from Bainbridge Island to Seattle. It's not bad for a couple of years, but it starts to get old and isolating. It was very effective for some growth that I went through, but became an annoyance as my designs and ideas began to vastly overwhelm my ability to execute and lead a number of teams to execute.

Looks like a very beautiful place! Of course everything mellows out and becomes "normal" with time.

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

#207

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

#208

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

#209
post #152

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

#210

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?)

Post reply on HN