This list actually came from another blog, but I did not see where I could leave a comment so I thought I would jot my thoughts down here. The blog implies that these are essentially in order of importance with the first being “Does it work.”

• Does it work?
• Is it easy to understand?
• Is it efficient?
• Short functions
• Good naming
• Clear division of responsibility
• High cohesion
• Low coupling
• Appropriate use of OO and other techniques
• Minimal code

However, I thought I would point out a simple observation. Short functions, good naming, clear division of responsibility, and appropriate use of OO are all efforts to make something easier to understand. I really don't like efficient code I can't understand. And finally, efforts to write minimal code often result in code that is not easy to understand. So, I might reorganize this list like so…

• Does it work as requested? (Adding “as requested.")
• Is it easy to understand?
  • Has clear division of responsibility
    • Leads to High Cohesion
  • (adding) Has useful exception handling. Good exception handling makes bugs easy to understand.
  • Appropriate use of OO and other techniques
  • Good Naming
  • Short Functions
• Is it easy to extend and maintain?
  • Easier if it is easy to understand in the first place
  • Low Coupling
• Is it efficient?
  • Yes, how few wasted cycles there are is last on my list
  • And 'Minimal Code' did not make the list

Software developers, especially those working with Microsoft tools, are often lumped into 3 different groups: Elvis, Einstein, and Mort. I have talked briefly about them before, and you can always just Google the three names to read plenty more if you like.  However, I thought I would take my own stab at dividing up developers based on my own experiences with various types. I also offer clues as to how one might spot these developers in our midst simply because I like to be helpful and I’m a smart-aleck.

The Methodology Bigot

Though I might be called an Object-Oriented bigot, I promise you the OO bigots would strongly disagree. These developers latch onto a methodology like OO, DDD, SOA, [insert your own acronym here] every few years and blindly follow it like Branch Davidians. The concept of why they do things is lost in the how and must so much so that you can’t question their ideals because then they must think, and that wastes too much time. You can spot methodology bigots because they often have a blog dedicated to their current favorite methodology, or they might have a prescription for fluvoxamine and they just might be trying to open their computer case with a blunt instrument.

Open Source Developers

Developers who work on open source projects in their spare time are in a class all by themselves. Aside from having a full time job developing software for the man, they also find time to write software for everyone on the side and give it away for free. I don’t want to work with these people and I am sure I won’t like them, and they won’t like me. They won’t like me because I have a life after 5 PM, I coach pee-wee soccer and grade school basketball on multiple nights per week, I love my wife more than my computer and spend most my free hours with her instead of Ruby and her sexy Rails, and finally I only give my time away to the highest bidder and certainly not for free. You can spot these developers because they might still live in their parent’s basement, are divorced or have a cheating spouse, subscribe to the Socialist Review, and they just might wear Birkenstocks with socks.

The Banana Republic Developer

This developer does everything but build solid code. The code is often cool and uses the latest gadgets but falls apart under any weight. In fact, if you are a size 8 you can’t even open the code in your IDE. This developer uses every open source gadget there is for “helping” their development effort. Their IDE nearly crumbles under the weight of all the add-ins that have been installed. If Microsoft releases a technology even as useless as Microsoft Bob, this developer can take advantage of it because he will instantly make sure he knows enough to be dangerous, and I can’t stress the word dangerous enough. Have no fear, you can spot these developers easily too. They often have Swiss army knives and the latest super cool cell phone attached to their hip. Surprisingly enough, they are not very snappy dressers.

The Mad Scientist

The mad scientist is enthralled with the inner workings of the computer and would prefer to write assembly because C is too abstract. Her code is correct but was clearly written so only the computer has a clue about what it is doing. She puts value in writing the fewest lines of code possible for any single task and is constantly concerned with performance at every turn.  The mad scientist can be spotted by her poor handwriting, class ring on her finger, college diploma on her office wall, and her disheveled hair.  You might also note that she doesn’t like magic shows.

The Assembly Line Developer

The assembly line developer just goes with the flow and does what everyone else is doing, and does it as long as they can, possibly their whole career. They don’t advance much in their career but they will surely complain about it and blame someone or something else for their stagnant job. The assembly line developer gets their design techniques from MSDN articles meant for Janice in accounting who wants a report from Access. These developers might often ask how, but never ask why. You can spot the assembly line developer by their parking space at a large company where they gladly toil away in obscurity.  This developer probably drives a Camry. The assembly line developer is about 5’10 if male and about 5’5 if female. They always wear kaki pants and a light blue shirt when asked to dress nice, and they vacation in the same place every year.

I realize all these have pretty negative connotations. This begs the question, what kind of developer does not have negative connotations? Well, all of you my dear readers of course. We are the best kind, right? We who are a blend of all of these. Sometimes we might be mad scientists who obsess over something that with hindsight turned out to be not so important. Some days we might realize we have been doing something without really questioning why like an assembly line developer.  I’m sure you have been caught up in the propaganda and fanfare of some new silver bullet before eventually coming to your senses.  Though just as there are many of us who are a cool blend of these types of developers, there are very many who match these descriptions dead-on or are very very close.

10 New Year's resolutions in no particular order...

• Write more tests
• Cleanup random development notes and get them documented on blog or deleted
• Do not get caught up in debates when any of the 3 U’s of design debates are present
• Don’t get lead into database design instead of object design when working with other developers on design issues
• Write more tests
• Just like comments, software documentation needs to be more about intent and less about implementation
• Read a project management book and a SQL Server book (always skipping these on my list)
• Write more tests
• Complete more small tasks along with big tasks as you never seem to get to some small tasks that have been hanging around forever
• Ask someone to critique something I have done once a month (at a bare minimum)