5 ms·

> Rapid iteration was a potential source of improvements (never going wrong since you can always adjust next week vs potential big fail every N years) and that

by ardy42 7y ago

> Rapid iteration was a potential source of improvements (never going wrong since you can always adjust next week vs potential big fail every N years) and that it would yield better understanding of users by throwing every possible solutions at them. > It will have to pop and rebalance itself because it leads to fatigue and false sense of progress. Totally agree, it's ended up turning into a stream of pointless side-grades and regressions, forever. Progress come from thoughtfulness, vision, and luck. You can't replace any of that with A-B testing and little experiments.

agumonkey 7y ago
It's doubly odd because as many (I suppose) I firmly believed that faster pace and smaller changes would lead to global improvements (same goes for ajax web..). I think we just blew some social limit. People prefer stability, stability allows for more complex but riskier constructions, society enjoys the working ones even better. I like the notion of seasonality these days.
- Jtsummers 7y ago
  > It's doubly odd because as many (I suppose) I firmly believed that faster pace and smaller changes would lead to global improvements (same goes for ajax web..). A late response, but a response none the less. Faster response time and changes can result in global improvements, but they don't ensure it unless they consider global implications. See also: normalization of deviance [0]. It's very easy to make small changes based only on local considerations. These can, individually or in aggregate, produce a globally worse system. A non-programming example, but I think illustrative: A friend works in aircraft maintenance as an engineer. They use an adhesive to apply patches to aircraft versus bolts and other joining mechanisms (it's less harmful, longterm, to the airframe and less disruptive to the operation of the aircraft being lightweight and not intruding into the airflow). When the aircraft come in for maintenance the worker is supposed to use a disposable plastic tool and some chemicals to remove the adhesive, it is a slow tedious process. So, naturally, the worker makes a local change to improve their flow: a metal tool that quickly scrapes off the old adhesive. Job done, they move on. The decision was made only with local consideration, but the consequence was an extra 2-4 weeks of maintenance on every aircraft this happened to. Why? The metal-on-metal scraping resulted in damage to the aircraft that required repair. Unless you're making changes with the whole system in mind, the consequences can go either way with regard to the global optimum, while moving towards a local optimum. [0] https://en.wikipedia.org/wiki/Normalization_of_deviance https://en.wikipedia.org/wiki/Normalization_of_deviance
  - agumonkey 7y ago
    Thanks, once again, lots to learn from other industries "issues" :)
- MattGaiser 7y ago
  > faster pace and smaller changes would lead to global improvements They need to account for how that changes behavior. It is like Agile development. Sure, adaptability is good. But it has led non-technicals to treat change as free so they now feel ok writing specs on the fly in meetings, creating half baked tickets, or changing a button's color every 5 minutes. By making change seemingly cheap, demand for it soared. Smaller changes at a faster pace mean that no thought is being put into them and they are probably being viewed by fewer people before being deployed. In large companies that have a lot of people, that can easily mean that one developer has no idea what others are doing. It also requires that meaningful feedback be received about them. A friend of mine has a startup and they are endlessly making small tweaks to where things are located. They aren't checking in any meaningful way how that is changing things but rather just guessing based on weekly user numbers.
  - ulisesrmzroche 7y ago
    Bull. Smaller changes at a rapid pace allows for feedback. Meaningful feedback, since you get to see and play with the feature. It’s easier to know what you want once it’s concrete. If you’re deploying continuously to a QA server, there is be no way halfass features get out in prod. Also, no developer needs to know what everyone is doing, and is impossible to ask for it, since people need space in their head for real life problems and responsabilities, not keep track of the minutia of their peers day to day
- ulisesrmzroche 7y ago
  Are y’all deploying broken shit to prod? Why would the app be unstable?
  - buckminster 7y ago
    I think they mean UI stability, not reliability.

by ardy42 7y ago

agumonkey 7y ago

It's doubly odd because as many (I suppose) I firmly believed that faster pace and smaller changes would lead to global improvements (same goes for ajax web..). I think we just blew some social limit. People prefer stability, stability allows for more complex but riskier constructions, society enjoys the working ones even better. I like the notion of seasonality these days.

Jtsummers 7y ago
> It's doubly odd because as many (I suppose) I firmly believed that faster pace and smaller changes would lead to global improvements (same goes for ajax web..). A late response, but a response none the less. Faster response time and changes can result in global improvements, but they don't ensure it unless they consider global implications. See also: normalization of deviance [0]. It's very easy to make small changes based only on local considerations. These can, individually or in aggregate, produce a globally worse system. A non-programming example, but I think illustrative: A friend works in aircraft maintenance as an engineer. They use an adhesive to apply patches to aircraft versus bolts and other joining mechanisms (it's less harmful, longterm, to the airframe and less disruptive to the operation of the aircraft being lightweight and not intruding into the airflow). When the aircraft come in for maintenance the worker is supposed to use a disposable plastic tool and some chemicals to remove the adhesive, it is a slow tedious process. So, naturally, the worker makes a local change to improve their flow: a metal tool that quickly scrapes off the old adhesive. Job done, they move on. The decision was made only with local consideration, but the consequence was an extra 2-4 weeks of maintenance on every aircraft this happened to. Why? The metal-on-metal scraping resulted in damage to the aircraft that required repair. Unless you're making changes with the whole system in mind, the consequences can go either way with regard to the global optimum, while moving towards a local optimum. [0] https://en.wikipedia.org/wiki/Normalization_of_deviance https://en.wikipedia.org/wiki/Normalization_of_deviance
- agumonkey 7y ago
  Thanks, once again, lots to learn from other industries "issues" :)
MattGaiser 7y ago
> faster pace and smaller changes would lead to global improvements They need to account for how that changes behavior. It is like Agile development. Sure, adaptability is good. But it has led non-technicals to treat change as free so they now feel ok writing specs on the fly in meetings, creating half baked tickets, or changing a button's color every 5 minutes. By making change seemingly cheap, demand for it soared. Smaller changes at a faster pace mean that no thought is being put into them and they are probably being viewed by fewer people before being deployed. In large companies that have a lot of people, that can easily mean that one developer has no idea what others are doing. It also requires that meaningful feedback be received about them. A friend of mine has a startup and they are endlessly making small tweaks to where things are located. They aren't checking in any meaningful way how that is changing things but rather just guessing based on weekly user numbers.
- ulisesrmzroche 7y ago
  Bull. Smaller changes at a rapid pace allows for feedback. Meaningful feedback, since you get to see and play with the feature. It’s easier to know what you want once it’s concrete. If you’re deploying continuously to a QA server, there is be no way halfass features get out in prod. Also, no developer needs to know what everyone is doing, and is impossible to ask for it, since people need space in their head for real life problems and responsabilities, not keep track of the minutia of their peers day to day
ulisesrmzroche 7y ago
Are y’all deploying broken shit to prod? Why would the app be unstable?
- buckminster 7y ago
  I think they mean UI stability, not reliability.