It is a long story, actually. I first started using the tool in 2014 when there was an open source version, and before it became the CodeScene we know today. Since this was in the early start for the tool I had a lot of contact with Adam Tornhill, CTO and founder of CodeScene, discussing the possibilities of adding more features and improving the tool. Since the start I have used CodeScene continuously to match quality assurance and process object absorption rates.
I do not find technical debt to be a problem in and of itself, however technical risk is a real problem. In the context of CodeScene the software helps me to identify technical risks while prioritizing in what order actions are needed to mitigate it. Oftentimes technical debt and technical risks are correlating. For example, we conducted a detailed analysis of our bugs and tried to trace them back to code.What we found was that there was a direct correlation between different code bugs and risks in 2019 and have used this functionality since then with great results.
Hard to say, really. But over a long time the guiding principle of most software projects has been more or less a waterfall model where coding was a linear ordal. In today’s world, however, development tries to be more agile and in the best cases more focused on certain components of the code stack.
On a more general level I think that some programming languages need to change. For example Python. It can too easily produce sloppy software products which should be contrary to the community’s general need. Of course, any language is only as good as the programmers who use it.
A quite tricky question, but as I see it this goes through phases. For the past couple of years, everyone has been talking about cloud and microservices, but in some cases these are hard to accomplish depending on the requirements. It is not always clear why cloud should be better off the bat, but I am pretty sure that the traditional on premise solutions will be more seldom used.
I use CodeScene from many perspectives. Generally speaking the ability to be able to find trends in the code base and take fast action based on the prioritisation is something that really empowers companies who are aware of the importance of keeping high code quality.
CodeScene also allows the users to work in a more focused way in both development and refactoring. Instead of working on a general level with code, developers can work directly with the weaknesses in the specific parts of the code, saving both time and increasing efficiency. A function I see as important is looking at what resources are available and distributing them to where needed in the projects.
Working with CodeScene prioritizing the efforts of the development team is much easier and with predictive refactoring and in pull requests the developers can get instant feedback. In fact, one weakness with CodeScene as a product is that it is so potent and can do so much that it is hard to communicate to people who do not know about it just how useful it can be. But the biggest benefit of all I’d say is that there is a lot of money to save by using CodeScene to decrease excess rework developing code.
First of all, I do not really see that CodeScene has competition right now. Sure, there are many tools that give you static analyzes, but it is not the same thing. Point in time data does not say that much, for it to be relevant you need real time data and CodeScene does just that among other things.
We use for example the prioritization functionality to focus our work the best way possible meaning that we save quite a bit of time and money by decreasing excess rework.