Recently, I've seen a nice trend out on the blogosphere on going back and revisiting the basics of programming like this post from Scott Hanselman and this podcast from the Herding Code gang.  My contribution to this trend just went out in the October issue of MSDN Magazine.  For the latest issue of the Patterns in Practice column I decided to focus on the very basics of software design:  Cohesion and Coupling. I made an effort to explain the two concepts of coupling in terms of the first causes of desiging code that is readable, simpler to change, and easier to write.  Assuming that I made my case on why cohesion and coupling qualities are important to your daily coding effort, I moved onto some design concepts that can help point the way toward better coupling and cohesion qualities in your code:

• The Tell, Don't Ask Principal from the Pragmatic Programmers
• The Law of Demeter.  I can't say that I coordinated with him, but fellow Austinite Jimmy Bogard conveniently wrote the perfect companion piece for this section entitled:  Entities and the Law of Demeter
• "Once and Only Once" from Extreme Programming.  One of the best things you can do to improve your design is to simply recognize and remove duplication whereever it pops up.
• Information Expert from Craig Larman's GRASP patterns. The GRASP patterns are a great read for OO newbies.

And just for fun, I talked about some "Code Smells" that can help us spot potential coupling and cohesion problems that have crept into our code:

• Inappropriate Intimacy
  

Coming up next

Roy Osherove made a good post yesterday called Goodbye mocks, Farewell stubs about why so many teams and developers struggle with adopting TDD and their inability to grasp the “Testability message.”  He's largely talking about the learning curve hurdles with some of our existing testing tools, but I still think the bigger obstacle to TDD adoption (assuming that people are open minded and willing to begin with) is a general lack of skill with designing Object Oriented systems.  TDD adoption punishes coders that don’t understand the basics of coupling, cohesion, and separation of concerns.  Coincidentally, I'm busy writing my next article for Patterns in Practices on "Testability and Design" to explore the design considerations and patterns for the efficient usage of automated testing (I was going to steer way clear of interaction testing and all the TypeMock/DI/Mock v. Stub. v. Let's just hopelessly muddle the situation by calling lots of very different things a 'Fake' controversies, but decided that it just couldn't be complete without some mention of substituting fake implementations for infrastructure concerns).

The Hereafter...

I've been renewed to continue the Patterns in Practice column throughout next year, so I need to generate some more article ideas.  Anything below sound good to you?  Got any requests?

• Essence, Ceremony, Conventions, and Opinionated Software -- I want to explore ways to increase the Essence v. Ceremony quality of our code with better API's, some FP-like coding, and the way that we're starting to exploit convention over configuration techniques in our designs.  I also want to talk about the impact of programming language advances on our designs
  
• I'd love to do an article on messaging patterns and Distributed Domain Driven Design ala Greg Young, but this is mostly for my own learning benefit
• Designing better API's.  I want to use my experiences with StructureMap to talk about how to create more predictable and usable API's.  This has been on my mind quite a bit lately because of some flat out mistakes I made on the previous version of StructureMap that I'm trying to correct
• I've also proposed Persistence/Infrastructure Ignorance as a possible topic to MSDN.  Obviously, I have to be very careful with this one, but I think it would be valuable to explain the issues and the patterns used to accomplish Infrastructure Ignorance.  I think I would work in the Hexagonal Architecture 
• The Top N (where N == however long the article needs to be) things that makes a codebase hard to work with.  That's not exactly a design-specific article, but I've had the outline for it for 18 mos
• Moving beyond the Layering Metaphor for Software Design -- I don't think about my architecture in layers anymore, do you?
• Data Access patterns.  Repository, Database Mapper, Active Record, etc.  I'm not enthusiastic about this, but sooner or later I'll do it