Science and Art in Software Development

Art is best appreciated emotionally. Science logically. The subject matter however can easily overlap. I can stare at the Mona Lisa's enigmatic smile or I can study 16th century clothing styles--all in the same painting.

Software development contains the same split personality. I beleive the best software developers understand when and where to apply both logic and emotionality. It's not unusual for me to be working on a problem and "feel" about it in a certain way long before my logical mind catches up.

Generally, those feelings are right. However--while emotions tend to form more quickly than logic. they also tend to be more extreme. Logic is required for proper balance.

Historically, the general public has seen programmers as all logic and no emotions. I'm not sure that's really true. I think our field is filled with emotional people, they are just emotional about topics that the public doesn't understand. Go .Net, Java Stinks!

(Feel the emotion?)

My Code or Someone Else's Code?

Most software developers if given the choice of maintaining their own code or someone else's code, will choose their own. That's unfortunate. Editing other people's code is one of the best things that can happen to a developer. It's a great way to see what works and what doesn't.

Especially early in a career it's not always obvious what practices are best. Fixing problems in ten year old code is very revealing. My own coding style has become simple, spartan, structured and well documented. I didn't code that way in school or early in my career. I learned it as result of many, many hours of maintenance coding.

Working in someone else's code base is also good for the code. As I noted in my previous post, hacking in new code can be a very destructive process. When editing my own code it's very tempting to hack new features because I know where all the easy attachment points are.

It's not nearly as easy to hack in someone else's code without risking nasty side-effects. That forces a full re-evaluation of the code and often significant restructuring. The result is that the code ends up containing the best of both developers.

Coding is Bad For Your Code

There is nothing as destructive to a computer program as a good day of coding. An afternoon can wipe away a week's supply of simplicity and clarity. Gone are the clearly defined functions with well commented logic. In it's place is mess of IF and WHILE logic addressing all those special cases that didn't come up in the initial design.

We all know we "should" refactor. But the clock is a remorseless taskmaster. It's so easy to just hack in the feature we need and "design it better next time". Of course, there is no next time. Only now. There is no "design once, write once". Only design and re-design. Code by design, or hack without one--there is no middle ground.