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 221 posts

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

#181

Post by Kaotique »

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…

I've estimated dozens of projects over the years and in my experience the more you split it up the more the total estimate is going to be. You can even use this a tool to get more budget/time allocated to your project. Break it up as much as you can and no task is ever going to be smaller than 1 hours, but in reality you can do 10 of those tasks per day because if you bunch those 10 tasks together people will estimate 5 hours of work. But now you have suddenly got 10 hours to do the same work!

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

#182

Post by verinus »

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…

I even think that the construction analogy does not hold merrit: I have never heard of a really big project that was a) on time b) on budget.

I think those projects might be best compared to the software projects we think of here...

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

#183

Post by Aeolun »

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.

Estimating non-trivial software is easy. Making those estimates any kind of accurate is the problem.

I was talking with my project manager today, and he was asking me if we could finish on time if we got twice as much time as I estimated. My reply was that we’ve tried that 4 times now, and we’ve never reached the point where we actually finish within the time estimated.

So increasing the time would just mean we fail later, not that we suddenly succeed. I’m firmly starting to believe that work expands to fill the time allocated to it.

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

#184

Post by Aeolun »

meheleventyone wrote: post #177
k_ wrote: post #101

Earlier quoted context omitted.

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”.

The real estimate is ‘as long as it takes’.

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

#186

Post by TeMPOraL »

laumars wrote: post #158
mattmanser wrote: post #153

Earlier quoted context omitted.

For me Joel was spot on in my experience, and I disagree, you are always writing the same code again and again. Just tweaking it a bit to fit the requirements. An easy example is the thousands of JSON APIs you can integrate these days, where the code to do that is almost identical, but not quite. Generally the only complications are in what stupid authentication and pagination method this API came up with. But it hap…

In my experience working in a broad range of fields in IT; web development is quite unlike any other type of development when it comes to code reuse and framework churn.

IME, web frontend might be particularly repeatable once you drop the artistics. But when I was doing desktop development, beyond simple UI issues, almost all work I had was unique and dictated by customer's ever changing and ever weirder requirements. In backend work, similarly, pretty much everything I write is a new and unique flower on a unkempt bush of the overall architecture.

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

#187

Post by TeMPOraL »

cameronbrown wrote: post #143
godzilla82 wrote: post #122

Earlier quoted context omitted.

By we do you mean software engineering in general or bay area? Asking because most people commenting on hn tend to assume the entire universe is just the sf bay area.

Even non-bay area SWE in general is still much better than most other job types and probably much better when it comes to having a nice place to live anyway.

I'd say non-BayArea are relatively in the best position, because remote work always gives a chance for salaries much higher than local to you, while unlike the SF, costs of living won't eat most of what you earn.

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

#188

Post by amirathi »

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 make reasonably accurate (+/- 30%) estimates. I wrote a blog [1] about it if someone is interested but here are the main takeaways,

- Don't just estimate writing code but also include time required for testing, documentation, communication, setting up infra/deployment

- If certain part is hazy ("is there a reliable python library for speech to text") then research it enough to know the path ahead

- Breakdown the system into smaller units until you feel confident to estimate each piece

[1] https://blog.amirathi.com/2018/02/05/science-of-software-est...

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

#189

Post by TeMPOraL »

nl wrote: post #156
icebraining wrote: post #144

Earlier quoted context omitted.

Right, I'm not saying they can't be broken down somewhat, but the parent comment said he broke then down until the tasks are trivial. I don't think that example is trivial! Or that it can be estimated to take up about a day. Regardig the "research" vs "engineering", I don't think you can cleanly separate the two; many otherwise straightforward projects include a research component, even if it is just about using a ne…

For me, research is something where is is unknown if something is possible. Engineering is where we know it is possible, even if it isn't clear how long it will take.

Under that definition, very little is research. Warp drives is research. Curing cancer is engineering.

Obviously, you have implicit constraints in mind. "Is something possible given $constraints?". And the set of those constraints is where the line between research and engineering starts to blur. If you set $constraints to "in time and under budget for the project", which seems like a very reasonable value, then it turns out that a lot of programming tasks become research work, unless you're only churning out cookie-cutter websites.

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

#190

Post by TeMPOraL »

wvenable wrote: post #35
a_wild_dandan wrote: post #12

Earlier quoted context omitted.

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.

That's why I think a more correct analogy is that programming is making the blueprints; the blueprint is the source code, and construction is what compilers do.
Post reply on HN