3 ms·

I think the main reason codebases are ever-growing is that we never ask, in a serious way, the question "could this be much smaller". I can't recall a company w

I think the main reason codebases are ever-growing is that we never ask, in a serious way, the question "could this be much smaller". I can't recall a company where there was ever a concerted effort to consistently refactor a codebase for conciseness, nor where the inevitable breaking changes from that activity would be tolerated. It is difficult to find an economic argument for such activity but it bears a significant resemblance to a "tragedy of the commons" scenario. By contrast, if I look at my large private codebases, which I religiously refactor and modernize every few years if I think I could improve them even on elegance grounds, have shrunk in size and complexity by a significant integer factor over the many years. And this observable shrinkage happened while adding significant features and materially improving scalability, performance, parallelism, and robustness. The difference is that I can break my APIs and architectures anytime I want and the only person who is mildly inconvenienced is me, and I don't have to justify the time spent doing so. If I look at the mechanics of how the shrinkage happens, I invest a lot in building highly refined code tools that replace recurring development patterns seen across codebases, and then deploy them everywhere that pattern occurs. It is a kind of inductive library building, done to high standard. Again, not a pattern I see much in other large codebases. If the code works, we rarely change it, and it is difficult to justify this kind of tool building when we could be shipping features instead. I understand why the incentives in engineering organizations of any size will never encourage working this way, except outside perhaps the occasional small team. There is a strong bias toward maximizing convenience and minimizing transaction costs in the moment, which are felt keenly. Whereas, the significant drag on productivity and maintainability is highly diffuse and only felt over a long time.

prepend 3y ago
> I think the main reason codebases are ever-growing is that we never ask, in a serious way, the question "could this be much smaller" I think we do ask this question, but code bases grow just like cities grow. We have more stuff and do more things and have more people. I think there is a curation and pruning process but still gets bigger over time. Even with serious refactoring, the codebase still grows as the deleted portions are still available in the codebase for reference.
Pet_Ant 3y ago
> It is difficult to find an economic argument for such activity but it bears a significant resemblance to a "tragedy of the commons" scenario. To me the canonical example of this is base-10 numbering system. If we were base 12 (and it's not unheard of), we'd have the best properties of both the metric system (being based in the radix of the number system) and imperial (half units that are easily divisible into common integer fractions, halves, thirds, quarters, etc). Blank state, no doubt, base-12 is better. But now imagine the costs of switching our society to base-12 when the US cannot even get with Celsius which is clearly the most intuitive of the metric measures. Some things are truly moot and require seismic events to ever be possible to change so they are effectively set in stoneas far as mortals are concerned. PS- for those interested: https://en.wikipedia.org/wiki/Duodecimal https://en.wikipedia.org/wiki/Duodecimal PPS- base-16 is not covenient for thirds, and really only makes sense for a society anticipating binary logic
jmercouris 3y ago
That is exactly what we do in our codebase for Nyxt, and I assure you, it is not cheap. However, the benefits are very tangible. It depends, are you making a premium engineering product, or something quick?
kjkjadksj 3y ago
For me it seems like I spend at least 10x as much time making something lean vs bloated and ugly. Unfortunately I am not measured by lean code but by output of other things, so in the end the code base reflects these incentives.

prepend 3y ago

> I think the main reason codebases are ever-growing is that we never ask, in a serious way, the question "could this be much smaller" I think we do ask this question, but code bases grow just like cities grow. We have more stuff and do more things and have more people. I think there is a curation and pruning process but still gets bigger over time. Even with serious refactoring, the codebase still grows as the deleted portions are still available in the codebase for reference.

Pet_Ant 3y ago

> It is difficult to find an economic argument for such activity but it bears a significant resemblance to a "tragedy of the commons" scenario. To me the canonical example of this is base-10 numbering system. If we were base 12 (and it's not unheard of), we'd have the best properties of both the metric system (being based in the radix of the number system) and imperial (half units that are easily divisible into common integer fractions, halves, thirds, quarters, etc). Blank state, no doubt, base-12 is better. But now imagine the costs of switching our society to base-12 when the US cannot even get with Celsius which is clearly the most intuitive of the metric measures. Some things are truly moot and require seismic events to ever be possible to change so they are effectively set in stoneas far as mortals are concerned. PS- for those interested: https://en.wikipedia.org/wiki/Duodecimal https://en.wikipedia.org/wiki/Duodecimal PPS- base-16 is not covenient for thirds, and really only makes sense for a society anticipating binary logic

jmercouris 3y ago

That is exactly what we do in our codebase for Nyxt, and I assure you, it is not cheap. However, the benefits are very tangible. It depends, are you making a premium engineering product, or something quick?

kjkjadksj 3y ago

For me it seems like I spend at least 10x as much time making something lean vs bloated and ugly. Unfortunately I am not measured by lean code but by output of other things, so in the end the code base reflects these incentives.