Much of the software development that I do is the maintenance of existing code (as opposed to writing new applications from scratch). Having done this for a number of years now, I’ve begun to see things that can be done during initial development to make code easier for subsequent developers to maintain years later (or more precisely, I’ve seen all of the things that are done to make code more difficult to maintain). Usually these techniques come down to following the coding techniques described in any good computer science text (careful design, proper encapsulation, following valid naming conventions, adequately commenting code, etc.).
It seems that most developers who write new applications tend not to end up maintaining code, so they tend not to see first hand the consequences of decisions made in the name of expediency. I don’t mean to say that they’re necessarily being sloppy or lazy. The code I’m talking about works fine at deployment–the results of these decisions aren’t bugs. But they can make subsequent maintenance more difficult and error-prone. So for such developers, I offer this ongoing irregular series of examples of why–even though it doesn’t make a difference in the current functioning of your application–you should make the extra effort to follow good design and coding techniques. I’m also hoping to document my experiences as background to inform the design and development discussions I participate in. In those discussion, I often find myself arguing against hacks that seem harmless, but that I suspect will cause problems later. I hope that with enough examples, I’ll be in a better position to make my case clearly and convincingly.
morgannels 