People get emotional rewards from themselves from making something work that is at the limit of the complexity that they can handle. They often also get emotional rewards from others for making things that others can't understand. (They shouldn't, but they often do.)
Imagine a carpenter going: - "Yeah, so I wanted to test the limits of my abilities so I made the shed nuclear bomb proof, and yeah, that'll be $100k, now I gotta go to the reinforced concrete conference, and do you mind if I use this shed as a reference when applying to the nuclear shelter company that I actually want to work for?"
This carpenter would of course never be hired again. But our industry is overflowing with nuclear bomb proof sheds without much push back. It's incredibly unprofessional.
Yes. There were too many cases of overnight success to ignore that in our field, this works very well.
It may require thinking hard to get code that is simple (like with DRY, KISS principle should be followed in moderation. It is all about tradeoffs as usual).
I still think you could have multiple levels of skill across design and code implementation though
Our profession doesn’t really know what it is, and that makes us easily manipulated.
So they're only good in theory given infinite time, but not in the real world where someone's waiting to be able to use what they're working on?
Most professionals have to wrestle with time constraints. Push hard enough and at some point the carpenter/doctor/civil engineer/whatever firmly says “no”.
What’s the difference in software that unbounded tech debt is permissible?
Clients regularly tell carpenters to “just do X” against the professional’s better judgement. The carpenter isn’t going to call the collapsing Jerry rigged staircase tech debt, instead they tell the client “no, I won’t do it”.
Our profession generally lacks sufficient apprenticeship. We could learn a thing or two from student doctors doing their rounds.
> Our profession generally lacks sufficient apprenticeship. We could learn a thing or two from student doctors doing their rounds.
I'm not sure how apprenticeship would solve this problem in software. To me, the difference seems to be that unlike carpenters, most people in software don't work on a contract basis for specific clients, but as an employee of a specific company. We don't have the authority to just refuse to do what we're told, and even in fairly good workplaces where you can voice technical disagreement without fear of repercussions, at the end of the day you'll often get overruled and have to go along with what you're told.
When did people learn good design?
Is reducing 24 to 6 "good design?" The study controlled for the actual quality of jams.
Avoiding the hard challenges of design at any cost is certainly a factor. I've seen design demonized as waterfall, and replaced by seat-of-the-pants planning almost universally. "Design" is the opposite of "Agile" in some minds.
Time crunches and the "move fast and break things" mentality results in broken things (shocked!). Keeping a sub-optimal system running smoothly requires an investment in complex workarounds.
Customers will always bias towards new features, new buzzwords, and flashy aesthetics. They don't innately understand the benefits of simplicity - they assume more/new is better.
Software developers want to keep up with the rapid pace of technical change; they are intrinsically motivated to adopt newer technologies to avoid getting stuck on a dying career path. New technologies almost always layer on new abstractions and new dependencies - increased complexity is almost guaranteed.
Finally, we're advancing the state of the art of what computation can achieve. Pushing the boundaries of inherent complexity is effectively the stated goal.
All factors steer us towards ever-increasing technical complexity. It takes a force of nature (or really abnormally disciplined, principled engineers) to swim upstream against this current.
What happens is that features new features are added willi-nilli and these take priority over the quality of the overall product - see the triumph of MS Office in the 90s and many other situations of software companies competing.
And the companies have their priorities and their hiring and management reflects these priority even if it's just implicit in what's done. Especially, if you let older software engineers go and push the youger workforce constantly with constant fire-drills etc, and , no one will be "capable of good design" but why should they be?
OTOH, Vernon's DDDD book comes with caveats:
https://dev.to/yakovlev_alexey/do-not-read-ddd-distilled-by-...