>> Complexity has to live somewhere. If you are lucky, it lives in well-defined places. In code where you decided a bit of complexity should go, in documentation that supports the code, in training sessions for your engineers. You give it a place without trying to hide all of it. You create ways to manage it. You know where to go to meet it when you need it. If you're unlucky and you just tried to pretend complexity could be avoided altogether, it has no place to go in this world. But it still doesn't stop existing.
>> With nowhere to go, it has to roam everywhere in your system, both in your code and in people's heads. And as people shift around and leave, our understanding of it erodes.
>> Complexity has to live somewhere. If you embrace it, give it the place it deserves, design your system and organisation knowing it exists, and focus on adapting, it might just become a strength.
I think that's true up to a point, but it misses the distinction between accidental and essential complexity. Essential complexity has to go somewhere, accidental complexity doesn't, and most complexity in software is accidental.
And even when the complexity is essential, IMO it's better off not in the build system. I'll gladly accept more complex code for the sake of a simpler build (even though that theoretically means worse performance). Worst case if I need to do something complex at build time I'd rather model that as "the build system invokes a program that does something complex" than try to express the complex thing in some Turing Tarpit "configuration" language.
Also the point of software engineering is to take the real complexity that actually exists and you can't get rid of and work out how to write simple code to deal with it. Good software architecture does not include complexity because there is complexity in the business. It manages the complexity with simple code.
The trouble is when people say "complex" you don't really know what they mean, though. They often just mean "difficult". Every programmer who wants to use that word needs to watch this: https://www.youtube.com/watch?v=SxdOUGdseq4
> I think that's true up to a point, but it misses the distinction between accidental and essential complexity.
Very respectfully, I think you may be missing the author's point. When you fail to make a home for necessary complexity, it rears its head as unintended complexity in unexpected parts of the system. The source of 'accidental' complexity is unaccounted for complexity.
> When you fail to make a home for necessary complexity, it rears its head as unintended complexity in unexpected parts of the system. The source of 'accidental' complexity is unaccounted for complexity.
If that's what they're claiming then I completely disagree. No, that's not the reason, that's got nothing to do with it. If that were true we would expect e.g. projects with more complicated builds to have simpler code, and IME that's not true.
Again, respectfully, I don't think that follows (or makes much sense). There is not a set amount of complexity for all software that gets apportioned between the build system and the business logic, so that an increase in one necessarily means a reduction in the other.
Instead, each domain space has some degree of inherent complexity, which varies from problem to problem. Failing to account for this inherent domain complexity appropriately will cause it to bubble through at unexpected points throughout the system.
Build systems inherently have a very complex job. A good build system grapples with this complexity and tries to harness it; a bad one pretends it isn't there, and becomes a tangled mess once the (inevitably complex) demands made of it exceed its limited assumptions.
> Build systems inherently have a very complex job. A good build system grapples with this complexity and tries to harness it; a bad one pretends it isn't there, and becomes a tangled mess once the (inevitably complex) demands made of it exceed its limited assumptions.
I don't think this is true. I think that when looked at in the right way the job of a build system (when used appropriately) is actually fairly simple, and most build system complexity is either accidental complexity (either just straight-up bad design, or misguidedly overengineered flexibility in directions that don't matter) or comes from trying to accommodate things that the build system shouldn't have been doing in the first place. When I've seen overcomplicated builds they've never been because the build system made assumptions that were too limiting.
>> With nowhere to go, it has to roam everywhere in your system, both in your code and in people's heads. And as people shift around and leave, our understanding of it erodes.
>> Complexity has to live somewhere. If you embrace it, give it the place it deserves, design your system and organisation knowing it exists, and focus on adapting, it might just become a strength.
- Fred Hebert, https://ferd.ca/complexity-has-to-live-somewhere.html