A few years ago, I came across this post, where a web developer was sharing about how 90% of his time at work was spent on maintaining existing projects and only 10% was spent on actual development. There was also a comment by rtperson on how impressed he was by the maintainability of the code he was working on, which attested to the prowess of the original coder. This brings me to the main point of this post:
Developers should build stuff in view of maintenance.
Hmm…probably this should be applied to property developers as well, seeing the recent problems with the DBSS (Design, Build and Sell Scheme) housing projects in Singapore. Back to software development – many programs count their lifespan in years and even decades, an example being Windows XP, which was released in 2001 and still accounts for more than 10% of the top 7 desktop operating systems in use according to StatCounter statistics. The time spent on software maintenance far outweighs the time spent on developing the software in the first place.
Closer to home, I once wrote a centralised CMS (Content Management System) using Zend Framework 1, to manage content for multiple event websites. That was in 2012 and took me about 4 months to develop. 8 event websites and 3 years later, it is still in use, coming close to the 10-90 rule stated in the title of this post. Of course, there were fixes and improvements made along the way, which fall under the realm of maintenance.
It is not unusual to come across programs, websites, WordPress themes and plugins which work fine on a daily basis in their intended contexts but prove to be a horror when one is asked to delve into the code to modify it, whether it be fixing bugs or adding functionality. It then becomes clear that the original coders were just coding to get the job done and did not think ahead about future maintenance or extensibility. I suppose no programmer can absolve themselves fully of this, including myself, especially when deadlines come knocking on the door.
That said, as software developers, we should strive to design and write our code to be maintainable and extensible, even if we do not think we will be the ones maintaining it. Some of the reasons for the abovementioned horror code could be that the developer thought of it as a one-off fire-and-forget project, or that he/she would still be around, or that someone in the original team would still be around to impart background knowledge. Put yourself in the client’s shoes – would you want a piece of code that no one can fix later (everyone says redo from scratch) or have a case of vendor lock-in (assuming the vendor is still around)? Which of the following scenarios would attest to the prowess of the developer – a complex piece of code which no one else understands or a piece of good, clean code that anyone can understand easily and be able to modify it?
A valuable tool in making code maintainable would be inline documentation, ie. comments in the source code. Not software manuals, Word documents, PDFs or text files which, being bundled separately from the application code, will get lost in the passage of time – you don’t put a Word document manual for the website together with the website code on the web server, do you? No matter where the code is deployed, the comments go with it. Though I never generate documentation from my source code (no need as yet), I try to make it a point to document my code in phpDocumentor style plus add comments on usage whenever possible. This has proved to be an invaluable helpline in refreshing my memory when I had to modify the abovementioned CMS 3 years later.
Another valuable tool would be indentation – imagine having to edit 1000 lines of HTML code generated in Adobe Dreamweaver (which is why I still code my webpages entirely in NotePad++) 😛 It doesn’t matter whether you use 3 or 4 spaces or tabs for indentation – just be consistent.
In conclusion, that brings us back to the title of this post – “10% development, 90% maintenance”. We spend infinitely more time maintaining our code and others’ code, so why not make life easier for everyone? Let us then make it a joyous task to maintain each other’s code 🙂 Adhuc!