Yesterday I visited a software intelligence workshop organized by CQSE at the Technical University of Munich. The event consisted of five very good presentations from different industries. Thus, the afternoon was not only informative, but entertaining as well. I have worked with CQSE and their software quality tool TeamScale a lot in the past. I believe firmly, that investing in software quality pays off in the mid- and long-run. Especially in outsourcing of software development or maintenance, I found it very useful to have some insight on how the project is doing. Therefore, I was eager to know how other customers use the TeamScale tool suite.
Context of Software Intelligence
Nowadays, marketing in IT is pretty big and therefore we see many terms that sound really good, but are usually not completely new and can be interpreted in several ways. Recently, many of them have to be intelligent. Be it artificial intelligence, business intelligence or – as in this case – software intelligence. There is a lot of discussion whether or not the word ‘intelligence’ is justified. In machine learning, I came across a good definition of ‘intelligence’:
“[Intelligence is the ability] to learn from experience E with respect to some task T and some performance measure P, if its performance on T, as measured by P, improves with experience E.”
What is Intelligence in IT?
This definition basically says, that intelligence is the ability to learn from past experience, which in IT is data. Ideally, a lot of data. By learning from this experience (data) individuals (or programs) will perform better every time they perform the same task again. The discussions whether or not it should be called ‘intelligence’ arises from the fact, that many people assume, human intelligence is the only type of intelligence. I believe, that learning from past experience and therefore making different and especially better decisions every time a task is performed is one type of intelligence, too.
What exactly is Software Intelligence?
There is a lot of data around the software development process. Some of it is often used as KPIs or SLAs, such as number of defects, lines of code, method length, number of duplicates, nesting depth and so on. However, this is reactive and does not lead to improvements quickly. The improvement comes when we use the collected data during the entire development process. Thus, based on the data we gathered before (experience E) the team can create software (task T) that will contain less defects (performance P). This is pretty much in sync with the definition above.
Where and How does TeamScale fit in?
TeamScale is basically a tool suite, that integrates in the entire software development process and gives feedback in real-time. It shows the team potential pitfalls whilst creating software. Thus, these can be removed instantly, which is much more efficient. TeamScale also identifies technical debt, which can then be resolved quickly, when working on the same method anyways. TeamScale collects and aggregates the available data and makes it transparent. This is not easy in the beginning and it is important to know, how to interpret the data. Remember:
“Not everything that counts can be counted, and not everything that can be counted counts.”
The team must not feel like they are being controlled. Instead, the benefits of using this tool-based support have to be outlined.
Why do I like TeamScale?
I have used TeamScale heavily in my role as vendor manager. Therefore, my view on TeamScale is limited. To get the full picture, I strongly recommend to have a look at the CQSE website. When outsourcing software development projects or entire maintenance services, I did not want to oversee all the activities that were going on anymore. My understanding of a trust-based partnership is simply different. However, as I was still responsible for the services, I did not want to be completely blind. TeamScale offered me insights into our ongoing projects on different levels. Using the dashboard, I could see the rough overall status of all projects. Whenever I saw some indication for potential issues, I could thrill down and have a look at the details. The level of detail helped me a lot in conversations with vendors.
People leave – Software stays
This reflects the reality in IT and especially when outsourcing IT services. The only consistency is change. Attrition or exchanging vendors is an ongoing challenge. Although the importance of documentation is well-known, I have hardly seen any project with sufficient documentation. Much more often I have heard the following:
“The code is the documentation.”
Insufficient documentation, different skill-sets and several other factors lead to software, that becomes very hard to maintain after some time. At that point, it is extremely important to have or create transparency on the technical debt. When exchanging teams or vendors a clear and transparent baseline on that technical debt is required for future comparisons.
To me, TeamScale offers all of this and much more. This is why, I definitely recommend its usage in my projects.