Maintaining Software: I'm Not Crazy
How do you know if your code is maintainable?
Following up with last week's post about Complexity vs. Simplicity, I focus this week on an aspect of coding that is kind of touchy to developers: Maintainability.
Now, I'm not pointing to any one developer, but I'm sure there are other developers out there who know what I'm talking about in terms of "coding spaghetti." That's just one term. Some of these may be familiar to you:
- "You're code is hard to follow."
- "If I touch one thing, it breaks the system."
- "I don't know where to begin."
- "Where is the documentation?"
If you haven't been in a corporate environment and you just code like a madman, how do you know if you writing good code? You have nothing to compare it to.
If it's just you in a basement or garage writing code and you're saying that your code is maintainable, that's like saying you're not crazy, right? You can't do a self-assessment of yourself. You're crazy, remember? Someone else has to tell you you're crazy.
Same thing with your code. You can't say you have maintainable code. Someone has to evaluate your code and tell you whether it sucks or it was delivered by angels.
Find some peers to evaluate your code (code reviews). If you don't have any peers (sad), how do you know whether you're code is maintainable or not?
Self-assessing your code comes down to these disciplines:
- Efficient Coding Practices
Given a specific piece of code and based on experience of what works and doesn't work, you should be able to visually detect the difference between a fair piece of code and a outstanding piece of code. - Simplicity/Readability
The simpler, the better. You wouldn't want to have a ton of 'Gotos' in your C# code, would you? - Documented Code (wavering on this one)
I would take a solid programming routine without any documentation as opposed to tons of documentation for a crappy implementation. One day a person asked me, "why do you document your code for the next guy?" I replied, "Next guy? I'm doing this for me so I don't forget the technique I applied when I come back to it two months from now." - Unit Tests pass
Any programmer worth his salt will have a number of unit tests prepared to show how the partitions of the application work properly.
Ehhh...Let your computer do it!
The other way to determine your code maintainability is to use a tool to help you gauge it. Jonathan van de Veen, over at Developers 42, discusses how to build maintainable code with Visual Studio's code metrics. You need either the Team Version of the software or FxCop.
One of the factors he mentions in his post is to have less lines of code (LoC). The less lines of code, the simpler it is to maintain. This affects your Maintainability Index (MI). The formula for determining an MI is located here.
Summary
Of course, there are tons of directions to go with this post. All developers have their opinions of what maintainable code is.
My opinion? It is truly a personal evaluation of you and your code style and practices. Here's my summary of how to maintain software:
To maintain software properly, developers need a combination of methodologies, coding practices, and discipline: the methodologies to identify efficient and structured code, coding practices achieved through experience, and the discipline to write it or adjust it the way it was meant to be.
How do you measure your software in terms of maintainability? Post comments below. Let's start up the discussion.
Other Resources
- Advogato: How to write maintainable code
- About.com: How to build maintainable web sites
- Frans Bouma's Blog: Why you can't live without proper solid documentation.
- CodeBetter.com: Create a Maintainable Software Ecosystem
- CodeProject: Four Pillars of Maintainable Software
- Sam Gentile: Writing maintainable code
