Re:Why Software Jewels Are Rare (1996) [pdf]
by loup-vaillant on Saturday April 03, 2021 @06:49PM
(#26685439)
> Writing easily understood and simple code, code easily maintained and extended by corporate employees, and fast code don't always line up.
Am I misinterpreting your comment, or did you just list 3 distinct items?
1. easily understood and simple code
2. code easily maintained and extended by corporate employees
3. fast code.
In my experience, points (1) and (2) are one and the same. No tension at all. Easily understood and simple code is easily maintained and extended, by anyone.
When I write code, I never try to cater to some junior idiot. I write for myself, 6 months later. Yet people who see my code often compliment how easy to read, use, and extend it is. Junior and experts alike.
Assembler code for old 2D game consoles is unclear, partly because it's not structured programming, partly from rushing out the door and/or generational cruft, and partly from talking to awkward hardware interfaces, and partly from optimizing performance. I've seen C code with #ifdefs to pick different code on x86 and RISC CPUs, which might've made sense as an optimization with CPUs and compilers from 15 years ago. Duff's Device is faster on older processors, but sometimes slower on new processors and compilers.
From what I've heard, microservices address organizational problems more than technical ones, and dependency injection may be more useful in large enterprise projects (not sure, in my minimal experience it creates complexity).
I think that all of performance, clarity, elegance, and replacability (possibly linked to modularity) are values, and software craftsmanship can encompass one or more to varying degrees.