Ayende has a post that exemplifies principles that I see as extremely important to a good development environment.
Some key points:
- Infrastructure Ignorance – If I have to deal with my infrastructure explicitly, then I need to have developers dealing with it on a regular basis. That doesn’t mesh well with the idea of moving all the complexity to the infrastructure.
- Fizz Buzz concepts – the code that a developer should write should be simple and easy to follow.
- Follow good design principals – the code written should naturally lean toward single responsibility principal, separation of concerns, etc
- Easy to figure out – It should be simpler than the alternative for any non trivial scenario. Ideally, you can explain how to solve most scenarios using this approach in half an hour or less (ignoring the infrastructure part, which may be very complex).
- No training wheels – one of the things that drives me crazy is having two ways to do things. One for the average developer, the second for the architect. This usually comes out of putting training wheels on the first approach that make it hard to deal with in more advance scenarios. I see this as a sign of contempt for the rest of the members of the team. If you expect the rest of the team to work in a certain way, make damn sure that this is a way that this is a way that you can live with.
“The code that a developer should write should be simple and easy to follow”
There is so much about this that needs to be expounded upon. I really think the Single Responsibility Principle(SRP) is vital to this concept. I’ve seen some pretty ugly looking code all over the place where I’m at right now. Very large functions that are procedural in nature. I’d personally rather have many classes than classes stuffed with tons of code. Also, too much code in asp.net code behind pages is a major ‘no-no’. For myself, I’ve had to do much refactoring to get code back into business/presenter classes and out of the code behind. (This is one reason I like the Monorail/MS MVC approach). I could go on and on about this one.
“Easy to figure out”
Whew, amen here. Here is my code smell for this one: When you have no code in the business layer and all it is a pass through. Why do I say this ? Typically this means all the logic is in the UI or in the data layer. This is why I’m a big fan of a domain driven design with clean POCO business objects. Separation of Concerns is important here. I know it’s always debatable in the MS developer world, but when I see datasets I cringe. I think datasets tend to make developers think just in terms of the data layer. They are confusing to see the domain picture. So for me ‘Easy to figure out’ == well defined domain model.
I should add, I think creating a rules engine (IRules) and/or validation objects that can be kept away from the actual entity objects is important. This allows me to see the domain without clutter of all the rules (ie. different sets of business rules for a each client – the entity would hold a collection of ‘IRule’ objects associated to it’s particular instance)
The struggle is working in environments where principles aren’t openly discussed. I think ‘best practices’ should be complemented with developers all speaking a common language of good OO principles. On some teams I really enjoyed working with, stressing these principles made us a successful team, it was a very growing experience to me as a developer.