In Defence of Complexity
Simplicity is only simple if it stays that way.
Yesterday I had pause to think about the nature of complexity. After being confronted with a problem, the first reach was for a quick solution. There was one, and it was simple in its execution.
But we didn’t take it.
Instead we added some complexity. But we did it for good reason. The simple solution was a patch- if it grew it would become untenable. Even at low numbers it would be hard to maintain, and would be hard to migrate.
And so we opted for a more developed solution. One which had the shape of something that could scale, even if it did not have the full implementation of one. But in doing this, we added complexity.
At the time of posing the question, the complexity added comes under the title of not being needed. And so must, at the very least, be defended.
Is the corollary that if it is reasonable that you might need it, and it doesn’t take long to implement, and it will enable work without a re-write — then, maybe you should still do it?
Is that actually just good software design? Always crafting with a view to the health of the code base, and the flexibility of the architecture? After all, only a diamond core of features are ever truly needed. Regardless, it’s a gamble on the future.
The lesson: Is the exception to “You Ain’t Gonna Need It” that it is quick, you might, and it’ll be much easier to do now?
