Maintaining software programs uses a lot of time and money, which most organizations would like to invest in developing new software that brings value to their customers. But how can you reduce software maintenance, and lower technical debt? By throwing your bad software code away!
Throw your bad software code away!
An idea is to say “no” to bad quality software, by throwing old software code away. Just go into your configuration management environment, isolate the software modules that are costing you lots of time and money to maintain, and delete that code.
Ok, I understand that you cannot simply delete and throw away bad code. Your software products will not work anymore, your customers will complain (even more then they do about the current buggy software product), and you run the risk of getting out business quickly. And yes, it’s not easy to find out what is wrong with your software, testing everything is not possible and testing alone is not enough to increase the quality of software.
But let’s think about it: Why do we keep software code that is unmaintainable, keeps us awake at night, that hinders us in developing things our customers really need, and that we should dispose of as soon as possible? Reasons that I often hear are:
- We are afraid to throw something away, we might need later
- We’ve spend so much time and money, we don’t want to lose our investment
- We can always improve it later, lets keep it for now
- We don’t have the time and money to throw it away and develop new code
- We can’t come to a decision to throw it away. It’s easier to non-decide (and to keep bade code) then to decide to throw it away
Refactoring
If you are not ready yet to throw it away, then refactoring may help to reduce your maintenance. You rewrite parts of your software, to make the code more maintainable, to be able to implement new functionality, or both. Agile software development has embraced refactoring as a technique to reduce the technical debt. Refactoring is one of the techniques that improves the quality of your code, which contributes to the quality of the product delivered to customers.
Measuring Code Quality
Sampling the quality of your code with reviews is a way to measure the quality of your code. By reviewing just a part of a software, and measuring the defects that are found (both number of remarks and severity), you can extrapolate the defects to determine what the quality of the code is. For instance, if you find 15 defects in 250 lines of code, and the total module size is about 1500 lines, then you can expect to have around 90 defects in it. Multiply that with cost of finding and solving a defect, and you know how much the maintenance costs will be. Are you willing to pay that much in the future? If not, then it may be much cheaper to review and rewrite code, and prevent defects coming in from your customers with high maintenance costs.
Take the decision!
Most people hate taking decisions, and have worries that they take the wrong decisions. This is in my opinion one of the root causes we have so much horrible software. When you keep on having problems with a piece of software, throw it away. If it really feels as a loss, re-create it and you will have a better version. If it doesn’t feel that you lost something (and your customers also don’t miss something), then there is no problem anyway, so you did the right thing to throw it away. Leave it like that, and invest your time in better things.
I’ve had several occasions in the past where I lost a program, a piece of documentation, a blog text or a presentation by accident. I didn’t feel good when it happened, and of course I tried to get it back. Finally I gave up and rewrote it. The second version has always been better, and took only a small amount of time to create it. Why? Because the thinking to create the first version was most of the work. Creativity was my biggest investment, typing it didn’t take much time. When I lose the code I still have my investment, so my loss is very limited. And when I re-create it, I often get new insights which made it even better.
Since I’m aware of this, I decide much quicker to stop searching, and recreate. Also when I don’t feel happy with something, I just delete it. I’d rather invest my time on making something which is valuable, and use my strengths to support my customers. It makes me feel better, and delivers quicker and visible results that my customers appreciate.
Note: This blog is inspired by a blog by Jerry Weinberg on Disposable Programs. Thanks again Jerry for the gift you have that brings out good things that people have inside them!
Technorati claim ID NV2NZNH7CV85
