My Programming Philosophy

I have read several items which seem intuitive and relavant to computer programming in any language. There is the essay at The Daily WTF entitled “Programming Sucks! Or At Least, It Ought To”, the book by Kent Beck “eXtreme Programming eXplained”, and the book by Greg Hoglund and Gary McGraw “Exploiting Software: How To Break Code”. You may wonder what all of these have in common.

They all say the same thing about programming. Complexity is not desirable in computer programs. The eXtreme Programming mantra is “The simplest thing that could possibly work.” Exploting Software states that complexity is an enemy to secure software.  The article “Programming Sucks!” explains that the boredom of the programmers’ job entices us to try to make our jobs more exiting by adding complexity to challenge us.

My take is that simpler programs run faster, are easier to verify business rules correctness, and are easier to secure. The true measure of a programmer’s skills is his ability to distill complex business requirements into a simple, well-designed, easily maintained piece of code.

I have programmed in Java for over 12 years, but I have never used EJB. I have never had the need to use EJB because all of my programs were either stand-alone programs, 2-tier programs, 3-tier programs, or n-tier programs where the other service providers were written in programming languages other than Java. Now I could have used EJB in order to use the technology in some of my programs, but that would have been a dishonest use of my time. I program to fulfill the needs of my clients, not to fulfill my needs as a programmer.

Having said that I do not wallow in my same way of programming, dragging my feet in the face of new technologies. I am always looking at new ways to program, new technologies, and even the new fads in programming. However, I do not use the new technologies unless there is a compelling business reason to do so.

For example, I used to write my own JDBC connection code. That was until a good, robust, and easy to use library (a Jakarta project) gave me connection pools. I am still a little concerned about the extra dependencies and complexity introduced by using the library. (I mean do they really need to use so many other libraries? Can’t they do the simplest thing that could possibly work?) However, the benefits outweigh the risks, for now.

Edited to Add: Compelling business reasons to use a technology, in my mind, would include: bug fixes (or adding) to the existing/legacy code-base; conforming to policy laid out by management; interfacing with other code in a larger system; and building my code so a team member can work with it and/or take the project over. I would in these instances make the case to management why I think that the code would be better suited to other architecture/technology choices.

Advertisement

~ by Nathan Christiansen on 20 April 2009.