I found "A philosophy of software design" to be a well intended but somewhat frustrating book to read.
It seemingly develops a theory of software architecture that is getting at some reasonable stuff, but does so without any reference _at all_ to the already rich theories for describing and modeling things.
I find software design highly related to scientific theory development and modeling, and related to mathematical theories like model theory, which give precise accounts of what it means to describe something.
Just taking the notion of "complexity". Reducing that to _just_ cognitive load seems to be a very poor analysis, when simple/complex ought to deal with the "size" of a structure, not how easy it is to understand.
The result of this poor theoretical grounding is that what the author of A Philosophy of Software Design presents feels very ad-hoc to me, and I feel like the summary presented in this article similarly feels ad-hoc.
Nice article! Simple gets complex very fast when creating systems for business problems. For anyone interested in tools check some tips in a free cc-by book at https://nocomplexity.com/simplifyit/
The actual hard question is probably making even 10% of such wisdom and good intentions survive when the program is bombarded by contributor patches, or people taking Jira tickets. TFA talks about it in the context of strategy and tactics.
Organizationally enforcing strategy would be the issue. And also that the people most interested in making rules for others in an organization may not be the ones best qualified to program. And automatic tools (linters) by necessity focus on very surface level, local stuff.
That's how you get the argument for the small teams productivity camp.
I've written code for a couple of decades. The diagrams in this post are absolutely great. If you're just starting out, try to remember what they say and you'll do really well.
The complexity in our team's code bases have only gotten worse with AI-integrated agents. Maybe it's the prompts we're using, but it's an ironic twist that these tools that promise so much productivity today ends up dumping more tech debt into our code.
It's funny reading the "key contributors to dependency-complexity" -- Duplication, Exceptions, Inheritance, Temporal Decomposition -- because those qualities seem like the standard for AI-generated code.
I have to take special effort to tamp down on duplication in AI generated code.
For me it's not uncommon for AI to draft an initial solution in X minutes, which I then spend 3*X minutes refactoring. Here's a specific example for a recent feature I coded: https://www.youtube.com/watch?v=E25R2JgQb5c
Good on him for designing software in the large on the regular and on the daily. I saw him give a talk once in the round. Without him I would be in a bad way.
The largest successful software system we have is the internet.
So perhaps we should ask ourselves: What can we learn from the internet architecture?
And no that does not automatically mean micro-services. The core idea of the internet is to agree on API's (protocols like HTTP) and leave the rest as implementation details. You can do the same with modules, libraries, classes, files etc.
LLMs are trained on data from humans. That means these “code ergonomics” apply equally to coding with AI. So this advice will continue to be good, and building with it in mind will continue to pay off.
Books by programming theorists often When they define 'complexity' as 'anything related to the structure of a software system that makes it hard to understand and modify the system,' they miss a crucial distinction: the complexity of a supermarket is not the same as that of a telecom company. The primary factor in complexity is functionality and requirements to implement, followed by non-functional requirements, the restrictions of the IT environment, and then the structure of the software itself.
At this point, time becomes a crucial factor. You may end up with a creature that, after passing user testing and certification, has transformed into an unrecognizable monster despite your initial best intentions regarding length and clarity.
11 comments
[ 6.5 ms ] story [ 66.7 ms ] threadIt seemingly develops a theory of software architecture that is getting at some reasonable stuff, but does so without any reference _at all_ to the already rich theories for describing and modeling things.
I find software design highly related to scientific theory development and modeling, and related to mathematical theories like model theory, which give precise accounts of what it means to describe something.
Just taking the notion of "complexity". Reducing that to _just_ cognitive load seems to be a very poor analysis, when simple/complex ought to deal with the "size" of a structure, not how easy it is to understand.
The result of this poor theoretical grounding is that what the author of A Philosophy of Software Design presents feels very ad-hoc to me, and I feel like the summary presented in this article similarly feels ad-hoc.
Organizationally enforcing strategy would be the issue. And also that the people most interested in making rules for others in an organization may not be the ones best qualified to program. And automatic tools (linters) by necessity focus on very surface level, local stuff.
That's how you get the argument for the small teams productivity camp.
It's funny reading the "key contributors to dependency-complexity" -- Duplication, Exceptions, Inheritance, Temporal Decomposition -- because those qualities seem like the standard for AI-generated code.
For me it's not uncommon for AI to draft an initial solution in X minutes, which I then spend 3*X minutes refactoring. Here's a specific example for a recent feature I coded: https://www.youtube.com/watch?v=E25R2JgQb5c
?
So perhaps we should ask ourselves: What can we learn from the internet architecture?
And no that does not automatically mean micro-services. The core idea of the internet is to agree on API's (protocols like HTTP) and leave the rest as implementation details. You can do the same with modules, libraries, classes, files etc.
LLMs are trained on data from humans. That means these “code ergonomics” apply equally to coding with AI. So this advice will continue to be good, and building with it in mind will continue to pay off.