Kiss My App

Sunday, February 20, 2005

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


3 Objects - 300 lines of Code

1 Year of Application Performance/Maintenance - Fast and Easy


  • I think you hit this one on the head. Programmers have these new hammers (Spring Framework, AOP, etc) and everything looks like a nail.

    I think much of this comes from using the wrong tools for the wrong job. Any tool use in the proper situation can be a great asset, however using the wrong tool for the job is always wrong.

    I do however think all of this is important to designing software. If you are unaware of other perspectives you will never grow or improve how you develop software.

    Knowing when and how to use these tools however can be a painful lesson to many. Actually the pain is usually inflicted on the poor soul responsible for fixing the mess the previous person made.

    By Anonymous Sal DiStefano, at 2:39 PM  

  • So good to see some critical notes on the whole IOC hype!

    As a matter of fact, within my componany I am kind-of guilty of introducing an IOC framework three years ago (home bred, pre-spring). After having experience with it in several large projects, I really came to dislike its use. Not only is it more work the end of the day to both maintain java code and the xml needed to keep the java code going, but - and this is my main dislike - it doesn't actually help your programmers (learn how to) write good OO code. When you work in a company that has a large influx of junior programmers (like I do) this *is* important, and my experience is that by using IOC frameworks and depending on too many hammers in general, lots of juniors tend to look at their applications as a set of functional modules and their dependencies instead of really trying to think about what objects can be distilled from the problem domain.

    I haven't used any IOC framework last year at all, though I've used IOC concepts a lot in my application design. The pattern is great for some problems, but I haven't had the need for a framework so far.


    By Anonymous Eelco Hillenius, at 1:48 PM  

Post a Comment

<< Home