Tuesday, July 5, 2005

I like to analyze my co-workers' to understand how they think. Understanding my co-workers helps me work better with them, and gives me a little perspective on my own future direction. One of the early indicators of how well I would get along with a co-worker was how much they liked technology. I found myself much more interested in working with others who had the same passion for programming that I've had. After a while I found that not everyone who loves programming is especially good with it. I've found that a lot of it has to do with early programming experiences and what philosophies of programming they consider important.

For example: Which of the three basic principles of object oriented programming do you find more important: polymorphisim, encapsulation or inheritance?

Those who say inheritance value the ability to change an objects behavior. They aren't as interested in this for the sake of masquerading one object as another (or they would have said polymorphisim). Instead they find it important to repeat as little code as possible. People who find inheritance very important have a tendency to inherit from unrelated objects simply to pick up behavior. They tend to believe in deep hierarchies and flexibility in object models, even if it risks complexity.

Those who prefer polymorphisim also love design patterns. Some like polymorphisim because it makes for elegant code. Most like it because - let's face it - polymorphisim is cool. It makes you seem really smart. I don't mean to make fun of these people. Polymorphisim does help you write some very elegant code sometimes. I just don't think it's an especially important tool in writing good software.

I put myself in the category of programmer who believes encapsulation is the more important characteristic. With encapsulation you separate responsibilities cleanly and provide easy to understand code. Someone who looks at well-encapsulated code has much less to understand before being able to make changes. If there is a downside to leaning this direction, I haven't found it yet.

Another question that may explain a lot about your programming personality: What is more important to you in application code: reusability, flexibility, maintainability?

(Side note: I debated about putting Performance in the list above, because I've known many programmers who would place Performance above all three other choices on the list regardless of the purpose of the application. I didn't include it because I believe this is a decision based on ignorance rather than preference or philosophy. I don't consider ignorance to be a personality trait.)

Those who favor reusability fall into one of two camps: Those who subscribe to the DRY principle and don't want logic repeated in multiple places; and those who think the idea is to minimize the number of line of code in a program (as if it makes the code more maintainable to share code between unrelated pieces of logic simply because they look similar when you do a text compare against them). The former group has a very strong argument, and while I don't disagree with the philosophy, I simply don't rate it as high as others. The later group should be shot. Fired, then shot.

Those who think that flexibility is more important than reusability or maintainability are very hard for me to deal with. They believe that if they can write the code, then anyone with an education should be able to read it. Therefore, maintainability is not an issue and they should instead dedicate their time to making the code do more. These people usually don't have the social skills to deal with the domain experts, and write flexible code to substitute for communication. Since agile methodologies have become more popular, this programmer has had less and less ground to stand on.

Personally, I find maintainability to be the most important thing to keep in mind while writing code. Code is in maintenance far longer than in development. There are also far more remedial programmers than advanced programmers. Much more cost goes into maintaining code than developing it, and the ultimate goal of any commercial software is to make or save money. I find maintainability to be more important than reusability because maintainability is the driving purpose behind reusability. Why DRY? So you can make the change in a single spot. So you can read the code easier. Why is encapsulation so important? To make it easier to maintain the code. I find maintainability to be at the root of all good software decisions, and I think it is ignored way too often.

So what do you value, and why?