Improving development time through simplification

I want to share insights learned from the trenches of software development. In order to do that, I must tell you a short story.

A little over two years ago in November of 2018, I joined Betsson. I had taken a long break from working in Software Development and was excited to once more be productive.

As I picked up my first ticket and proceeded to the implementation, I faced a question — how do I make a change?

It was explained that there are eight repositories — six for packages and two contain an application. The packages are consumed by other packages or applications served to customers.

Applications were primarily used for composition and not implementation. The usual workflow consisted of building the package, linking it to an application and testing it.

I followed the workflow but noticed that building and linking took a while. It was somewhat acceptable since not all changes required building everything from scratch, but some did — namely deleting and adding files occasionally broke the incremental build process and required a full rebuild.

Occasionally linking failed with an obscure error:

TypeError: Cannot read property ‘match’ of undefined

Then there were the breaking changes — someone had merged something that required a change in a dependent repository. The whole department stood still for hours.

I was frustrated and asked my colleagues — why are you putting up with this? They responded with — it is too hard to fix. I started my investigation there, fueled by my ego to solve a difficult problem and the obvious praise that would follow.

The first visible time sink was the build time for packages. When reading the implementation for ng-packagr, the packaging tool that we were using — it became obvious that some steps were duplicated. Fixing that along with some configuration reduced the build times by about 40%. Small package repositories went from 5 minutes to 3 minutes and big ones from 8 to 4 min.

It was a band aid on a deep cut. The other issues haunted me as I informed my colleague that deleting the node_modules and package-lock.json would fix the linking issue. It was my third time that week sharing the same information.

At the same time I was struggling with a different issue, linking a package that was depended on by another package instead of the application. It meant that I had to first build the package, wait 4 minutes, then I had to link the package, wait another 3 minutes, link the consuming package and then wait another minute for the application to build, but the application build was NOT WORKING and needed to be fixed. A different set of packages needed to be linked to work on the fix.

I eventually discovered some relief. Packages did not need to be built before linking. It took some fixes to types and some configuration. It was now possible to link all the packages to the application and work from there, intermediary linking was only required occasionally.

I also built a tool that allowed packages to be linked in a more convenient manner. I finished it after months of development during my spare time — https://github.com/OlaviSau/zelda

The name stems from Betsson’s culture of naming projects based on movies, games and books.

At this moment — I was pretty happy. The setup on average took 5 minutes, down from 30 minutes, but there were still issues with breaking changes and packages seemed to be misused. Only two versions of a packages were useful — the development version and production version, awfully similar to branches in a repository. I was still wondering — why are we using the packages at all? Why not have the code with the application?

There was a good reason — a package can be used in other projects, but that was not the case in reality. The packages were only consumed in the two application repositories, which were fundamentally the same project, desktop & mobile version simply had separate repositories. They were even released together. I investigated how it would look like if we combined the applications and packages into a single repository.

The investigation revealed that a built package is faster to compile for the application. The initial build time would increase from 1 minute to around 3 minutes, but the incremental time would remain similar. The downsides were acceptable, considering the breaking change problems and the cost of managing packages.

It was decided and after working on it for some time — most of our project is in a single repository and working on a task only requires developers to run the application build for 3 minutes.

This journey helped me harden a couple of beliefs.

1. Problems should not be ignored — they might be easier to fix than first perceived.

2. The best solution is not always visible — the lessons from an improvement will lead to the next one.

3. Simplicity — cost should always be considered when implementing something complex. It took effort to introduce the packages and set up the building, linking and the release. It was not worth it in the long run.