In the pursuit of delivering what clients want while also maximising our efficiency, we often encounter challenges. This article will explore some common reasons behind these challenges and potential solutions to resolve these.
One of the questions we often ask during interviews is “What are the qualities of good code?” The interviewee will usually respond with qualities such as “clean” , “easy to read” and “has good documentation”. These are great examples and are indeed worth mentioning but one key characteristic often overlooked is simple code. What is simple code? Simple code is in essence the minimum amount of input, processing and output that would meet the required output. As developers we like to solve complex problems and most often than not we lose sight of the end goal through overcomplication and obfuscation . Why does this happen so frequently to developers and in the I.T space?
There are a number of reasons why this can happen – one of the reasons derive from developers needing to show their ability to code. Sometimes making things look more complicated shows that they are smarter but, unfortunately, this does the opposite. Does the code work? Potentially but at what cost? Through over complication and potentiality over optimisation the code’s function is obfuscated and harder for the next programmer to use.
Making code simple means making it easy to understand – not just for yourself but for everyone. There is a reason they say mastery is not by knowing about a complex topic but by being able to explain it to a six year old.
With this approach the MVP or actual requirement of the solution can be lost – sending the developer on a “side-quest” to create solutions to the complexity around their initial problem set.
Another reason often seen is a lack of understanding of what the actual requirement is.
Requirements can sometimes be a little more complicated than a simple add two strings together etc. Most of the time in today’s ever evolving world the solutions we are required to create are complex by nature. By not understanding the value of the requirement – we spend time on things that do not meet the “MVP” or value of the solution.
A very simple example would be creating a function that would add to integers together . A very simple function that’s value derives from the addition of the two numbers. This can be lost in translation where the developer creates a function that instead is able to add, subtract, multiply or divide the two integers. Is this incorrect ? No – however it is extra work added on a very simple function. The requirement was for the two integers to be summed and the output to be given. Instead the method now has extra functionality that most likely won’t be used for the solution.
It can be argued that it allows for scalability and future use but isn’t always the case. Delivery in today’s world is everything and more often than not when working on a project businesses can get away with slight issues that can be patched in as long as the main functionality is present and working,
How can one ensure they do no fall into the pitfall of over complication or missing the simplicity of the asked requirement?
First and most importantly would be to understand the requirement. Not just what needs to be done but who needs this to be done and why they need this to be done. Different client’s require different things and an of understanding what gives them value is key.
A advertising client would focus more on UX ( user experience ) and eliciting an feeling and/or action. With little concern for scalability or over optimisation.
On the other hand a FinTech company would rather focus more on the logic and arithmetic functions of the site. Ensuring that all logical outcomes are correct , performed speedily and with the ability to scale.
An example would be to look at a financial site who’s aim is to make math more accessible via their tools.
Looking at these two different clients we can make the assumption that UI/UX would be more valuable to the advertising client and should be the primary focus. This does not take away the need for good logic and performance but does provide a “safety rail” on what is the main focus.
Next up would be looking at the solution. What are the desired outcomes of the solution? Are we trying to get sign-ups for mailing list or showing off a product? In this case the client would like to show off their product. This tells us that the overall goal is to impress the user and elicit feelings so that they will remember the product. This is another tool to narrow down our focus on what is required in order to keep it simple.
We understand what the client wants to achieve and how they would like to achieve it via their product so we can now look at how to we can accomplish this in the most effective way. Breaking down the steps to reach the outcome allows us to keep our focus on the goal and keep things simple. Keeping in mind our previous points – we can take each step and ensure the points are there. “Does this show off the product?” and “Is this good UI/UX?”
This will easily disqualify steps that don’t fit into our guard rail. Working backwards we can now sift out the complexity to find our simplest yet most valuable tasks.
We have mentioned how coding the solution has its own set of problems but if we follow a similar pattern of understanding what is wanted from the task. Asking ourselves the questions of what is most important and honing in on these we can ensure the shortest path will be followed.
As previously mentioned – keeping code simple can be a bit more trickier with the various possibilities to achieve the outcome . Many companies adopt the K.I.S.S ( Keep it simple stupid ) principle . This principle focuses on :
- Keeping variable names simple
- Method names defining the functionality of the method
- Comment writing
- Separation of concerns via smaller more legible methods
- Non-redundant code
- Avoiding global states as much as possible
It might seem dumb to use simple terms , variable names and class names however it allows for easy following and reading. Breaking down the tasks into steps and steps into K.I.S.S applied methods keep us from venturing far into the wildlands of complexity.
Keeping your ego in check and not trying to show your coding prowess but instead fulfilling the steps you have defined will be a big help to keeping it simple and not looking for solutions to future problems that do not presently exist.
Most of the problems with complexity come from a place of not understanding what is required. As we can see it all comes down to breaking things down. Initially we broke down what the client is , what they are trying to achieve and what the required outcome is. This process is then continued downwards down to a solution level and finally even down to a coding level.
One would think being simple would be .. well simple but it is in fact a process – like a sculpturer creating a piece of art. Initially he will break down the stone in front of him piece by piece until finally his work is displayed.
It is a skill that requires practise and can help remove unnecessary work and pain, help give clients what they want on time and also give the next developer an easier way to scale the codebase.
Simplicity can found through complete understanding without having to do extra in case what was asked does not meet the required outcome. Always try to understand what you are asked to do . Do not impose what you think is required and always ask questions so that you can find the what is actually being asked. Whether it be creating a micro-site , a method that adds two integers or a CMS that allows for users to upload photos of their cats.
Without keeping things simple – we lose sight of what is actually asked of us. It can cause major problems with outcomes such as late delivery , a breaking of rapport with clients and even knocking down the confidence we have in our own problem solving skills.
If all else fail’s – just remember to K.I.S.S , realize who the client is and what they are trying to accomplish. Ask stupid questions and write down a simple sentence what you need to do.
