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.
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.
17 thoughts on “Beautiful Code 1 : 5 Symptoms of Software Rot”
Nice post. Carefully using the appropriate design pattern(s) helps in writing beautiful, loosely-coupled and easily maintainable code. Another thing is not to fall into ‘patternitis’, abuse of design patterns. Even OOP goes a long way in solving some of this problems.
Another one is testing, unit testing especially. I personally like the idea of TDD. You write test cases for each class even before writing code for those classes yet. Initially they all fail but as you start coding the implementation, they pass the tests.
Thanks a lot; yes TDD sounds cool and I like the way it forces you think and make design decisions uphand.
Do you use it a lot?
Not really, I haven’t had time to use it on a project.
Programming, art or science? Both ? Neither? Question irrelevant? Wondered about this myself. For now I tend to think of programming as a subset of computer “Science” expressed through craftsmanship (arts).
I agree with you that it spans both art and science. :)
Can’t be truerer, I just “inherited” a Classic ASP clusterfuck of code and learning to love every bit of beuty…
Oops; sorry about that…
Nice post this is! I run into trouble with my naming conventions so i really understand the important of that… it’s true that programming is both art and science – i compare it with architecture sometimes.. TDD is surely a good practice.. and it also a major part of Agile development..
Nice one again!
Thanks a lot Chillie B!
Am glad you liked it :D
Reblogged this on Chillicon Dot Com and commented:
Nice one. I really appreciate your effort. I gained a lot from this post.
Glad you liked it!
nice post .
Thanks a lot Taha :)