Writing Maintainable Code

Lately, there has been some heated discussion in the software engineering community about what it means to write maintainable code.  The concept of architecting and designing software so that it is more easily maintained is rooted in the desire to keep support costs down for the customer.

Much of the recent discussion was spurred by a jdn blog about developing a software application that will be maintained by developers who are unfamiliar with current practices.

“One problem (well, it’s really more than one).  I know for a fact that I am going to be handing this application off to other people.  I will not be maintaining it.  I know the people who I will be handing it off to, so I know their skill sets, I know generally how they like to code.

None of them have ever used ORM. None of them do unit testing.  One knows what they are and for whatever reason hates them.  The others just don’t know. None of them have ever used MVP/MVC, and I doubt any but one has even heard of it.”

jdn’s dilemma is this: Should he write the software application using the outdated practices that the maintaining developers would be familiar with, thus reducing short term support costs? Or should he write the software application using current practices to reduce long term and overall support costs? 

The benefit (if you want to call it that) to using outdated practices is that the maintaining developers wouldn’t need to spend extra time learning the new technologies and patterns.  This would reduce the initial support cost to the customer.  However, this view is not looking at the overall picture.  While using the outdated practices would reduce the average amount of time spent on the initial support tasks, it would also likely increase the total number of support tasks needed, making the overall cost to the customer higher.  Plus, once the maintaining developers became proficient in the current practices, the average time per task would go down as well.

The design patterns and practices we use in software engineering today, such as unit testing, ORM, or MVC, have evolved as solutions to problems discovered over time.  Ignoring them invites the reoccurrence of known problems in software engineering.  If I were to give counsel to jdn, I would advise him to develop the software correctly the first time, using current practices. This would not only also instill better development practices in the maintaining personnel, but more importantly reduce the overall cost to the customer.