iLude

What’s in your wallet?

I’ve refrained from posting on the stir that occurred after Stack Overflow #38. I’m firmly on the side of the apparent “SOLID”-nista’s. The reasons for this is that learning and applying them has made me a better programmer.  I’ve used TDD and SOLID principles on large codebases and found that this has allowed significant changes and evolutions to happen to these libraries and have them rolled out into numerous separate projects with absolutely no issues.  Why? Because there are several hundred tests surrounding each of these projects. And the use of the SOLID principles has allowed me to swap out large sections of code with better implementations and add new functionality with little effort thanks to the reduced dependencies.

So today when I opened my Google Reader I was confronted with Jeff Attwood’s latest post where discusses technical debt and he states:

After six solid months working on the Stack Overflow codebase … We have to stop working on new features for a while and pay down some of our technical debt.

What I hear is that he and his team must stop delivering software and start thinking about code quality.  His reasons for needing to do this are:

…that accumulated technical debt becomes a major disincentive to work on a project. It’s a collection of small but annoying things that you have to deal with every time you sit down to write code. But it’s exactly these small annoyances, this sand grinding away in the gears of your workday, that eventually causes you to stop enjoying the project.

Back in the day I was granted commit rights to the Castle Project which is where I came to know Oren “Ayende” Eini. I’ve never heard him say it but its my belief that he eats, lives and breaths the SOLID principles ( I didn’t say sleeps them, because everyone knows Oren doesn’t sleep! ).  He shares the prize with Hammett for introducing me to TDD and starting me on the long path to SOLID Zen.  Ayende sums up the solution to Jeff’s problem here:

If you have an environment that has friction in it, there is an incentive for the developers to subvert the design in order to produce a quick fix or hack a solution to solve a problem. Creating a zero friction environment will produce a system where there is no incentive to corrupt the design, the easiest thing to do is the right thing to do.

By reducing the friction in the environment, you increase the system maintainability

TDD and SOLID are not “bureaucratic programming”. They are refined wisdom of many master craftsmen to help reduce friction and keep you focused on that pesky “revenue generation” code.