Beautiful Code 1 : 5 Symptoms of Software Rot

I used to wonder why people would refer to software development as an art; to me there was absolutely no correlation between programming and art. However, after hacking at software for years and writing all sorts of software: crappy ( I bet I’ll would hide my face in shame if I see some of my old code), good and ugly, I believe it is an art. Well-written software is actually beautiful and infact some  complex interwoven software systems are classics and should be up there with monuments like the tower of Pisa. The beautiful code series will be mostly focused on software architecture, design practices and common pitfalls; I hope it helps to reduce some of the hassles of development as well as improving the quality of produced code.

Well-written software is actually beautiful and infact some  complex interwoven software systems are classics and should be up there with monuments like the tower of Pisa. The beautiful code series will be mostly focused on software architecture, design practices and common pitfalls; I hope it helps to reduce some of the hassles of development as well as improving the quality of produced code.

Can software rot? Well, not physically but its quality can degrade over time so severely that a complete redesign is the only way out.

1. Rigidity

Rigid software is difficult to change. If your codebase is so rigidly coupled that changing a single class requires you to make changes to other classes in your software; then something is WRONG and this is a classic indicator of software rot.

Redesign your architecture; separate components cleanly and think deeply about your design before you jump into code. Use loosely-coupled modules that can be modified without breaking some parts in the system. This will make development easier for you and make your code easily extensible.

For example, you can move configuration options out of code and into a plain text, XML or JSON file.

2. Monolithic Multi-Function Classes

A car class does not have to drive; wash, repair, refuel and get its tyres all by itself.

Please stop writing humongous monolithic classes that have 170 variables, 400 constants, 978 methods and do 7000 things at once! (Well, this is an exaggeration; but I hope you get what I mean ;)).

An essential part of good design is breaking down software into discrete components that can be integrated to form a working system. You decide how best to create your classes; there are already enough wars in software architecture over whether a class should have only one responsibility or not and I am not ready to start another here.

I have to repeat this; a humongous mess is just not worth it! Refactor your code, pull it apart into separate classes,  redesign, do anything but please don’t bundle it into one single bunch.

3. Needless Complexity

Don’t write software that does more than it is expected to do and obviously not less too. Keep it simple; there is no need to make software more complex than it should be; for example, there is no need to use a relational database system if simple plain text files will do.

4. Repeated Code

Copy pasting code is a TOTAL no no! It is too easy to copy working code into another function; Never do it! It might be a great idea for text processing but doesn’t work in software development. It just leads to hidden bugs,  spaghetti code and rigid software.

Imagine you copy-paste some code block five times and now need to modify that block; you need to make the same modification five times. While this might be easy during production, it is a source of pain during maintenance or extension. A new developer might not know about the four other copies and will wonder why the software breaks after changing one. You bet they won’t have kind thoughts about you.

Simple solution: whenever you feel like copy-pasting; improve your design and refactor your code; somewhere there lies some abstraction you are missing out. I bet you’ll sleep better too if you know no irate developer is out there looking for you.

5. Difficult to Understand

Recently while working on an open-source application I had to extend; I came across some terribly-written code. It had all sorts of cryptic single-letter variables and calculations and I could not figure out what the class was supposed to do or how it worked. #painfulCode

It takes extra effort and time to use meaningful names but it is worth the time and effort and you’ll be glad you did it. Else, I bet you’ll swear you never wrote your code when you come back to it after a few days. :D; and if you can’t figure out your own code; then who will?

Use meaningful variable names, method names and forget about all those hacks that enable you to do a gazillion things in two lines; no one appreciates them in production code (yes, they are great for bragging; please use them in YOUR personal projects ONLY) and it leads to software rot.

Well that is it; I hope to continue the Beautiful code series with more examples; while this is more talk and less code; future editions should insha Allah contain more code and show you how some of these things work.

If you disagree with me; please let me know your views in the comments.