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

81–90 of 221 posts

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

#81

Post by paggle »

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 much-derided “execs” who demand time estimates don’t do so out of spite. They do so because their costs are measured in man-months, and a business needs to know how much something is going to cost to decide whether it’s worth building. Also, they may have partner companies who they need to coordinate timelines with.

I’d guess that freelance developers who are paid per project, and thus have to own their P&L, are very good at estimating.

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

#82

Post by chrisweekly »

mathgladiator wrote: post #70
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 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…

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 don't have runway to attempt to plan that far out. Personally, I once endured a project being shelved after 15+ months of solid, productive effort. I've also been the catalyst, at least twice, for adoption of paradigm shifts that ultimately spanned ~2yr timeframes (one was performance as a first-class citizen, and another was incorporating RWD (responsive web design) into a large company's MO. These successful cross-cutting / interdepartmental changes took time, but I don't think either of them could have happened if they'd ever been pitched up front as multi-year projects. Maybe you've just been luckier finding far-sighted decision-makers.

(If I seem bitter, I'm not. Just sharing my lived experience.)

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

#83

Post by chrisweekly »

femto wrote: post #42
danpalmer wrote: post #7

Earlier quoted context omitted.

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'd extend this by aiming to have each trivial step be a useful result that can be immediately released to market. If you can't make every step useful, try to get as many as possible useful with a minimum number of steps between useful results. Put a hard estimate on the first few trivial steps, but recognise that it's largely guesswork beyond that. If the trivial product can be released and start earning money then…

Sounds like "how to build a successful business".

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

#84

Post by chrisweekly »

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'm reminded of the book "The Hard Thing About Hard Things"... and even more, of this also-classic post: https://www.quora.com/Why-are-software-development-task-esti...

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

#85

Post by AmericanChopper »

generatorguy wrote: post #80
mathgladiator wrote: post #70

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…

Isn’t The hard part understanding the problem and writing the design documents? That is the task which takes the unknown amount of time. Once the roadmap is in place and people are assigned to build the things that have been designed the problems that occur are much more concrete. Unless there is some oversight or omission in the design, change in the requirements. Etc. How long was the discovery and design document…

For every project I work on, I make sure I understand the problem, define the requirements, design the solution, and validate any necessary design patterns before I begin planning the implementation. How long that takes depends on the scope of the project, but I have never seen a project save time by skipping that bit. I also end up being pretty accurate with my time estimates.

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

#86

Post by edoceo »

mdtusz wrote: post #59
wvenable wrote: post #36

Earlier quoted context omitted.

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

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.

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

#87

Post by twothamendment »

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…

That is pretty close to how I do it and I'm not the only one who thinks I'm good at it. This only works on a stack and team that I'm familiar with. It works with projects that are days, weeks or a year long.

If you can't break it down you don't understand it and if you don't understand it you aren't ready to estimate it.

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

#88

Post by mathgladiator »

generatorguy wrote: post #80
mathgladiator wrote: post #70

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…

Isn’t The hard part understanding the problem and writing the design documents? That is the task which takes the unknown amount of time. Once the roadmap is in place and people are assigned to build the things that have been designed the problems that occur are much more concrete. Unless there is some oversight or omission in the design, change in the requirements. Etc. How long was the discovery and design document…

That is the hard part, but this is why it requires an inordinate amount of time combined with short term tactical work to keep things running.

Most work can fit within quarters and get executed quickly, but it takes something else to have long term vision.

The discovery process was paying attention and looking at what is actually the goal, and it generally requires the discipline to slow down and focus on the future without giving into the short term time sinks.

I had the benefit of 70-100 minutes per day of being stuck on a boat commuting for years to focus on discovery. The particular project that had a two year vision had about six months of shit to eat in office while thinking and planning on the commuter boat. It is amazing what one can accomplish by simply writing and the time to focus.

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

#89

Post by rhizome »

mgbmtl wrote: post #14

A colleague from a previous job once told me: "when a developer gives you an estimate, always double and add one of that unit" (estimate = 2n+1). He told me this after a while, because he would often nag me to clarify if I meant 7h or 1 day. i.e. if you estimate 7h, then calculate 2x7+1 = 15h. If you estimate 1d, then calculate 2x1+1 = 3d = 21h. It's a silly joke, but it also gives insight about how we perceive time…

That sounds like a relative of a rule of thumb I read once upon a time: projects slip by the units they're estimated in. N weeks slips by weeks, days and days, months, years, etc.

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

#90

Post by mathgladiator »

chrisweekly wrote: post #82
mathgladiator wrote: post #70

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…

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 going on, I'm also working on a design document for a potential 10 year project. I doubt that I will pull this one off since I'm having difficulty finding those quarterly deliverables, but I'll keep grinding away.

Post reply on HN