Think ahead
So we're in the software business or at least software accounts for a sizable part of the business.
What business people or managers want to have from technical guys is the functionality made in time, within the budget and without business
disruption. Sometime's it's so.. mostly not. But it's much more important what you get beyond ordered features and you usually get much more than ordered functionality that works fine at the day of the release.
You get the system that should:
- Work stable. It should not fall down every week at 5 PM or anything like that;
- Be maintainable. It should not cost a fortune to keep the software up and running each day;
- Be scalable. If your business scales, the software should follow or even proceed the growth.
From the practice I know the following cases from the software that was delivered in time and within the budget:
- Glitches that are hard to get rid off and unhappy users are calling constantly;
- Maintenance of the software takes more and more money over time;
- It's harder and harder to get people working with this software.
Or the hardest smash possible: a business dies as the software lags behind for a long time and the profit margin shrunk to the point, it can't accommodate to rewrite the software, neither has time for it.
Challenge for management
The question is - what we as management can do today to decrease the chances of this to happen?
We should make better decisions and get to know earlier if anything wrong can happen soon. The more information we have the better we prepared for observed decision making.
But on the managerial level we're mostly cut off from what happens under the business logic level.
Code quality is the important layer of information that can let you know as a manager or an owner what's under the hood. It's considered to be highly technical, but we're trying to make it accessible for non-technical managers, executives, directors, business owners.
By knowing what's under the hood we've managed to:
- Decrease amount of re-appearing bugs from 20% to 5%.
- Create software that takes 3 times less efforts to maintain and update.
It means that the similar complexity software took 6 developers for support, now it takes 2.
How we started
First of all we decided to work on code quality within a company of 300 professionals (most of them are software developers). We've established the lab for analyzing code quality and extracting meaningful insights from the code that's written within the company. I'm leading this lab and is proud to share what's happened behind it's doors.
We're using code quality metrics on the managerial level to:
- Support observed decision making;
- Standardize quality of software development among different departments and offices of the company;
- Add transparency to development process so developers are able to adjust along the way.
In fact we've written own software to do these jobs.
It was started with well known Sonar Qube (https://www.sonarqube.org/) that is open source and trusted by 50,000 companies around the globe. It’s definitely useful. Though after some time, we've found that it doesn’t provide necessary perspective for non-techies. So we keep using it as a reliable engine with our interface on top of it.
How it helped
Here are 2 stories in which we made decisions based on code quality metrics.
Copy-paste as the signal
A new developer entered the team. He seems to be working acceptable. It took much more time for him to deliver a piece functionality but it was tolerable.
Then a duplicates metric started to show that almost 600 lines of code were duplicated, then 100 lines more.
The software shown us exact dates when it happened. The developer was questioned but the answer didn't seem to explain why he made these decisions. The tech lead stepped in. He reviewed the code and found that the level of coding was way below the team standards and is almost impossible to scale.
As the result a personal development plan (PDP) was created for the developer, he started to receive tasks that were outlined and limited in scope so he's able to handle them.
In three months his code was scrutinized with evidenced improvements.
Who does code refactoring, who doesn’t
It's a team working on our product. Technical debt dynamics were compared for 2 developers of the same skill level.
It appeared that dynamics were different. One developer after accumulation of technical debt dropped it, usually after 2 months from the start of working on any big task. The second developer never had a drop in technical debt accumulated. Never, ever, across several projects that were checked.
It was decided that the code refactoring is required for every developer who works on the project and must happen at least each Friday for 4 hours.
As the result in 3 months we saw amount of functional bugs created on the project decreased by 18% and technical debt decreased by 15%.
The codebase size decreased making it more maintainable by increased readability.
The offer
Code quality expertise that we accumulated and Code Quality for Jira specifically helps me personally and our managers already to quickly observe what’s happening under the hood.
It became possible to make a non-technical manager able to:
- Discuss technical matters, ask right questions;
- Trigger process improvements;
- Get understanding of the development team better;
- Get deeper understanding of what’s happening on the project.
We’re offering:
- Our expertise if you need it;
- Our free Jira add-on to give it a try: https://marketplace.atlassian.com/apps/1218553/code-quality-for-jira?hosting=cloud&tab=overview
Plans (instead of testimonials)
At the moment we:
- Analyzed 2.5bln Lines of Code;
- Processed 172k of code repositories;
- Created and implemented 6 classification models by 2 data science PhD's in our team.
Currently we’re moving on with deepening analysis on the real-world data to get more insights from the code on hand and even automate the advising service with meaningful and actionable suggestions to managers.
Web version will be introduced later this year.
Thank you!
Top comments (0)