Built with knowledge
A customer came to us with a project we should take over for maintenance. The project was built with knowledge by experts and we might expect it to be good. We believed in that and took over.
The first mistake
Usually when we are asked to take over an existing project we would certainly do due dilligence first. Such a check is rather important to get a feeling what we are supposed to take over - and eventually would also have an impact on the price tag.
In this case we didn’t do due dilligence for two reasons:
- Pricing was not something to be discussed
- The customer said that it was something good
Maintenance
The project was planned for bugfixing and minor improvements only. As such it was just a side-track and other projects of the same customer got a lot more focus.
After some time it became clear that there was something wrong. Really wrong.
Cognitive complexity
Since the time we took over, different experienced developers have been working on the code base. All of them had the same feeling: “This was all a house of cards”. No matter what they did, something else fell out.
Code Duplications all over, business logic deep in the view code, an external system acting as another persistence store, etc. And all that with 0 (zero!) automated tests.
That was the time when we came across Sonarqube’s metric of “Cognitive Complexity™”.
Sonarqube told us that this project of ~37.000 lines of code had a cognitive complexity of ~5.800. Its most complex class alone had a cognitive complexity of ~1.000 (one thousand!). Compared to other projects this value was huge.
This metric shed some light on the issues we encountered in the last months. Actually, the code base was measurable crap.
Sake for good
Now we had to tell our customer that this thing “built with knowledge” was actually crap that he should let go, no matter the consequences.
To undermine our point, sonarqube offers additional, very visionable metrics - most important of all the fridge labels.
Since we are working on multiple projects with this same customer, we had other projects to compare.
This project had a high value of cognitive complexity and a fridge label of E. If it was a fridge, I explained during a meeting with the customer, you wouldn’t consider to use it at any time - not even for that one single garden party once a year.
Eventually our customer did the one right thing to do in such case. He decided to drop it in favour of a rewrite.
The rewrite
The rewrite should be “built with knowledge” and “feature comparable” - but by rechecking the processes of the original solution and making them actually really fit.
That’s what we have done. A strong team took up work, asked things that haven’t been asked before to build a solid solution from the ground up. The most important rule to follow for the rewrite was to not follow the processes implemented in the original implementation, no matter if they actually worked. We challenged every single function and treated the customer to rethink it together with our analysts to actually build what is needed and what builds value.
In the meantime this solution is almost feature comparable but with a fraction of the original’s cognitive complexity - only 1.250 vs 5.800 (this means a reduction of 78% in cognitive complexity).
That’s what a strong partner and a great team can do - build the right solution and gain value by improving the processes.
