Insights

At DVT we run regular online events that are focused on the latest technology trends within the IT industry and we invite guest speakers to share their knowledge and insights on various topics. The DVT Insights Events aim to enlighten you, educate you and often, provide a new view on a burning issue within the technology space.

Simplicity in software development
Trent Richardson

Simplicity in software development

Friday, 02 August 2019 11:58

We’ve all used something that’s woefully complex.
We know this feels a hundred times worse when we’re on a deadline.


Wouldn’t it just be great if everything were as simple as 1, 2, 3?
Not possible - but we are going to try anyway!


This article serves as a personal reminder of the importance of simplicity in the modern software development workspace.


Simplicity is hard.

“Simplicity is the ultimate sophistication.” ~ Leonardo da Vinci


Software is inherently complex. Many moving parts coupled with an ever changing environment means that your solution is not guaranteed to hold water forever.
Good software, software that tends to stick around for its intended lifetime, is focused, to the point, and most often, simple. In software development, simplicity pays off as systems get large and you have to troubleshoot or understand them.


What does simple mean in this context?
We have something that does a job.
It does this job well.
It is not expected to do any other jobs other than what it was designed for.


There are countless reasons to invest time in creating simple software. However, aside from perhaps very trivial use cases, software does not start out being simple.


It is not expected that you know exactly what your solution will look like before you start coding, or even that your first stab at it will be any good. More often than not, the root of a problem cannot be understood at first glance and takes conscientious refinement to transform your solution into something that users and other developers would want to use.


When it comes to code, a motto that comes up often is: “Make it work, make it right, make it fast” - with simplification being very much a part of the latter two points.


Simplification should not only be desired in the technical aspect of your job. A large part of a typical modern software development team are usually members who actually never look at code. Simplifying your interactions with these members can improve output and traction within a team.


Finally, we will look at how the idea of simplicity can relate to your work-life in general.


So, how do we go about the simplification process?


Simplicity in code.

In software development, simplicity is appreciated in the following forms:


  • Conciseness.
    Eliminate redundancy - though not to the point of losing readability.
    If your code becomes too difficult to refactor effectively, you’ve probably taken it a step too far.
  • A clear thought process.
    Pseudocode does not work for everybody - although at least mapping out your intention beforehand in the form of a comment / summary can allow the next reader of your code to understand why you made the decisions that you did.
    Leave signposts for the next traveler - any decision that does not have an obvious reason should be commented.
  • Easily testable.
    Exposing certain properties and making it easy to package will aid in testing - and by extension make it easier to understand. Unit tests often make the most effective documentation.
  • Human readable.
    Aside from comments, the code itself should be semantic and behave as such. Always look back after writing a method to see if your method name is accurate enough.
    If this means making some parameter names a bit longer in order to make things easier to understand, then do so. The compiler isn’t going to mind.
  • Clear separation from client code and services.
    After extracting the reusable components of your code, implementing business logic should (almost) be as easy as putting the puzzle pieces together in the correct way.
  • Keep things DRY!
    Don’t Repeat Yourself!
    A mantra we’ve all heard before - no explanation needed!
  • YAGNI.
    Hol’ up! - Ya Ain’t Gonna Need It!
    It's tempting to make provision for the future by adding code you anticipate needing in a future sprint. In reality, this is almost never the case and you end up with dead code that will never be executed should it get to production. It's a good idea to make things extendible, but implementation should be left until you need it.
Signs of code complexity.

“Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it.” ~ Alan Perlis


Here are some common signs that your solution might not be as simple as you think:


  • Different components of your application have a hard time talking to one-another.
    There is a lot of code required to transform a message from component A into something that component B understands. Does your code play nice with others?
  • Super objects.
    Your code simply tries to do too many things and the lines of responsibility begin to blur.
    Would you expect to find a TrackGPSCoordinates() function on your Toaster object? Try to define your scope upfront and continually ask yourself: “Does this NEED to be here?”
  • Lick and stick’ solutions.
    Code written just to “get the job done”, with no regard to structure or established patterns. This can often lead to a knock-on effect as more code becomes dependent on this solution, and thus complexity throughout the application is increased tenfold.
  • Missing / bad in-line documentation.
    Inadequate / non-existent comments, making the code difficult to read by developers who must maintain or extend its functionality.
Simplicity in teams.

Aside from tried and tested agile and scrum methodologies, the following are some important aspects of achieving simplicity in teams:


  • Purpose.
    Everyone in the team should have a clear idea of what it is they want to achieve as a whole. Having a good general understanding upfront will often eliminate the need for excessive communication later down the line.
  • Picture the system as a whole.
    This will highlight to individuals what parts of the machine they will be helping to build. Draw pictures! Pen to paper is often the fastest way to shoot out concepts.
  • Be modest - ask for help.
    With the software development discipline being as big as it is (and getting bigger by the day), there will always be others in the team that have more experience than you with certain technologies. Accept it.
    Don’t be afraid to ask for help, but try to keep the time that they’re away from their work to a minimum. Prepare your questions beforehand - help them help you!
Simplicity in work-life.

Keeping your head above water is more than just meeting your sprint deadlines. Probably the most important point in maintaining simplicity in work-life balance is:


  • Planning.
    Your work doesn’t exist in a vacuum - work is constantly affected by life and vice versa. Keeping ahead of the game means planning for both work and life as best you can, and managing the parts where they overlap.

So that’s it - the simplest simplicity crash course I could simply imagine!


I expect this list to look a lot different as I delve deeper into software development, though the underlying message will always stay the same: Keep it simple, stupid!

DVT 25 Years of Service