Ever wondered which code is the best code? If there is something called “the best code”, how can software engineers go about writing it? Software engineers want to use their talents and intelligence to come up with clever ways of writing the best code. Some characteristics of the best code are:
- No bugs.
- Highly Performant systems.
- Reduction in memory usage since memory is a precious resource in computing.
- Reduce memory leaks
- Follow best practices to maintain the productivity of the developer.
Some of the characteristics mentioned above are nearly impossible to achieve.
For example, it is always good to be able to write bug free code. Bug free code is specifically more important in mission critical systems and real time and near real time systems. In some other systems such as GUI based systems, the bugs might be related to colour of the screen or placement of buttons and these kinds of bugs can be tolerated in most cases.
The following blog is from my own personal experience about how I learnt to write the best code while working as a software engineer at Imago software: The University of Manchester’s student software company. I got the wonderful opportunity of working in an exciting project – “Agile Coaching Games for Flexible Learners”. The aim of the project was to convert existing coaching games used in the software engineering courses at The University of Manchester, to online versions, for remote learners.
A Software Engineer’s Productivity
A software engineer’s productivity is sometimes measured in terms of lines of code (LOC) produced by the software engineer per day. For most computer languages, a fair idea is available in the industry about the lines of code produced per day. So, LOC per person-day is often considered an acceptable benchmark with which a software engineer’s productivity can be measured.
In effect, a person who produces more lines of code per day is presumed to be more productive than a software engineer who produces fewer lines of code per day no matter what.
There are many problems with this metric of lines of code per day.
The paradox is that a software engineer could write minimal lines of code to achieve the same functionality as compared to another person whose program achieves the same functionality, but with more lines of code. However, the first software engineer is deemed to be less productive in terms of the lines of code produced, which is not the case.
Actually, the best code written is “no code written or minimal number of lines of code to deliver the feature”.
How one can write the best code is to find out how to write minimal amount of code to achieve the goal in a timely and efficient manner. I found this truth, fortunately, in the early stages of my career at Imago software. The story of how I discovered it is below.
The story
The main task at hand for our team was to recreate a lego-like coaching game, for remote learners. I was thinking of creating the game on top of some game engine which might save time, from my perspective, of course, instead of trying to reuse something which already existed. I came up with an idea of using the SDL gaming engine to write the software for implementing the games. My mindset of building on top of a game engine needed a shift from building on top of a game engine to building something on top of an existing platform, which might only need some glue code and not a full-fledged game.
My manager and mentor saved the day by advising me to create software with fewer lines of code and leveraging the existing software rather than writing more lines of code, which would have been the case if we would have used SDL. This helped me see from a new perspective and my mindset shifted then to reusability, rather than creating something new or adapting a game engine to do so.
What about the cost?
My mentor also reiterated the fact that each line of code produced has a cost associated with it, such as salary to the developers, testers and deployment team, along with cost associated with maintaining a server and other systems for such development. In the same manner, deleting a line of code also has a cost associated with it if it is safe to delete the line, but this cost is much more desirable than the cost associated with producing a line of code. Some other costs are related to the third-party software and its versions and the developers who develop on top of the platform need to keep up with the versioning of the third-party software. It is always better to freeze the version which the team will be using for the development and deployment, but it is necessary to keep track of the deprecation of features, to ensure that the present system will not break in the future.
So, what have I learnt?
I learnt a great deal about professional software development, which might not be described in any text book but can only be experienced. The most important aspect of my learning is that reusing and repurposing code is a very good approach in several software development projects. In other words, using something off-the-shelf is usually better than creating something from scratch, in most cases. This is a brilliant way to go forward due to so many reasons and some of them are less code/no code written, time tested software, lesser bugs and more productivity from the team.
PostScript
I interned at Sophos as a part of my year in industry. During my time there, I consistently found myself drawing on the lessons I learnt at Imago Software. In a fast-paced environment where delivering features quickly was the norm, I consciously avoided the temptation to write extensive new code. Instead, I focussed on reusing existing libraries and tools, which saved considerable time and resources. The insights I gained at Imago–particularly the value of writing minimal code and leveraging what’s already available–became the foundation of my approach. This not only made my work more efficient but also allowed me to deliver reliable solutions faster than expected.