Our customer BKR, is an independent, non-profit foundation committed to responsibly managing data used to assess the financial credibility of consumers. Their purpose is to contribute to the financial health of the people of The Netherlands. They do so by delivering services for financial organizations and governments in order to prevent problems in the areas of debt, credit and fraud. They make sure that people’s choices today, align with their long-term financial well-being tomorrow. In order to do this, BKR and their supporting organizations need to register and store numerous individuals’ credit data. Which means that having quality software is essential to the success and security of their mission.
In a recent sit down with BKR’s IT Change Manager & Head of Testing, Dirkjan van Zoelen, we discussed his role in BKR’s mission, and how BonCode, among other tools, has aided them in keeping their software, and communication channels, thriving. Most of our conversation early on was around leadership, and his approach to cultivating a culture of pride and joy, which hopefully longer-term leads to a growing willingness for experimentation and improvement. I was especially impressed when he shared his definition of a leader as: ‘someone who is concerned with taking actions that best serve the long-term health of an organization’.
At BonCode, our mission is the same, to enable our customers to be the owners of high-quality code that is maintainable, not just today, but well into the future.
We both acknowledged that in the world of software development, prioritizing the “long term” can be a difficult balancing act. Urgency (real or imaginary) can block a holistic approach to ‘the next move’, especially in a sprint setting.
“There will never be a world without deadlines, I know that. But what I can do as a leader is create an environment where pausing and zooming out is an acceptable and celebrated aspect of culture. My priority is that we are setting a strong foundation for the future while achieving quick wins.”
The Benefit of Zooming out
Zooming out and keeping a wide gaze is one of Dirkjan’s pillars in his approach to quality. When I asked him how partnering with BonCode factored into helping achieve this, it was very gratifying to hear his response.
“While the development teams use a tool called SonarQube in their day-to-day work to help get a sense for our code quality, it’s limited in that it only captures a picture of the present moment. This is like taking a picture of grains of sand, versus getting a panorama view of a beach landscape. When all you can see are grains of sand, you can’t see the bigger picture. While there’s a time and place to zoom in, for depth, there can be some important context missing. What BonCode offers us through their source code analysis is a zoomed-out picture, for breadth and overview. It’s important to recognize that a high-quality score on a project doesn’t necessarily mean that it’s maintainable. So, looking at our code from the angle of, ‘how can we ensure that our projects are high quality and maintainable’ is very valuable to us. Being able to see beyond that day-to-day metric and into the long-term health and maintainability of our code is crucial.”
How to Champion Continuous Improvement while Avoiding Gaming the Metrics
At BonCode- the core function of our tooling is to run diagnostics on the state of our customers source code. It can be a pretty challenging task for a leader to introduce and create buy -in around a tool that, in essence, analyzes past work. In order to improve, we know that teams must honestly assess what is working well along with what could be better. The trouble is, the ‘what could be better aspect’ can be unnerving and scary for folks. But great leaders know that reflection is the only way to get better and improve the organization.
Understanding this, I asked Dirkjan how he approached rolling out the BonCode dashboard to the development teams, and he said:
“The most important aspect of incorporating the level of transparency that a tool like BonCode offers, is that it has to be properly integrated. I can say to the teams that bringing in BonCode is not bringing a critical microscope to their work, but the only way to build trust amongst team members is by our showing that versus merely professing it. As a leader it’s my job to make sure that no one is feeling like they are now under scrutiny for past work, or in trouble. Because, if they do feel scrutinized, that’s when you run the risk of folks ‘gaming the metrics’ to get you off their backs. And in this case, all the potential value offered by the tool gets missed. So that’s why it’s imperative to me that my actions foster an intrinsic desire to use the tool amongst the teams, versus feeling it forced upon them.”
Instead of ‘forcing’ a direction or a method, Dirkjan tries to be clear about the real implications that unchecked technical debt can offer down the line. One of which, is developers spending unnecessary amounts of time troubleshooting versus building new things.
“If a car isn’t running well, and you can’t access the different parts of the engine easily, maintenance is going to be difficult and take a while. It’s a bit like owning a Ferrari, thinking and feeling like you’ve got one of the best cars in the world, only to one day ‘have a problem’ and get blindsided by the fact that it costs a fortune to perform basic maintenance tasks. Why? Because of the complex construction of the engine and difficulty accessing certain parts. When it comes to source code maintainability, much like in the car engine example, being able to easily work on parts reduces time spent performing maintenance, potential risks involved in changing parts and ultimately the cost of ownership and operation. So, being able to easily access the ’car’s engine’ is a very important first step. Through BonCode and their dashboard, we are able to see a visual of our applications and how they relate to each other. It’s a bit like a map of the parts. Keeping code well-maintained doesn’t guarantee it’ll run perfectly all the time, but it does help exclude certain things in figuring out why it isn’t….if it isn’t.”
A Bridge between Software Engineers and Upper Management
To round out our time together, I prompted Dirkjan to share what he feels has been the greatest value of adding BonCode to the toolkit. We discussed how it can be difficult for upper management and development teams to truly understand each other and the work that is being done. Before working with BonCode, this connection was searching for a middle ground. Now both parties have a simple, to the point visual representation of the software project portfolio. “The dashboard is something that our management team has loved gaining insight into. It’s made difficult technical conversations much smoother. With a few simple graphs, they’ve been shown the status and size of the projects- and most importantly: developments since the start of BonCode monitoring.”
It’s often said that relationships require sound communication to thrive. The management team is now in a position to ask Dirkjan and the developers meaningful questions, and maintain a level of understanding that was previously lacking. This is perhaps our proudest contribution to our customers, offering a tool that provides clarity and enables constructive discussions between differing parties. Where there were once abstract and intangible metrics, there is now a visual, recognizable, common ground to rely on.
