Objections to SOLID principles (Overheard through the years):
“Why should I have to click “Go to Declaration” on four different methods to figure out what happens?”
“I don’t see how refactoring the code adds business value.”
“We have to move faster; SOLID doesn’t let us do that.”
“All these small methods make it hard to find the code I want to change”
“It’s just a user control. It’s too much work to move the Database logic out!”
“I don’t understand the problem. Why does it matter if the ASCX is big?”
“Using Exceptions for flow control is just how it is; we can’t change it, it’s too brittle.”
“Be careful of making changes; we have customers depending on this code.”
“Fix that for new code going forward, but there’s no sense in fixing the code now.”
“Does it really matter that business logic is aware of the ASP.NET pipeline?”
“What’s an interface? I don’t see how that’s useful.”
Complaints (about the code):
“This code is hard to change.”
“I’ll work the weekend to fix this issue.”
“CODE FREEZE. Don’t check anything in for the next two weeks, so we can test everything.”
“It’d be really nice if it didn’t take so long to build the solution.”
“This code doesn’t make sense, it does too much!”
“We should put in more process to be sure code with bugs doesn’t make it into production.”
Design can be fixed. Code can be refactored. Improving the design of code is like Pascal’s wager: even if you lose, you win. If you hear complaints about improving code, listen for the complaints about the code as well: They’re intertwined.
Author’s Note: All of these objections to SOLID can be attributed to multiple people, some senior, some junior. I’m not calling out any one company or team or individual: This is an endemic problem in our industry.
Bonus: On Hacker News today, a similar story titled “Worse is Better” is making the rounds.