- Single responsibility principle
- Open-closed principle
- Liskov substitution principle
- Interface segregation principle
- Dependency inversion principle
SOLID is good.
SOLID is not gospel.
The first rule of programming should be "use your brain." The first answer should always be "it depends." SOLID is not a silver bullet (because, as we know, there is no such bullet). There are going to be times where you need to write some code that is not pretty. Sometimes we acrue technical debt for valid reasons. Usually the reason is we need to implement some feature or bug fix fast, possibly because we're losing customers.
It really comes down to what Jeff said: "Quality really doesn't matter that much, in the big scheme of things." What matters is what we deliver to the customer. Of course, good code quality helps you deliver more and better apps to the customer. But the customer does not care that you followed the SOLID principles to the letter as long as the product is right.
2 comments:
Now, now, your subject invites inflammatory responses but I know better since you and I talk about this stuff on the train ad nauseam. It isn't SOLID that gets your goat, it's the preachy, dogmatic way in which some of these messages are delivered. I tend to agree which makes it harder for people like myself that really want to promote the qualities of SOLID.
This whole thing wasn't necessarily about SOLID but rather the topic of "quality doesn't matter" in software development. We have all forsaken the gods of truth and beauty in order to meet project deadlines. The work I did last week I wrote off the cuff and jammed it into the system and used instinct alone to guide the code quality. I hate that. But for these few things we can repent and be forgiven. What is the real injustice is to completely disregard proven software development patterns altogether and call them academic exercises (in reference to the SO podcast).
There is good reason for us to want to strive for writing quality code. Case in point, you and I have both worked on a legacy system that was built as quickly as possible to meet the business needs without so much as giving a thought towards things like SOLID, DRY, YAGNI or any of the bajillions of acronyms that produce evolutionary code. As time marched on the code became more and more brittle. It took longer to build new functionality, it took longer to debug, it took longer to produce releases. All of our time was being devoured with hotfixes.
It finally came to a breaking point. Now, large swaths of code is either being rewritten or removed. That's a lot of what our recent projects are...replacing the previous systems as they're not maintainable and can't be built upon. That's a huge loss for the customer and for the code and too many systems have died an early death this way. At that point, it makes no difference how right the product is. I have a page I'm working on that has 4000 lines of code in a single source file. No one on this planet can fix or build upon that. It's a house of cards.
I like Jeff Atwood, he's a really intelligent guy. However, he admits in the StackOverflow podcast that he's bound to rewrite StackOverflow a few more times and he admits it's lacking in overall code quality. Now, if we all had the luxury of rewriting our systems all the time, then yes, who needs quality? We can just write the same thing again and again. I don't see the point in that from a development or business perspective.
Technical debt has to be paid back eventually. The question is whether or not it will bankrupt you.
The thing about technical debt is that sometimes you have to accrue it.
The business makes a decision that the product has to move forward to take advantage of some situation. In that case, you want to move to market quickly, and in the way, you'll accrue some technical debt. This is the story of Stackoverflow. Jeff and Joel decided they had to get to market quickly, so they raced the development, made some mistakes, but got out the door quickly. In that case, they served the customer well.
Technical debt is just like real debt. You can take some out so you can take advantage of an opportunity, but you'll have to pay it back later. That's my biggest issue, that technical debt isn't anathema, it's a necessary part of development.
Post a Comment