Item — HN Reader

> Stack enough layers - framework on library on abstraction on dependency - and nobody understands what the system does anymore.

This is specious reasoning, as "optimized" implementations typically resort to performance hacks that make code completely unreadable.

> TFA touches this when discussing complexity ("people don't understand how the entire system works"). But treats it as a separate issue. It's not. Bloat creates unknowable systems.

I think you're confusing things. Bloat and lack of a clear software architecture are not the same thing. Your run-of-the-mill app developed around a low-level GUI framework like win32 API tends to be far more convoluted and worse to maintain than equivalent apps built around high-level frameworks, including electron apps. If you develop an app into a big ball of mud, you will have a bad time figuring it out regardless of what framework you're using (or not using)

2 comments

I'm not advocating for unreadable optimization hacks. I'm working within TFA's own framework. TFA argues that certain bloat (frameworks, layers, abstractions) is justified because it improves maintainability through "modularity, extensibility, code patterns."

I'm saying: those same layers create a different maintainability problem that TFA ignores. When you stack framework on library on abstraction, you create systems nobody can hold in their head. That's a real cost.

You can have clean architecture and still hit this problem. A well-designed 17-layer system is still 17 layers of indirection between "user clicks button" and "database updates.

> This is specious reasoning, as "optimized" implementations typically resort to performance hacks that make code completely unreadable.

That really depends on context, and you're generalizing based on assumptions that don't hold true:

Replacing bloated ORM code with hand-written SQL can be significantly more readable if it boils down to a simple query that returns rows that neatly map to objects. It could also boil down to a very complicated, hard to follow query that requires gymnastics to populate an object graph.

The same can be said for optimizing CPU usage. It might be a case of removing unneeded complexity, or it could be a case of microoptimizations that require unrolling loops and copy & paste code.

---

I should point out that I've lived the ORM issue: I removed an ORM from a product and it became industry-leading for performance, and the code was so clean that newcomers would compliment me on how easy it was to understand data access. In contrast, the current product that I work on is a clear example of when an ORM is justified.

I've also lived the CPU usage issue: I had to refactor code that was putting numeric timestamps into strings, and then had complicated code that would parse the strings to perform math on the timestamps. The refactor involved replacing the strings with a defined type. Not only was it faster, the code was easier to follow because the timestamps were well encapsulated.