Shifting gears // The need for speed!
Blog Series Index:
The current application we are developing has been around for a long time, more than 10 years. Over time, it has grown into quite a big system, as most long-running systems do. Last time I checked, we had over 400 tables in our DB and around 1.8 million lines of code. It has some parts with quite complex logic as well.
“Did someone in the back yell monolith :)”
The application is for the automotive industry, focusing on business processes in the areas of:
- production – how a vehicle is built,
- logistics – how parts travel from their source to the production line and onto the vehicle,
- part sourcing (MRP) – how we order new parts so we always have stock to build vehicles.
We are a small team of 6 developers, including myself, looking after this relatively large system, making sure it keeps running smoothly for our existing customers and also on-boarding new customers (which brings new requirements).
Because the business processes keep evolving, our team has an ever-changing demand for keeping up with the changes in processes and integrating with other production, logistics, and finance systems making things easier for our customers and also saving costs.
In the last year or so, we have repeatedly heard things from our customers and management centered around:
Why does it take so long to implement feature X?
Because our team has observed a trend here, we decided to look into our development practices and development lifecycle to see what we can do to speed up actual development.
In this blog series, I will uncover the process we went through of figuring out what we can improve and also how we implemented these improvements to help speed up our day-to-day development.
Focusing on day-to-day development
When you start researching this topic, a lot of people talk about continuous-integration/delivery (CI/CD) but our deployments are relatively simple at this stage so there is not a lot of gain for us here YET.
As our first step, we explicitly wanted to focus on day-to-day development activities because this is where we spend most of our time.
The type of gain we were looking for was halving the time it would normally take us to build a feature.
Optimizing the actual day-to-day development would give us the most benefit, paving the way for optimizations in other parts of the development lifecycle.