Breaking down the approach to software development.
In software development or any kind of engineering, what is arguably the number one productivity killer with poor designs? It’s bad organisation and no compartmentalisation. What do I mean by compartmentalisation? I am referring to the splitting of development tasks into their key and distinct roles. A situation where everything does everything is exactly what we don’t want. This is hard to maintain, risks lower quality outputs and is not an efficient use of time or resources.
Manufacturing Cars:
Let’s take for example, manufacturing cars. A car is made up of many parts and those parts have very specific jobs. I’m not going to pretend I am an expert in how cars work but I do know that there is an engine that propels the car forward. The chassis holds everything together and the steering wheel controls the direction that the car drives. In a typical production line, an entire car is not all made in one place. This is because it is far more efficient to have specialised stations dedicated to one part of the production process. This means higher quality for customers and higher efficiency which leads to reduced costs for the manufacturers.
Now, what if a car manufacturer wants to supply engines for trains? They already have a station that builds the engines. All they need to do is adapt that one station to produce another type of engine. If there is not enough production to go around, they can copy the design of that station and build another. The rest of the production line can be left alone. What if the car was all made in one go at one station? Suddenly what was an easy task, is now going to be too costly. To make a new type of engine, you would be destroying the entire production process of making a car. It becomes very difficult to introduce any changes.
How does the concept of specialisation apply to software?
In software development, it is too easy to take a problem and linearly write code until the problem is solved. If you wanted to build a holiday booking system, there are two ways you could go about it. The first way is step by step.
- Ask the customer for a destination.
- Check available dates.
- Ask the customer to choose a date.
- Take payment from the customer.
- Commit the date to the system.
- Send out any notifications.
This might seem great and simple at first. What if there is a bug with the system where the wrong date is being added? You are now spending a lot of time trying to track this down in the code. You tend to find that as software ages, more and more work gets done to it. Now we might end up in a situation where the date is changed and used in multiple places. That’s going to be a nightmare to debug.
The good approach is to split the problem down into jobs. Each job will have an input and an output. That’s great for re-usability and for debugging. Let’s now use this approach for the same system.
Running through the same situation where we have a bug when saving the date, we can jump straight to the component responsible for saving the booking. First, we can check the input to the component. If this is incorrect, we know that there is an error before this component. If this is correct but the output is wrong, we know that the error is inside the component. We have now greatly narrowed the problem down. The component can also be easily changed with minimal impact on the processing of other components. This is because they have been completely separated. Imagine the components like boxes filled only with the necessary tools to complete their designated purpose (one box cannot interfere with the contents of another box).
Paying particular attention to the send notifications component, this is extremely generic. If we want to build another booking system but this time it is for hospital appointments, we can copy that component into the new system. Without doing anything to it, it will just plug in. All is needed for it to work, is the same kind of input. In this case, that is a booking confirmation. The best part about this is the more a component is transferred from system to system, the more it has been tested and the less likely it is to cause bugs.
I hope this has clearly demonstrated the importance of planning and organisation to delivering high quality solutions. This mindset has been adopted across multiple industries and helps us keep productivity high and maintain satisfied customers.
