Life on Mars

"So, are we planning to land man on Mars with this any time soon?", I heard my programming professor, Dr Peter Smith, asking a fellow student, Seb . They were arguing about Seb's assignment where his programming style had cost him precious marks. Seb had solved the programming assignment in a single monolithic function with short and obscure variable names despite being taught modular and procedural programming. Peter, who had significant industrial and consulting experience, focused not just on academics but industry best practices as well in his instruction.

"I was expecting more marks", Seb started the argument during the tutorial, "My program passes all the tests in the assignment sheet".

"Yes, but your variable naming is undesirable, for example, you have used i and o for input and output files. No one will be able to make out what these variables are for just by reading the declarations", Peter replied, "And all your functionality is in just one function when the assignment sheet specified a modular solution".

"A fine print indeed", Seb's argumentative nature had quickly gained notoriety during the course, "but you must appreciate it is much shorter than any other solution you would have marked and because it has only one function, it must be way faster. Surely I should get credit for that", completely dismissing Peter's emphases throughout the course on comprehensibility and correctness over conciseness and premature optimisations.

A Few Months Later ...

"Omar I need some serious help", I turned back on hearing this to find Seb, weary-eyed and growing a stubble. It took me a moment to recognise him as he always took good care of his appearance. We were in the last two weeks of the dissertation phase of the programme. Most students were writing up dissertations with their practical work nearly complete.

"I've hardly slept in 3 days", Seb continued, "I had issues in my project code. Through debugging, I found some variables were being unintentionally modified. I tried restructuring the code and now I cannot make out what is happening. Can you please take a look with me".

What is happening here ?

Seb was now learning the hard way the code quality best practices that Peter so painstakingly advocated in his lectures. His entire project code was just incomprehensible text. He had it working well in time and his project advisor was impressed by the outcome but not with the quality of the code. Seb grudgingly promised to restructure and restyle the code after he had completed the functional requirements. However, as the size of the code grew so did its obscurity. It all came to a head when he took the first stab at restructuring. His misplaced self-belief also overtook the prudence of having some sort of a version control strategy. Hence he had no way to roll back to the working version.

This is not the real world, right ?

High level programming languages were developed to make programming more productive by (a) making programming more comprehensible (b) providing the ability to model, in software, high level and real world concepts. However, the risk of obscurity and incomprehensibility with high level programming languages has not reduced but has transformed. Incorrect modelling, incorrect implementation of models and incorrect use or deliberate misuse of language features such as operator overloading can still lead to incomprehensible programs that are much larger in size and complexity.

Because of the huge initial investment in building software systems and their proliferation in most aspects of the modern world, organisations want to be able to maintain and extend them. Understanding software is a prerequisite to its maintenance and extension. Therefore, it is so much more difficult if software or its parts are incomprehensible. Usually developers who write the original software are not the ones who maintain it. Maintenance developers not only need to understand the code but also its domain and the context in which it is written.

Ideally these should be obvious from the code if it is well designed and well written. If not, working lives of maintenance developers may not be much different from the lives of pioneering Mars inhabitants battling an inhospitable environment. Many burn out, not because of radiation exposure but because of the stress of maintaining and supporting systems that are neither maintainable nor supportable. Working with poorly written code over time also has an adverse effect on developers' skills, motivation and knowledge. Many simply forget best practices and adopt the native style of that codebase. Furthermore, organisations and businesses are at risk because of the erosion in understanding of software they depend on.

Looking forward to maintaining this?

But what became of Seb ?

Seb eventually had to redesign his application from scratch, implement it incrementally and keep versions. Needless to say, he gained much of the college education he would use in his career in the last 2 weeks there, i.e., software engineering is so much more than just programming. It has a lot to do with attitude, discipline and empathy than with just technology. In essence, technology is as much about humanity as it is about code and machines. 

He now works as a professional developer evangelizing domain driven design, architectural patterns and coding standards. He has mastered skills and methodologies to apply best practices in maintaining badly designed and implemented systems thereby incrementally improving their structure, maintainability and hygiene. His key message for novice developers he mentors is "Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live".

Fiction based on real events.