> 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.
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.
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.
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.
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
These two types of products need completely different approaches to product development. But also, don't teach your grandma Notion - Word's a much sensible option for her.
It will have to pop and rebalance itself because it leads to fatigue and false sense of progress.