The acronym for SOLID has been making rounds for some time now.  SOLID is a set of principles that will help you write code that is easier to understand, maintain, and simple. 

Writing SOLID code is not easy and takes effort and craftsmanship.  The road to SOLID is not a direct route and you’ll need practice to get there.

Don’t start with SOLID.

Solve the problem first.  When you are first given requirements have a design discussion to outline responsibilities for classes or interfaces based on the requirements but keep the design loose.  Consider SOLID in that design discussion but don’t spend all your time on it.  Think about the requirement and how you’re going to implement it with code.  Once you start coding the code will paint a picture; it’s too hard to paint the picture first.

Getting to SOLID Requires Iterations.

Not project level iterations.  These are much smaller, could be several per day.  As you make your tests pass you gain a better understanding of the solution and you can begin refactoring code.  The other day, in one 15 minute pair programming session, the project architect and I removed about 25+ lines of code.  Shortly there after I performed some major refactoring.  The codes understandability improved and the tests continued to pass.

Find New Eyes

Sometimes you get stuck in how you’re thinking about a problem.  In my pair programming example above the project architect was able to see things differently and helped me get past a hurdle.  If you’re stuck, find a trusted colleague or just put the code away and do something else for a while.  When you come back with new eyes you might be able to simplify the code.

SOLID is a set of Principles

SOLID is not a solution but a set of principles to help get you there.  Keep them in mind and use them judiciously as you refactor new or old code.