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

101–110 of 221 posts

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

#101

Post by k_ »

cocoa19 wrote: post #68
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…

Most maddening thing I've seen is PM translating agile points to man-hours because that's what upper management requests. Same people: you must complete assignments in the estimated time, or else, be prepared to work overtime including weekends. It drives me bonkers.

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.

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

#102

Post by navinsylvester »

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.

Its hard to estimate without breaking it down to smaller tasks and this process is laborious. This process assumes we are tackling stuff in which we already have expertise.

The rule of thumb i use - anything which takes more than 3 days needs to be broken down further into tasks. If any task takes more than 3 days during execution then it needs to be broken down to more tasks.

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

#103

Post by ibudiallo »

It's hard enough to estimate accurately when you are building your own project with no one breathing down your neck. But be a contractor, where your estimate becomes your salary, and you'll find that you tend to give longer estimates.

I once gave a 3 days estimate for a client project. 2 days to make sure I build it right and a third for testing. It turned into a 7 weeks project: https://idiallo.com/blog/18000-dollars-static-web-page

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

#104

Post by photonios »

jrumbut wrote: post #71

I really wish the estimation process would get turned around. Let stakeholders decide when they need it, and engineers are responsible for delivering the best version they can on that date. As the project unfolds, stay in close communication and make timely decisions about what tradeoffs are acceptable. My estimates get accurate once I know where we are on the spectrum from quick and dirty to pushing the boundaries o…

You might find the way Basecamp works interesting: https://m.signalvnoise.com/how-we-structure-our-work-and-tea...

Each project is six weeks. You deliver the best possible version within those six weeks.

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

#105

Post by bcrosby95 »

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…

Some things can't really be broken down into it's trivialities unless you already know the answer.

E.g. I worked on a warehouse app before. None of us ever had before.

If you have no experience with any of this, how do you break down picking: SKU design (ours weren't just random numbers), barcode printers, and barcode scanners to be used in your software project? That part alone took us about 7 weeks. Including a complete SKU redesign because our initial test hardware worked better than some of the stuff we got later.

Nevermind all the hardware integrations, which was also new to us: multiple printers (barcode label, shipping label, pick list, packing slip), barcode scanner, a scale, all seamlessly integrated into the warehouse application.

This also reminds me, one of the services we decided to use had a serious (for us) bug that we didn't find out about until late in the game. They didn't fix it for 3 months and it blocked us for a while. So yeah, you could be very well end up integrating more than once. You can't really break that down into trivial parts.

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

#106

Post by eecc »

darkerside wrote: post #69
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…

The biggest problem I've found with this approach is that it drives the prioritization process towards smaller and smaller pieces of work, because those can be accurately broken down and estimated. This means larger, but proportionally much more valuable, pieces of work do not get picked up.

Hmm, I disagree. The larger and valuable pieces are broken down into quantifiable parts, but are still being done. Less unpredictability, and that’s the point.

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

#107

Post by jdlshore »

paggle wrote: post #81
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…

I don't know about freelancers, but typical fixed-bid RFP responses are lowballed in order to get the work, then they make their profit on the inevitable change requests. So accurate estimates aren't as important as you might think.

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

#108

Post by brigandish »

Being asked "how long will it take?" is actually my greatest fear in tech work. Give me long enough and I'm (fairly) confident I can overcome any other problem, but estimating time, even for seemingly trivial things…

I'll probably give everyone an upvote here as a) it's nice to see I'm not alone, and b) there's some really good tips.

Not sure why every tech interview introduces a whiteboard with an algorithm problem when all they have to do is ask me "how long will this simple command line client take to build" to really see the difference between the way I attack a difficult problem!

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

#110

Post by cpeterso »

jrumbut wrote: post #71

I really wish the estimation process would get turned around. Let stakeholders decide when they need it, and engineers are responsible for delivering the best version they can on that date. As the project unfolds, stay in close communication and make timely decisions about what tradeoffs are acceptable. My estimates get accurate once I know where we are on the spectrum from quick and dirty to pushing the boundaries o…

That's the idea driving agile product development: defining and estimating big projects is hard, so let's do many small projects (sprints). If the stakeholders have a hard deadline, you can ship whatever you have then because your product is supposed to be in a shippable state, though possibly with reduced functionality, at the end of each sprint.
Post reply on HN