3 ms·

I have to respectfully disagree with #1. Software is hard because we 'don't know the unknowns'. It's not like building a building - if it were, we could just

I have to respectfully disagree with #1. Software is hard because we 'don't know the unknowns'. It's not like building a building - if it were, we could just schedule it down to each detail. We would be still all be using 'waterfall'. If we knew how to write the module, we'd just do it, test it, and voila. But most of our time is spent 'figuring stuff out'. Oh, product has asked for a tiny change (support a specific kind of font), but our libraries don't support that, meaning major possible architectural changes. The other major unspoken factor is that requirements change. In fact, this is the #1 thing, really. Requirements change because customer's needs change, because business changes because our understanding of the market changes, etc., and this is a reality of our world. So the nature of how we're going to adapt is difficult to predict. This is why the #1 predictor of outcomes is the quality of developers on the team i.e. experience, intelligence, know-how of the domain. If you're doing something where there are very few unknowns, well then it should be possible to schedule within reason.

icebraining 8y ago
It's not like building a building - if it were, we could just schedule it down to each detail. We would be still all be using 'waterfall'. I hear that it doesn't work that well for buildings either, as you end up with people in the field detecting bugs in the plans and having to improvise fixes without input from the designers.
- sonnyblarney 8y ago
  For actual buildings, they spend a fortune up front planning. Soil and dirt samples at $100K - just to do a bid on a project, let alone the actual build. Can't spend $500M on something only to find you have to tear it down. Software is not magic, but it does require thoughtfulness and experience ... (hint to all those who think startups require mostly new/young blood - it's mostly wrong, but that's for another post)
dmichulke 8y ago
> The other major unspoken factor is that requirements change Walking on water and developing software from a specification are easy - if both are frozen - Edward Berard
- AstralStorm 8y ago
  Also when the dependencies are frozen. If these change, you're walking on mud. It sucks. Comparably it'd be as if building developer built from prefab that changes the design every week.

icebraining 8y ago

It's not like building a building - if it were, we could just schedule it down to each detail. We would be still all be using 'waterfall'. I hear that it doesn't work that well for buildings either, as you end up with people in the field detecting bugs in the plans and having to improvise fixes without input from the designers.

sonnyblarney 8y ago
For actual buildings, they spend a fortune up front planning. Soil and dirt samples at $100K - just to do a bid on a project, let alone the actual build. Can't spend $500M on something only to find you have to tear it down. Software is not magic, but it does require thoughtfulness and experience ... (hint to all those who think startups require mostly new/young blood - it's mostly wrong, but that's for another post)

dmichulke 8y ago

> The other major unspoken factor is that requirements change Walking on water and developing software from a specification are easy - if both are frozen - Edward Berard

AstralStorm 8y ago
Also when the dependencies are frozen. If these change, you're walking on mud. It sucks. Comparably it'd be as if building developer built from prefab that changes the design every week.