Reading time:

10 minutes

Word count:

2216

I found over decades of software development that the concept of elegance of code is at constant flux with the idea of functionality. Single Page Application paradigm #0

I started writing home computer arcade games at a very young age for educational purposes. I learnt a lot of BBC BASIC and Research Machines 480Z BASIC and microcomputers back in the day. In those heady days, there was no such thing as Agile. If you wrote code you program in such a way that only you understood the code. I quickly learnt the hard way that if didn’t type "SAVE SPACEWAR.BAS" #1 at regular intervials then I could lose the entire day’s progress. At secondary school, I saved my code to a floppy disk (remember them) or a cassette tape. I noticed that if I context switched after a week using an instruction like "LOAD PACMAN.BAS", which loaded the entire code for a different game into the computer, then I really wanted to understand how I coded it. There was no Windows Mouse Pointer interface and no multi-tasking. Although, I did not realise it and unconsciously suspected there was truth to having a clean code, pretty good looking code. In other words, there was a beauty and elegance to intrinsic coding.

Fast forward a few decades until today, with the knowledge I learnt on this lifetime journey, I found many people have different ideas of clean code. What constitutes clean, efficient and concise code? I believe it varies in according to culture, teams and even country #3. If you look at code that is generated by machine to be ingested by another machine, you can see that has a context different to code that is written by and read by a human. It is why we have TABS and SPACES in programming languages. Yet the battle remains, like an impregnable fortress, between elegance versus functionality. If you have ever been involved in an outsourced project where the code has been completely handed over for one year or more, and then you examine closely the software produced between the on site and the off site teams, you might be in for a surprise.

Software estimation

I was recently asked a prospective client about how do I provide software estimates in a project? I said to her that my gut reaction, honestly was to inflate the initial estimate by 100% sometimes. In many cases, if there is a task and you understand the software application, software system very well, then you can make a more accurate guess. I might say half a day, one or two days, provided that there are no interruptions with better precision, if I was comfortable with 50%-75% of the source code.

In modern terms, software estimation is collective team task. There is no straight forward answer, unfortunately. As software writers and other related people, we are just as bad as construction builders: “how long is piece of string?”. Yet we, who work inside so-called Agile teams #2, which are answerable to stakeholders and decision makers, are emboldened to provide an viable answer. We have many techniques now from Fibonnaci to tee-shirt sizes. Yet still we find that software estimation is a vexing questions to people inside and outside of IT.

If your client really wants reusable code, or sustainable software applications, then you ought to pushing to elegant solutions. On the other hand, if your client genuinely only is interested in a quick solution, then I recommend you err on the side of functionality.

I suppose I would also draw the line on the type of client, project and goal. Your client might might produce code that another internal team in your own organisation depends on. If your code is used by countless others, then this focuses your attention to being a library writer, and in my experience you are better provide a viable, sustainable and elegant solution to those users rather than a broken down record player.

Requirements

Sometimes the type of client is such that they do not care how the software is written, but that it works. There is a point where fighting the SOLID principles is a perilous descent in limited returns, especially when your client wants compromises. Think of the situation of nano second trading in financial trading high performance application and the impact of low latency protocols and processing in network communications. The rules of Java coding from Sun Microsystems using the JDK collections have to be abandoned to instead to coding Java program like if you writing in C language. If you are looking for open source comfort of nice slippers, a cigar and a roasting warm fire, then forget it.

Clearly, there are requirements where the forces are either one of TIME-TO-MARKET, FAST, PROTOTYPE, COST and DISPENSABLE or a combination of them. If you find the driver for the business (or decision makers) is TIME-TO-MARKET and COST then you are fairly in the functionality domain. The stakeholder and the client most likely do not care about intrinsic elegance politically, but let me emphasis this is the root of all software evil; here lies the classic bit-rot, staff turnover, recruitment churn and broken applications.

Cutting corners

If you have to the opportunity to discuss with the client the long-term benefits of sustainable applications and provided that they do not just hear you, but they also listen, then you can choose the path of elegance. Of course, in my experience, this varies according to the client, the project, the ability of individual members of the team and also having a great technical leader, who is able to fight your corner, when the pressures mounts.

The primary reason why code is hard to read and maintain is that it written mostly against the dimension of time: often said that time is money. Unfortunately, most of all have a finite time to do a job. The secondary reason is that we do not write testable code all of the time, every time, unless it is explicitly asked for #5.

Sometimes the client’s culture and working practices make it hard to write testable code. There can be projects where the legacy code is so hard and so complex and the unit test, if any, are extremely bad that the current project team do not even use them any more. Perhaps at the inception there was a grand intention to ensure cleanly written production code, but after third and fourth generation of staff turnover, the current codebase is a ball of wax. Yet the current development team have no choice but to implement the next urgent feature request. I believe this is why a mountain of legacy software eats so much time and resources and then there is no desire to improve the quality. It is also makes it hard to recruit really great developers, designer and architects #6.

Zealotry

Building software for applications or for infrastructure is generally a complex. What I have found consistently and incredibly myopic in the industry is the belief there is a golden unicorn measurement ruler. People tend to reach for this ruler like crutch and apply it to every situation. Usually this will work for the majority of cases, however occasionally it might miss the mark, lose an incredible opportunity. This might be acceptable as a matter of fact, if you are deliberately prepared to miss out on engaging with a fabulous designer or outstanding architect, but then you must factor for these near-misses. Insisting on pair-programming for 100% of the development, does not automatically mean that you will suddenly build bug-free software. What happens if there are only three people in the office? Or two regular pair developers find themselves on other sides of the world? The same can be said for Agile development. Zealotry effects both functionality and elegance, so just be aware of how you measure individuals.

I thought this has given you an overview of some of the human qualities in deciding elegance over functionality or vice versa.

+PP+

Photo credits

Creative Commons License (CC) – attributing the source of photographs

Baijg Just a bed https://flic.kr/p/zTDud

Spacify-Furniture Store Lax Platform Bed https://flic.kr/p/apmhjB