PEAT Online Course -
How To Improve Your Personal Performance in Java work Technology

  • Focus
  • Autonomy
  • Proficiency
  • Purpose
  • Covid-19!!!
  • Deep Hidden Meaning
  • FREE updates
Exclusively on

Elegance versus Functionality

24 March 2017 Comments off

10 minutes


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

Hello there reader!
I use these little pop overs dialogs to provide extra information to the article. Please click elsewhere on the view to dismiss it. Thank you.

What kind of bed are you comfortable in tonight? How much time would you spent building a luxury bed from scratch?
Or maybe you are just want to rest your head, sleep fast, and then in the morning travel onto the next important destination. What bed would you create for yourself if you only cared about functionality?

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.



Just what are these funny medicine pill buttons #0? (Click on me)

These are popover dialogs that go with the article and provide additional information to the audience
in my writing. Finger or press your mouse button off the dialog to dismiss these handy notes!



Heady Days
I learn to program my first computers during the mid-1980s, which is the considered
as the golden period of the Home Computer Boom. The microprocessors were generally 8-bit like MOS Technology 6502 and Zilog’s Z80 with 16 bit address address (216 == 65536 bytes == 64K memory). There were 16-bit processors around like the Motorola’s 68000 and Intel’s, then brand new, 386 series, however they were expensive and aimed at commercial business systems.

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.

Efficient Offshore Teams
The main issue is communication, communication, communication. The second issue is motive. The third is genuine enthusiasm (something that recruiters mangle into passion – being or exhibiting passionate behaviours)
The dichotomy I have with off shore teams is we know a out sourced, remotely networked and co-located team can build high quality software like the Linux Kernel system, which is open source. On the other hand, I know personally, how hard it is to build a community around project. So what gives? The time zone difference is good for some, for some it is clearly not.

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.

Agile SCRUM Estimation Tip
However, how do we get a software currency estimate from a bunch of smalls, mediums, and larges? We need to assign a number scale to each of the sizes using something like Fibonacci – 1, 2, 3, 5, 8, 13. So extra-small equals 1, small equals 2, medium equals 3, large equals 5, and so forth. Now, we can actually add up these user stories and get a total number of story points.

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.


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.

Functional Programming
Scala is a door to higher order programming. In fact, this is deliberate practice (or design) of
Martin Odersky, who wanted to create a scalable language this marries object-oriented programming with
functional programming. I will admit this choice is controversial design and it will always be so. On the positive
side, through the door of Scala, other engineers have moved on to discover type classes, monads, endofunctors and designing expressive programs that validate against a rigorous type system.
If that reason is not elegant for you, then I don’t know what is, and I think you are in the wrong game?

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.

Testable Code
Testable code is defined by observability, adaptability and re-usability. If all levels of the production code can be inspected, checked and verified, then you most likely have the basis of a quality metric. Usually people start with Java with unit tests. As a contractor, I certainly do write completely testable code all the time in Java or Scala. It really depends on the client and if they want functionality over elegance then I write principally for that. However, I know myself, that I might eventually go back to it, six months later. I will wonder what I actually did there. Good clean code is appreciated by many, including yourself.

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.

Recently, I made a complete mess of applying for a contract engagement at MMy Job Matcher. I thought they wanted functionality and TIME-TO-MARKET, so I believe their coding challenge was driven by fast time, operational correctness. Especially as they supplied with me with near enough real-world exercise. I had not accounted for elegance in my solution. I devote just 2-3 hours to the exercise thinking I was competing to get solution as quickly as possible. The client’s feedback was all about SOLID principles, not about operational correctness. So I failed to in the tender. Who do think is it is at fault here? Here is my answer to the My Job Matcher XML Importer candidate exercise on Github.


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.


Photo credits

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

Baijg Just a bed

Spacify-Furniture Store Lax Platform Bed

Hey all! Thanks for visiting. I provide fringe benefits to interested readers: checkout consultancy, training or mentorship Please make enquiries by email or
call +44 (0)7397 067 658.

Due to the Off-Payroll Working plan for the UK government, I am enforcing stricter measures on contracts. All potential public sector GOV.UK contracts engagements must be approved by QDOS and/or SJD Accounting. Please enquire for further information.