4 ms·
Without taking the time to make a data-driven argument, I'll just hypothesize that, it's a natural result of lowering the barriers/costs of entry, to making cha
by strgcmc 6y ago
Without taking the time to make a data-driven argument, I'll just hypothesize that, it's a natural result of lowering the barriers/costs of entry, to making changes.
30 years ago, if you worked in software, then you were almost certainly building shrink-wrapped products, that had to "go gold" before being printed onto 1000s of CDs at a factory. How quickly/easily could you change anything? Not for years, typically. Hence, you were very careful to try and build things right the first time, but the ironic thing is, with such long feedback cycles (i.e. you never really got feedback), that all this waterfall-style effort to plan everything and do everything right the first, rarely ever materialized as perfect/seamless UX for the end user anyways. It turns out, you need to iterate to improve.
Nowadays, the pendulum may have swung too far in the opposite direction... it could legitimately be said that, some things are too easy, tinkering with changes is too easy, and thus nobody expects to have to maintain something for a long period of time. If the cost of rewriting everything is low enough, people will be tempted to just do that whenever they change their minds about something, rather than forcing themselves to predict the future upfront and make durable decisions that will survive for 5-10 years out in the wild with no changes.
IMO, there's no single right answer for all scenarios, all products, all forms of engineering, etc. But it's explainable why such trends may emerge over time.
- MaxBarraclough 6y ago> it could legitimately be said that, some things are too easy, tinkering with changes is too easy This is certainly the case in modern game development. It's now routine for a game to receive a major patch within 2 weeks of release. > there's no single right answer for all scenarios, all products, all forms of engineering, etc. Sure. A search engine for cat photos can go ahead with a 'minimum viable product' release, and improve incrementally. Not so for avionics.
- hinkley 6y agoTo be fair, the minimum viable product for avionics is more complex than anything most of us have written, so it's not implicitly wrong.
- MaxBarraclough 6y agoI don't see how avionics' complexity is relevant. Game engines are complex too. Avionics cannot be developed iteratively, for domain-specific reasons. The costs of re-testing, re-certifying, and deploying, would be crushing. Besides that, how can an aircraft be delivered if its avionics are unfinished? What's the gap between 'viable' and 'finished' here? Games are of course a different domain.
- Wowfunhappy 6y agoI think that frequent changes and experimentation are great qualities for new software, which is still figuring things out. However, this should be a temporary state, and it should be clearly communicated to users with some sort of extended "beta" moniker. After some number of years, the software's creators should recognize that their product has matured, and the pace of change should slow down drastically.
- scotty79 6y agoI'd say 50 years is the magic number.
- Wowfunhappy 6y agoJust to be clear, by "some number of years" I was thinking closer to 3–5 years, although I of course understand where you were going with that. :)