Where it really starts.

Moving to a new place always gets me excited. Whether this move was voluntarily or not, I see it as a new chapter in my life. A chapter where I have the opportunity to make the place more comfortable than the old place. I’m sure you can relate to this for other events that occurred in your life. Starting with a clean slate, a blank canvas if you will, has one major benefit which often outweighs its drawbacks: it’s a new beginning, one that can have a better ending.

Before starting anything new, there will be that moment where you envision the end result. Viewing a place before making the decision to take it, is that very moment. You think about how to arrange the furniture so that the place is either spacious or cosy. Whatever your preference is.

In a technical project, this moment occurs before writing a single line of code. It’s a crucial process to evaluate any kind of situation before making major commitments. Much like an architecture, first we must visualise the composition before executing the plan.
You have to consider where things should go to avoid wasting time and effort. This process entails the use of a checklist, a list of requirements.
Will the desk fit in that corner? Where will the TV sit? By answering these questions, you are mentally ticking the boxes of each requirement. In this case, all the requirements are tight to your inventory.

A project’s inventory includes the programming language, framework and process used. If meeting requirements is impossible at this stage of the game, then you’ll have two options: either reduce the requirements or revisit your inventory.

image

Do you really need a desk? Are you restricted to that framework? Options, options. Nothing is set in stone yet, giving you the luxury of changing your mind without unmanageable consequences. However, certain things cannot be excluded: the fundamental items in your inventory. You need things like light, heating, storage (even if it’s a suitcase). What’s often underestimated in any technical project, is the default behaviour of software. Disobeying default rules will definitely result in major technicalities. How certain are you that these specific manipulations don’t have a negative impact in the performance of your system on other platforms? If it happens so that you don’t have to consider other platforms, then you have another thing coming. Being flexible, robust even, is to consider every possibility. Every risk, regardless of its likelihood to occur.

Visualising something and putting it into action are two entirely different things. This is the reason why people aren’t held responsible for thinking of doing something rather than doing it. Aimlessly moving furniture around will only introduce more work. Thus, equipped with our visual plan, moving the furniture will be easier and less time consuming. The furniture will practically move itself. Not only that, but this visual plan will also helps in prioritising the items to move. For instance, it’s illogical to unpack the clothes if the wardrobe isn’t in the right place. The furniture is what holds everything else in place. So, making sure that this get sorted first is top priority. Giving core functionalities top priority in a project will clarify if the visual plan is realistic. We will still have the opportunity and time to revisit the plan and reanalyse it before we start on the simple functionalities.

“Being flexible, robust even, is to consider every possibility. Every risk, regardless of its likelihood to occur”

What differentiates between thinking and doing is that we can’t take the small details into account when thinking about something. We might make the corner of the room look bigger than it is, only to find that the wardrobe doesn’t fit there! Or we assume that requirements never change, only to find that the code is fragile to said change. This assumption is the first step towards the rise of technical debt. Manufacturing code so it does only what it’s supposed to do will result in the creation of inefficient code: code that is most likely unmanageable.

Understanding the requirements of a project is only the start of avoiding technical debt in a technical project. Accommodating to those requirements without restricting yourself is what makes all the difference. Especially since starting over again isn’t always an option.
Like paying a deposit on a new place, a project requires time to establish a foundation on which the system is built on. And I’m only talking about the time it takes to draw this out on the whiteboard. Rushing this process in order to see results is definitely not the ideal way to go about it either. By focusing on implementing the riskiest functionalities of a system, time is available to change our minds. This means not arranging the clothes in the wardrobe before moving all of the other furniture into place. We may even find that it’s better to get a bigger wardrobe to avoid using space for the chest of drawers. Which in turn frees up space for the desk.

So where does technical debt start? At the very beginning of the project.

Author: Marfat Abdullahi