Are you thinking of adopting Stepsize for your team to improve your codebase health?
In this case, you are probably wondering what is the difference between Stepsize and code analysis tools, and how to choose the right tools for your team.
Let’s take a look.
Static code analysis or source code analysis tools help dev teams analyse the code to detect defects and vulnerabilities. These tools run an automatic analysis of your legacy code or raise issues during the development process.
Some of these tools include CodeScene, SonarQube, and CodeClimate, and each of them has different functionalities. If you’re looking for an automatic code analysis tool, have a look at this overview.
Stepsize—the user-input based tool—is designed to fill the gaps left unaddressed by automatic code analysis tools.
We believe that the best way to learn about codebase defects is to ask Engineers.
Automatic code quality tools, such as SonarqQube, are great at catching small pieces of debt related to code quality standards.
Automatic git analysis tools, such as CodeScene, are good at spotting indicators of tech debt in git data.
Stepsize is the best for technical issues neither of these tools can catch. For example, how the code relates to the business purpose it's trying to solve, and all tech debt that goes beyond code quality standards and git patterns.
Stepsize empowers Engineers to:
You might be thinking: great, now I know about a huge variety of tools that help with the codebase health and they all seem very helpful—but how to choose the right tools for my team?
Answer these 3 questions to decide whether you need to adopt a new tool:
Teams who are building the pre-market fit products usually focus on shipping new features as fast as possible.
But once you find the market fit, you need to take care of your codebase to have a long-term plan and maximise velocity.
If you’re not sure about adopting a new tool, start tracking technical debt in a spreadsheet. Here’s a free template you can use to start documenting technical issues.
This activity will give you an idea of how much time and effort you need to spend on technical issues and if it makes sense for you to adopt a new tool such as Stepsize to speed up the process.
If you’re the only person working on your project, you probably know most of your codebase and don’t need a special tool to start fixing your debt.
But if you have a team and you often onboard new members, the best thing you can do is to give context to your code.
Stepsize VSCode and JetBrains extensions will help you add relevant comments and collaborate with your team on the maintenance issues.
Small: the type of tech debt that can be addressed as soon as the engineer spots it in the code and it’s within the scope of the ticket they're working on.
💡 Tip: You don’t need any specific tools to fix this debt but rather an engineering culture that supports the idea of boy/girl-scout rule and clean code.
Medium: the type of debt that can be addressed within a sprint. It should go through the same sprint planning process as any feature work and be considered just as rigorously.
💡 Tip: To build a habit of spending 10-20% of your sprint on code maintenance, make technical debt visible and track your progress. Stepsize is the best tool for it because it helps you easily track, prioritise and fix technical issues.
Large: the tech debt that cannot be addressed immediately or even in one sprint.
💡 Tip: if your team is drowning in tech debt, start by bringing up this issue with your PM and other managers. The best engineering teams we’ve spoken to have quarterly technical planning sessions in which all engineering leaders participate.
If your codebase is old and most of the Engineers who contributed to this code are not around, you might need to use both automatic and user input tools to reduce technical debt.
Do you have more questions or advice for your specific situation? We’re always happy to have a chat with you and see how we can help your team fight technical debt.