Monkey See, Monkey Do

I went snowboarding today with one of my buddies. He's with a firm that designs/engineers server rooms. He was talking about how well business is going for the firm in part to the fact that software is written so poorly today that companies just keep on throwing more hardware at the problem to keep performance on par. He asked if I thought the development trend would ever resolve itself. No question in my mind, this trend will continue as long as programmers aren't taught the fundamentals programming and fill that lack of knowledge with the wrong solutions.

Rewind to two weeks ago...

I was 'fortunate' enough to attend a week long intro to C# course provided by my employer. The class had about 20 developers of various skill levels which was quickly realized when the instructor started going over inheritance and OO fundamentals.

One of my co-workers who is new to programming was having some difficulty tackling abstraction and interfaces. She said, "We've learned how to do all of this stuff with objects, now we have interfaces and abstract classes? How am I supposed to know when to use them when I'm designing objects?" What a great question! I replied, "Interfaces and abstraction are there to support designing relationships, but never while designing objects."

That can sound confusing, but an example was provided by another guy in class with his 'best' programming practices. He told us that we should write interfaces for all of our Objects, and then provide seperate implementations. This is an example of using interfaces to design objects instead of relationships. Using interfaces to design relationships means: only use them if you have a series of objects that need to interface with another object-- hence the name 'interface'.

Reflect for a second on what you are writing: are you writing an application or a framework? Most of us are writing applications, yet we code them as if we are writing a framework. The old saying, monkey see, monkey do applies here. With open source, programmers are exposed to tons of excellent framework code where they use interfaces and abstraction to allow others to integrate-- this is a requirement of a framework isn't it? Go back to application development. The key with application development is, "Less is more." Don't write extra interfaces unless you absolutely need to and don't abstract objects unless you absolutely need to. You can always refactor later with a few clicks if the need arises.

I'm thinking of putting together a 'best practices' programming guide for my company next week. I might post a link to it here. These are just my ideas on my blog, but we are to a point where frameworks are written for programmers who code as if they are writing frameworks-- enter most IoC containers.

3 Objects - 300 lines of Code

3 Interfaces for those objects - 100 lines of Code

1 Spring XML configuration file - 50 lines of Code

1 Class to Integrate with Spring - 20 lines of Code

1 Year of Application Performance/Maintenance - Slow and Painful

-versus-

3 Objects - 300 lines of Code

1 Year of Application Performance/Maintenance - Fast and Easy