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

31–40 of 221 posts

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

#31

Post by mynameisvlad »

mikepalmer wrote: post #28

"What's the idea for Box CI? A CI service that does everything for you, except for running the builds." Marketing advice: define "CI" near the top of the first page. The word "Integration" is not on the page either. I am familiar with Continuous Integration but not the abbreviation CI. Adding to the confusion, the font on (most of) the home page is sans serif, so CI cee-eye looks like Cl cee-ell. Moreover, you mentio…

CI is a pretty widely understood industry abbreviation at this point.

> Adding to the confusion, the font on (most of) the home page is sans serif

I mean, except the logo at the top of every page.

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

#32

Post by eyegor »

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 find I can "accurately" estimate it by estimating the time for each major feature, and then tripling that number. Typically I ship ahead of schedule, even with glitch ups. Of course if you're in uncharted territory you should spend more time making sure your funding is secured regardless of ship date. Nothing worse than having the rug pulled out beneath you one day.

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

#33

Post by olooney »

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

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…

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 problem is that on a non-trivial project, these breakdowns are guesses which carry considerable uncertainty. And the less you know, the more the unknown-unknowns get you. If you write a detailed breakdown of a major piece of software before writing a line of code, at the end of the project you will look back and laugh and laugh at your own innocence.

As just one random top-of-mind example, consider Carmack writing Doom's rendering engine[2]. He tried several approaches that didn't work before striking the right balance with pre-computed BSPs. Some of the things he tried were fundamentally good ideas and would later be used for different games - but didn't work on the hardware of the times. How do you estimate something like that? "I'm going to spend a month on my first approach. That could be one month or two. If that doesn't work, (50% chance), I'll read research papers and textbooks (1 week - 3 months) until I find a promising technique. Then I try the most promising of these; since this is an approach I haven't even read about yet, it could be one week to implement, or six months. And there's some chance that will fail to and I'll have to do it again." The final estimate is anywhere from one month to a year. You just can't know.

[1]: https://www.amazon.com/Software-Estimation-Demystifying-Deve...

[2]: https://twobithistory.org/2019/11/06/doom-bsp.html

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

#34

Post by m12k »

I think most programmers tend to do their estimates in this wonderful parallel dimension where the code base they will be working on is pristine, with well-designed, documented and thoroughly tested code that they get to work on without interruptions or meetings of any kind.

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

#35

Post by wvenable »

a_wild_dandan wrote: post #12
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 think this is due to people adhering to a bad implicit analogy: "Estimating software construction projects must be like estimating other types of construction projects, e.g. bridges or cars." The problem is that most software projects don't have a myriad near-identical existing solutions from which to source a project's duration. We aren't making a building with the exact same floor plan, using the exact same crew…

Construction projects have detailed blueprints used to construct the estimate. Developing the blueprints is much more like developing software and probably has similar issues with estimating the time it takes, effort, etc. But nobody ever compares that. There is no construction phase in software (except compiling); the entire project is the planning stage.

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

#36

Post by wvenable »

thijsvandien wrote: post #23
henryfjordan wrote: post #15

Earlier quoted context omitted.

You cannot, by definition, break down a non-trivial project into trivial parts without having at least 1 non-trivial part in there somewhere

The non-trivial part might be combining the trivial parts. :)

This is a good point and something probably not caught in the estimation of the smaller trivial parts.

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

#37

Post by nostrademons »

thijsvandien wrote: post #23
henryfjordan wrote: post #15

Earlier quoted context omitted.

You cannot, by definition, break down a non-trivial project into trivial parts without having at least 1 non-trivial part in there somewhere

The non-trivial part might be combining the trivial parts. :)

Right, and it will take potentially unbounded time.

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

#38

Post by thaumasiotes »

wikiman wrote: post #6
drspacemonkey wrote: post #5

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

This 100% this. I run my teams via "Kanban" (I don't know how kanban it actually is, but that's what I call it). The only question I ask around prioritization is "Is it worth doing?" If the answer is yes, I ask the stakeholder if they care how long it takes. If they do, I ask for a range and give a best estimate if it's achievable. If the answer is no, I ask why they care how long it takes if it's the most important…

> If the answer is no, I ask why they care how long it takes if it's the most important thing to do.

Well... would you rather get $150,000 two years from now, or $90,000 next month?

You generally don't want to be making any decisions off ordinal comparisons.

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

#39

Post by andrewstuart »

Developer to self: "It'll take me about a week"

Developer to development lead: "It'll take about two weeks"

Development lead to project manager: "It'll take about 4 weeks"

Project manager to self: "It'll take double that plus 2 weeks"

Project manager to management: "It'll take 12 weeks"

Management to client: "It'll take 8 weeks"

Actual time taken: 16 weeks.

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

#40

Post by davnicwil »

m12k wrote: post #34

I think most programmers tend to do their estimates in this wonderful parallel dimension where the code base they will be working on is pristine, with well-designed, documented and thoroughly tested code that they get to work on without interruptions or meetings of any kind.

The thing is in this case I'm building this thing from scratch on my own, so literally without interruptions or meetings of any kind, and all the code, architecture, devops, everything is exactly how I want it, and the estimate is still wildly wrong :-)
Post reply on HN