The importance of an efficient coding structure

Whether you are employing someone to program for you or you program yourself, coding management is essential. 

The coding management is basically the way you differentiate and organize the different tasks necessary to the creation of a program (website, software, platform, etc...).

Most people, both programmers and management teams, do not build any structure when it comes to coding. They will just attack each step as it comes without following any protocol. The reason of such strategy is simple: usually, a management team can only evaluate the final result, as the code itself is far too technical to be estimated. From the designer point of view too, it seems easier to treat one problem at a time as it comes. We will see together why this is a mistake and how you could greatly improve your efficiency by implementing a simple protocol.

Why implementing a protocol?

You work for years without a programming protocol and you have always been successful: why changing?

While working in a programming team I found out that most people had no idea about the complexity or the simplicity of the projects we developed. For the rest of the company, the creation of a program is simply a bunch of lines with a design on top. For this reason, the programmer would just follow his own agenda and build things as they come: sometimes the workload would be very low and sometimes extremely heavy. A better structure would save time and increase efficiency.

Let’s take a similar example. You may have a project team in your company. When you create a new project, you start breaking it into various steps bringing to its achievement. At each step, you would check if things have been done properly before jumping to the next step. You would not simply run from one step to another without any planning. The same applies to programming and development in general: a clear planning enables higher efficiency and better quality.

How to define a programming protocol?

The purpose here is not to limit your team creativity or your own. You must find the perfect balance between freedom and restriction. Programming is like design: there is always an infinite number of possible ways to reach your goal and restricting yourself would close some of those paths.

You must offer a structure used as a guideline, a backbone that you and your team can follow to make sure nothing has been forgotten. Based on this structure, you will be able to break your project into tasks and evaluate the time required for each of those tasks independently. Only then, timing the complete project will become possible.

Which protocol to use?

The following protocol is a structure I have developed based on my own experience. It is a pretty simple graph but you can indeed adapt it to your personal situation.

This protocol has been created for webdesign but can perfectly adapt to any type of programming in general.

Details of the protocol:

When detailing this protocol, I will put myself into a programmer’s skin, and I strongly encourage you to do the same to understand the following steps.

Step one: Create basic structure

First of all, create your basic structure.

Don’t start jumping into design, creating folders as they come, adding features when you think about it. Sit down for a minute, think clearly about what resources you will need, which technologies or languages you will use and how to structure all this. Write down all those criteria in a document you will keep for future reference and build your structure accordingly. This means creating your folders structure, eventually your database if you need one, your code structure, etc… All project’s details must be clearly defined at this step, so that later you can simply follow the path you have built.

Step two: implement and test functional code

This step might be divided into several smaller steps but to keep it global and applicable to all situations I chose to keep it as one. The important thing here is to focus on the code itself: don’t start going into design or content.

Even more important, document largely each single step of your code.

If you are part of the management team, this will be the most important step for you. Documenting the code means adding comments and explanation within the code. The purpose is simple: if another programmer takes over the project he should be able to read the code and understand it easily. Also, if the programmer developing the project doesn’t touch the code for a few months and must get back to it, having it well documented will tremendously ease the task. Keep it in mind: whether you develop the program yourself or ask someone to do it, documenting the code is the most crucial aspect.

Another important detail is to keep the code clean and lean: the code should be as simple as possible. A simple code requires less resources use for its user and is easier to read.

To summarize a bit this section: keep your code clean, simple, and well documented and your efficiency will raise.

You may face situations in which the programmer thinks that documenting the code is both troublesome and a waste of time. The day you will have to pass the code over to another programmer or re-use it after a few months, you will see things differently. This is a real investment for the future: a few minutes investment can save hours and hours in the future.

I did not specifically mention it, but you must indeed test your code at this step. Each feature must be tested once built: don’t wait for the house to be entirely built before testing its foundations. Build a feature, document it, simplify it, test it, then run to the next one.

Step three: implement basic design

Many programmers are tempted to start with the design, and I am among them. The design is actually the visible part of the project and it is a real satisfaction to “see” the project come to life.
However, the design should always be kept for the end. Starting with the design is just a waste of time as you will need to retouch it and re-adapt it as you build your code. This technique is as absurd as decorating your house before building it. Focus on the foundations first, then apply your nice design once and for all when the rest is ready to go.

Where is the content?

I did not mention the content in this basic structure simply because the content usually comes in the end and evolves all the time independently from the programming team. An efficient program should enable your content to change from time to time without ever affecting the code.

And the rest of the protocol, what is it made for?

If you ever worked with a design or a programming team, you surely experienced it: nothing is ever finished.

You may have created the best design or the best program ever, the day will come when the result will need to be refreshed.

I have symbolized those changes into a looping protocol as it is exactly what it is: an endless series of changes.

Programmers are easy to solve those updates by adding a small piece of code as you would add a patch on an inflatable boat. Make sure this doesn’t happen with you: as I mentioned earlier, a clean code is the key to success. Start adding pieces of code everywhere upon requests and you won’t be able to use this code anymore, creating conflicts and making it unreadable. The testing phase will take much longer and the time you wanted to save in the first place will be wasted.

Start by cleaning up your code: normally, it should be crystal clear already, but take some time going through again to make sure all is well explained and nothing is left unclear.

Once done, develop your new features or modifications. Once again, don’t forget to document each new line of code you are adding.

Then, test and debug your code. This is also the perfect time to test the security of your code by trying to break through your own defense. You will certainly find that your program isn’t as unbreakable as you may have thought in the first place.

Finally, implement your design and content into the updated structure.

At the next change, your code will be easy to read and to update and you will just have to follow the same structure again.

Using such a protocol will certainly improve your efficiency, reduce waiting time, simplify codes and programs and create a better communication between you and the programming team.

Julien Rio.