4 ms·
>The concept known as "worse is better" holds that in software making (and perhaps in other arenas as well) it is better to start with a minimal creation and gr
by gambler 5y ago
>The concept known as "worse is better" holds that in software making (and perhaps in other arenas as well) it is better to start with a minimal creation and grow it as needed.
It's a horrible moniker for the concept and most people who use it don't really mean piecemeal growth at all. What they do talk about is usually design where some shortcut allows you to quickly accomplish a short-term goal while completely ignoring long-term consequences. This is the mentality that I see everywhere in the software industry today.
Go is mentioned here in comments as an example of "worse is better". It fits nicely. The main "feature" of the language is that it doesn't have any constructs that would require an average college grad or a disgruntled Java shitcoder out there to apply effort in order to understand the feature. Thus, people grab the language and mindlessly run with it. By the time the codebase grows where you need more advanced features, it's too late to switch.
My prediction is that in a few years when an average Go codebase switches ownership at least once, it will become widely hated, and language developers will start cramming in features that they originally said aren't needed there at all. You've already seen a preview of thing when they replaced cutesey (and obviously broken) dependency management with modules.
- grumblenum 5y agoI don’t think much will change until the incentives change. Right now there is basically no consequence for doing the wrong thing. Software is unique in that defects are generally tolerated. Minimizing time to market can be everything where often winners take all. Thus an incomplete solution today is worth more than a flawless solution in the future. I’m not saying it’s good, but it is a predictable consequence of the market incentives.
- michaelfeathers 5y ago> It's a horrible moniker for the concept and most people who use it don't really mean piecemeal growth at all. What they do talk about is usually design where some shortcut allows you to quickly accomplish a short-term goal while completely ignoring long-term consequences. This is the mentality that I see everywhere in the software industry today. I think the moniker is perfect because that is exactly what piecemeal growth is in nature. That's why code seems to have a biological feel. The rough bit, for we humans, is that code tends toward piecemeal growth because of the economics of change. It is easier to add to something that exists than to make something new, so entities (functions, classes, services) tend to grow in size. We have to step in, as gardeners in a way, to guide structure. I don't know that it was intended by the original people behind micro-services (Fred George comes to mind), but micro-services are a good example of aligning with natural tendency rather than attempting to impose a design and continually falling short. Part of the intent was that you just rewrite a micro-service when it becomes unmaintainable. That's a direct structural correspondence to apoptosis in biology. Cells live for a while, then they are replaced.
- pjmlp 5y agoWhat many Go adopters don't grok is that many of us have seen this "worse is better" movie at theater so many times, that the end is relatively easy to guess, but hey we are just old guys and gals that don't get progress.