We are announcing the release of several new features available now for all users of our platform:
- New metrics: complexity and code length
- Technical Debt cost estimate
- New Technical Debt view
New Metrics 🎉
Starting today, these new metrics are available to all projects. Existing analysis are not being updated: any new analysis being started will included these new metrics. These metrics are being surfaced in the analysis results, the new technical debt management tool and the dashboard.
We updated our engine to generate code complexity and surface too complex code blocks. The complexity measure we use is the well-known cyclomatic complexity, which is considered as a reference in the software engineering community.
Code complexity is now surfaced almost everywhere in the platform:
- Technical debt view: most complex functions and complexity average are shown
- Analysis: any file with an average complexity
- Dashboard: show the evolution of project complexity over time
Code should be easy to understand and maintain. For that reason, unit of code (functions) should show on a screen without scrolling up or down. Long functions are hard to understand for developers, this is why this is important to ensure that your code base has easy to understand, small functions.
The code inspector engine considers that any function with more than 40 lines is too long. Such functions should be considered for a refactor.
Technical Debt Cost Estimate 🤑
Everybody talks about technical debt. The metaphor is easy to understand and very powerful: by taking technical shorcuts, we can deliver faster today but will have to pay back later in terms development efforts. Yet, nobody was putting a dollar value on technical debt number. We are now doing that and associate a dollar value that shows how much it would cost to fix and address all the technical debt of a project.
The formula we use is based on analysis of our analysis or several repositories. We were able to asscociate a dollar value to all the efforts to fix the principal debt of a project. The principal is what needs to be done to avoid payment of further interest: the goal is not to pay back the debt completely but to avoid to have too much debt and avoid paying too much interest.
This principal cost estimates is based on project metrics, effort required to fix each issue as well as the cost of software engineer (our current model assumes that a hourly cost is about 85 USD).
New Technical Debt View 💸
All these new metrics were a good reason to redesign the technical debt view. Truth to be told, this view was one of the less popular among our users and we decided to change it in order to provide meaningful value.
The new view uses all the new metrics (and some older ones) in order to show a list of suggestions to fix and improve your project technical debt. The new view gives a list of files (and/or functions) that need attention because their complexity, number of violations or duplicates is too high.
For each dimension of the technical debt, we show how the project is evaluated against this dimension (good/warning/critical) and what are the files that could be improved. We also added a new page in our documentation that lists all the metrics we use as well as the thresholds used to qualify a project as good or not.
This new view is designed to be very practical. You will get clear, actionable information from it.
What is coming next? 🤔
We have many features coming very soon in the next two or three months. While we do not want to announce all the details right now, we can say with confidence that the next few features will provide the best integration experience with any CI/CD pipeline. We will not say more for now 🤫
We hope you enjoy this new feature. If you have any question of feedback, do not hesitate to contact us!