The Developer Know - All Paradox Solution

Introduction

Today we will look at a design and development issue that seems to impact all applications done in any paradigm. That turnover in the IT sector is very high; teams are constantly changing, and members are moved around between teams and applications. This can lead to some very common problems. Let us take a look at some of these issues and learn how these can be solved. 

The Problem

With the dynamic nature of the IT sector, things move very quickly. People move around to explore new challenges, and technology is also very rapidly on the move. The same happens in the application design and development space. Architects and developers who had originally designed and developed a solution are not usually around to work on enhancements and fixes. Also, newer technology trends come up that require that changes be made to the overall application. As a result, what happens is that new design and development resources are assigned to the project. Due to the very agile nature of development these days, not enough time or documentation is available for these new resources to fully understand the overall and detailed design and architecture of an existing solution. As a result, much redundant work is done, and similar code libraries are written over and over again. I have come across codebases where up to 30% of the code is redundant, and there are so many functions doing the same thing. These have been written over time by developers who just did not have the time to explore what currently existed, due to the quick turnaround that occurs these days.

Initially, we do not see much of an issue with this. But over time, our codebase will become polluted with unnecessary code, and the same things will be done in different ways. As time passes, different developers might use different classes to perform the same functionality, making it almost impossible to standardize things. I have seen that after a few years it becomes very difficult to even understand where certain things are located; thus, making future enhancements becomes more and more difficult.

The possible solution

So, what is the solution? Some would argue that a large amount of time cannot be given to a new design and development team simply in order to understand the existing codebase and identify issues and correct them. That is true, as at the end of the day business requirements need to be met, and even that must be done in a time sensitive manner. Based on my observations and more than three decades of experience, I have put together a proposal for solving this issue. It is detailed below:

I call it the developer know-all paradox solution, and it is very simple to understand and implement.

It is just not practical to maintain large documentation. Even if we do start working on it, through the years of my experience I have seen that it is almost never maintained and updated. After a while, this documentation becomes totally out-of-date and therefore useless for any future reference. Hence, what is needed is a simple method of expressing the design and development details of an application. I have divided this simple expression into three diagrams only. These represent:

1. The application business flow
2. The application technical layout
3. The deployment layout

Simply putting together these three diagrams and maintaining them will make it incredibly easy for future teams to understand the application and enhance it in an efficient way. Let us look at what each of these diagrams contains.

The application business flow

This diagram simply shows the business flow of the application. Note that there is no technical jargon in this diagram. Rather, it contains the different business components and how they interact with each other. Below I've provided a very simple example of a point-of-sale application.

The application technical layout

This diagram consists of technical details for the architect and developer. At a high level we list the projects, the scope of the projects, and what the projects contain. This gives developers a quick understanding of where to look for what.

The deployment layout

This diagram is mostly ignored or not shared with developers. However, it is also an essential part of any application. This diagram is essential for all team members, so that they can understand how the application is deployed. It will aid them in working to design and develop new features according to the environment, and fully utilize all available components.

Summary

In this article, we looked at the developer know-all paradox, where we assume a new developer to an application will understand all aspects and also deliver the optimal solution within an agile sprint. Not doing so can lead to many issues over the years, as I have explained above. We then saw a possible solution, which requires minimal time to create and maintain, and also very little time for the developers to see and understand. In this way, we have a solution that is easy to not just write but also maintain, that saves us from endless hours of application code clean-up and refactoring in the future. Happy coding!