These posts are a dime a dozen. Many developers get to that place where they realize the wide gap between what they suspect, or intuitively know, can be done easily/quickly in their software system but for some... reason... just... _can't_ be done quickly, easily. What they know should only take a day (it only took a day when I started building the thing!) now takes two, three, a week...
For the reflective types we start to see, correctly, that it's all rooted in "complexity". I have to _deal_, _contend_, etc. with all these _needless_ _things_ that I didn't have to deal with originally. This "algebra" of symbols was once easy to do math in, but now I can barely add two and two.
Some laugh uneasily at this point and say, "whelp, that's software for you" and go home and smile at themselves in the mirror. Others mull on the idea but don't apply enough rigor of thought to get past the fuzzy thinking where many a soul that's pondered this problem has found themselves stuck.
And so we get posts like this that are more lament and helpless than they are useful. You can toss a rock and hit these posts, they're all over the place.
The only way out of the complexity hell is rigor in thought at every level--at the level of our jobs ultimately, but in this case at the level of analyzing what _is_ complexity. That is by giving it an objective description, and showing what is and isn't complexity.
Many of these dime-a-dozen posts proceed to talk about complexity in relation to abstractions or lack thereof, etc. But they always miss the metrics of complexity.
Complexity is the lack of Simplicity, that's it. And Simplicity is _objective_. I'm not trying to be exhaustive here but you should get the gist:
Clear interfaces
Clear and minimal dependencies
Precise semantics/contracts
Minimal coupling
In any case, these are objective measures. And interestingly have very little to do with the lines of code that implement them.
Give me a system and tell me what it does. Now I don't think there is a proof (yet) that will say that a system is optimal with respect to these simplicity dimensions but I can tell you that if you give me another but differently organized/architected system that does the same thing, one will be _objectively better_ on each of these dimensions than the other and it will be very easy to point and show you the relative winner.
So once a team realizes this, you can optimize the simplicity of your system by having your members give their design pitch and the objective winner will emerge. (Yes, getting your business axioms pinned down, priorities, etc, is a hard problem here, but the fact that I've seen very few people track this whole realization means we haven't gotten _there_ yet. We're still trying to reach Milestone 1.)
Only when Milestone 1 is met, have you gotten your own personal team's optimally simplest solution. But you're still as strong as your team's weakest link (ie, your team's weakest designer/simplicity-optimizer.)
Now here's the thing. To get _good_ at building systems that optimize for simplicity you have to get _good_ at it, and to do that you have to _practice_ it for a long f-ing time.
I've been in industry for a long time and have worked with very smart people, top brass from the big FANG blah blah blah, and what many of these guys get good at, unfortunately it is not simplicity optimization. Not because they're not smart (in fact Alan Kay's "IQ is a lead weight" is spot on in these cases), but because that's not what they have been optimizing for in their careers. They simply have not been focused on simplicity optimization.
To be fair, you actually hurt yourself by trying to optimize for this skill set because it takes so long to master. So if you take time to master it, you are not spewing out code and getting raises with everyone scratching their heads a year later why is everything so complex.
But this question of complexity is all very simple, if not easy: Simplicity is objective. It takes a long time to master it as a skill set.
Why is every single post/discussion about complexity trying to think about or solve it some other way? I suspect it's because no one wants to realize how short they are on the skill set--which sadly is _most_ of our industry from my emprical point of view-- "It must be somethign _out there_ that is the problem, because _I_ am smart, _I_ have been doing this for a while, no, it can't be because I am _short_ a skill...
What I can say for sure though is that the skill set can be acquired with practice. But where is the training simulation, where does one go to practice? In industry, you really have to be quite vigilant and aggressive and calculated about it...
when you say simplicity is objective it means there's only one definition. I would really like to know what that definition is plus where to find such exauhstive list of qualities of simple code.
For the reflective types we start to see, correctly, that it's all rooted in "complexity". I have to _deal_, _contend_, etc. with all these _needless_ _things_ that I didn't have to deal with originally. This "algebra" of symbols was once easy to do math in, but now I can barely add two and two.
Some laugh uneasily at this point and say, "whelp, that's software for you" and go home and smile at themselves in the mirror. Others mull on the idea but don't apply enough rigor of thought to get past the fuzzy thinking where many a soul that's pondered this problem has found themselves stuck.
And so we get posts like this that are more lament and helpless than they are useful. You can toss a rock and hit these posts, they're all over the place.
The only way out of the complexity hell is rigor in thought at every level--at the level of our jobs ultimately, but in this case at the level of analyzing what _is_ complexity. That is by giving it an objective description, and showing what is and isn't complexity.
Many of these dime-a-dozen posts proceed to talk about complexity in relation to abstractions or lack thereof, etc. But they always miss the metrics of complexity.
Complexity is the lack of Simplicity, that's it. And Simplicity is _objective_. I'm not trying to be exhaustive here but you should get the gist:
Clear interfaces Clear and minimal dependencies Precise semantics/contracts Minimal coupling
In any case, these are objective measures. And interestingly have very little to do with the lines of code that implement them.
Give me a system and tell me what it does. Now I don't think there is a proof (yet) that will say that a system is optimal with respect to these simplicity dimensions but I can tell you that if you give me another but differently organized/architected system that does the same thing, one will be _objectively better_ on each of these dimensions than the other and it will be very easy to point and show you the relative winner.
So once a team realizes this, you can optimize the simplicity of your system by having your members give their design pitch and the objective winner will emerge. (Yes, getting your business axioms pinned down, priorities, etc, is a hard problem here, but the fact that I've seen very few people track this whole realization means we haven't gotten _there_ yet. We're still trying to reach Milestone 1.)
Only when Milestone 1 is met, have you gotten your own personal team's optimally simplest solution. But you're still as strong as your team's weakest link (ie, your team's weakest designer/simplicity-optimizer.)
Now here's the thing. To get _good_ at building systems that optimize for simplicity you have to get _good_ at it, and to do that you have to _practice_ it for a long f-ing time.
I've been in industry for a long time and have worked with very smart people, top brass from the big FANG blah blah blah, and what many of these guys get good at, unfortunately it is not simplicity optimization. Not because they're not smart (in fact Alan Kay's "IQ is a lead weight" is spot on in these cases), but because that's not what they have been optimizing for in their careers. They simply have not been focused on simplicity optimization.
To be fair, you actually hurt yourself by trying to optimize for this skill set because it takes so long to master. So if you take time to master it, you are not spewing out code and getting raises with everyone scratching their heads a year later why is everything so complex.
But this question of complexity is all very simple, if not easy: Simplicity is objective. It takes a long time to master it as a skill set.
Why is every single post/discussion about complexity trying to think about or solve it some other way? I suspect it's because no one wants to realize how short they are on the skill set--which sadly is _most_ of our industry from my emprical point of view-- "It must be somethign _out there_ that is the problem, because _I_ am smart, _I_ have been doing this for a while, no, it can't be because I am _short_ a skill...
What I can say for sure though is that the skill set can be acquired with practice. But where is the training simulation, where does one go to practice? In industry, you really have to be quite vigilant and aggressive and calculated about it...