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?
Labels: Programming
posted by Bryan at
6:00 AM
5 Comments:
good philosophy. i enjoyed the reading.
thanks
By
Anonymous, At
December 4, 2007 at 4:55 PM
Good breakdown. I myself would be with you on encapsulation, but really Maintainability, and Reusability are equally critical (and I do mean CRITICAL) for me. As an ex-Y2K coder, I dug through millions of lines of the crappiest code I have ever seen and it really forged this feeling in me. Seeing the same crap coded in 13 different places, guaranteeing you would miss one when you modified it. Rather than coding once. IMO Reusability enhances (but does not guarantee) maintainability.
Personally, what I would LOVE to see, is a discussion around the specific in maintenance as it relates to the .Net based languages. Specific topics like comments on code headers, use of regions, constants, points to break out code to separate projects, etc etc. I have found little nothing out there in terms of down to earth, nuts and bolts of maintainability thoughts like that.
By
Anonymous, At
March 19, 2008 at 10:47 AM
I believe flexibility is my main target when programming. Not only will it give the user more control to use the application as they need, in which maintainability is also not as much of an issue.
just my 2 cents.
By
garrison, At
July 28, 2009 at 3:27 PM
Hi I really enjoyed your article, I guess I would fall under somebody who is passionate about programming but still considers themselves a beginner-intermediate level. You mention that you believe those who see Performance as a good program trait as ignorant. Through the use of different programs on different platforms I have created for myself a few rules about programming (nothing ever set in stone but good guidelines to follow) and my first guideline deals with performance.
My belief is that a Programmer should have no right in using up the resources of someone else's computer. Basically a programmer would program what the need to program, but later on verify if they can enhance performance as to not eat up the resources of someone else. I guess personality wise it would be to restrain oneself from imposing their program on a user. I came up with this philosophy from the fact that older computers are unable to run certain programs very well simply because it demands too many resources for a menial if not simple task.
I would like to know if you would place my thoughts into the same category of ignorance, or if this somehow fits somewhere else in you interpretation of Programming Philosophy?
By
Mallow, At
May 20, 2010 at 6:25 PM
Mallow,
I think I agree with everything you said, but I think you miss-understand my intention in the passage about performance in my post. I probably wasn't being clear. I don't mean to say performance isn't important. Performance can be a part of user experience which is the center of everything we do in software development (or should be). But performance at the UX level is something that comes from high level design and from testing. For example, in a typical enterprise application, a good performance decision might be to wrap several server calls in a single message to save on connection chatter, or to make server calls in a background thread and show the data on the screen as it loads allowing the user to use the application before all the data has returned. These things are more architectural decisions than coding philosophy (am I splitting hairs?).
The behavior I was referring to as ignorant is sacrificing maintainability, reusability or flexibility in low level code as a default behavior. There are people who will use static methods for performance, convert String literal concatenation in Java into StringBuffers appends, or write 10 lines of extra code to keep from allocating a List every few seconds. These are real world examples. In our world of virtual machines and runtime optimization, many of these 'performance enhancements' end up being slower in the next VM update. But worse, they put the focus in the wrong place. Every one of the clever optimizations above wastes time for the next developer who needs to make changes to that code. Time that could have been spent making real changes to the code that the user might appreciate (including well considered performance improvements).
Of course there is a place for putting performance first. I come from an enterprise background, so I seldom have to deal with them. Off the top of my head, exceptions might include games, OS drivers, or embedded environments.
By
Bryan, At
May 20, 2010 at 8:01 PM
Post a Comment
Subscribe to Post Comments [Atom]
<< Home