undefined | Better HN

0 pointsmadeofpalk3y ago0 comments

> Nothing about building software, especially innovative software is predictable.

This is basically exactly the point. It's incredibly difficult to predict building 'large software'. So, lets try a few things to help make it a little bit more predictable by trying to predict smaller increments.

> Why do we need predictable deliveries?

Say I'm building a piece of software - maybe an app the audience would use - for the Superbowl. It's very handy to be able to estimate our progress to see if we'll actually land that date. The Superbowl isn't going to move because of our app, and our app isn't very useful the month after the Superbowl.

0 comments

stitched2gethr3y ago

This argument comes up a lot but this is a very narrow case. Neither you nor I are building software for the super bowl, and if we were building something with such high stakes we should start way, way early and concentrate on core functionality first. There's no real deadline for the feature we decided we needed last week.

madeofpalkOP3y ago

It's not the Superbowl, but I built software for a national sporting event during my time working on VOD for a broadcaster in Australia.

I think this sort of thing - where what you're building has external hard-to-move dependencies - comes up more often than you think. Those election visualisations on NYT didn't build themselves. There's often a bunch of less-hard-but-still-inconvenient dependencies as well - you're building software for hardware, or there's advertising campaigns in planning/motion.

j / k navigate · click thread line to collapse