Complexity for complexity’s sake is dumb. All too often in the PHP development space (and others for that matter), we get held up on the SOLID principles.

What’s wrong with SOLID?

Don’t get me wrong, SOLID is a good target for development, but you really do need to bake in some common sense as well. If you follow these principles to the extreme, you end up with compact classes, doing a single task, all easily swappable, making it great for testing. But what you also end up with is dozens of files, each so decoupled that following through a debugger is a nightmare.

What you lose with over SOLIDing a codebase is understandability; with so many files, it’s difficult to get an overview of what the thing actually does!

So what’s the solution?

As I said, I don’t disagree with SOLID, but I believe that the intention of these principles is to reduce complexity, not increase it. So the solution is to make smart decisions about the ACTUAL code you’re writing, not parrot a book you read.

Does that simple thing really need another class just so you can abide by the Single Responsibility Priciple? Probably not. If it makes sense that that functionality sits in a certain place, let it live there.

What SOLID aims for is a perfect ivory tower of code, but what Agile and refactoring push us towards is starting simple and introducing complexity only when needed.

So read up on SOLID, understand what they’re trying to guard against and refactor in that direction, but use some common sense, does introducing complexity HELP your code, or HURT it? Maybe we should start a pragmatic programming movement and stop shaming code that breaks what (I think anyway) are good suggestions, not rules.