The Essence of Software Craftsmanship

Alan Stevens gave a great talk at the Nashville .NET Users Group last night titled "The Taming of the Code". One of the points he got across what that trying to explain good software engineering principles to new or stagnant developers on your team is really hard. And it's hard for a few reasons:

• The terms can be strange and hard to remember (The Liskov Substitution Principle)
• The principles themselves will seem theoretical to those that don't grok them immediately
• Measuring the value of good engineering is next to impossible, so a bunch of rules without good justifcation probably won't happen

Alan's talk wasn't specific to these points, but seemed to acknowledge the difficulty in the expression and adherence to good engineering principles. The way he thinks you can get around such problems is by distilling them down to their fundamentals:

• Don't repeat yourself (DRY)
• Separation of concerns

I agree 100%. It's tough to argue against DRY, and when followed, eliminates a lot of bad coding practices immediately. While separation of concerns is a little harder to explain, the metaphor Alan used to explain it was seams within your application. A great quote he referenced from Jeremy Miller was something along the lines of "I don't try to figure out how to write code any more, now I try to figure out where to put it". The SOLID Principles have a bunch of rules that help guide you into putting code into the right places, but by just saying that all business rules are enforced behind the seam of the business classes gets the point across easier. I think taking the approach of streamlining and simplifying our communication within the community could go a long ways towards improving the craft overall.

I see a lot of potential in communicating and adhering to the two principles Alan has boiled things down to.