Software analytics has become a buzzword today and holds the promise of increasing the efficiency of software development and processes. A number of people are spending countless hours mining software repositories to garner retrospective and predictive insights that can disrupt the way software projects are managed.
That brings us to the interesting question – can design smells be used for such analytics i.e. can they be exploited to help improve software development and processes?
Let’s first talk about why we would want to do this. In our experience, many managers are not convinced about the importance of refactoring and repaying technical debt. They are only concerned with the product quality as perceived by the customer. This is often quantified in terms of the number of field defects/bugs. As a result, managers often relegate the improvement of design quality to a later release. We can, of course, wait for them to realize their mistake eventually (when the technical debt becomes humongous). But, maybe, there is a better way to convince managers to adopt refactoring early on.
One option is to show that finding design smells and refactoring them actually leads to a “reduction” in the amount of effort and time required to fix bugs or implement new features. As an example, consider the “Insufficient Modularization” smell (see our book) which occurs when a class has not been decomposed enough into more manageable (both size and complexity-wise) classes. As a result, the class becomes difficult to understand – its complexity impacts its understandability. Further, since the class may possibly have a larger number of clients, extending the class may become a nightmare with a ripple effect on all dependent clients – its complexity impacts its extensibility. When the understandability and the extensibility of the class are reduced, we can intuit that it becomes painful to modify the class when a bug fix or a new feature needs to be accommodated. Every project manager who is true to his salt is extremely concerned about the turn-around time for bugs and features. So, this “correlation” should really catch his attention and motivate him to push for refactoring.
The other option (which is more of a question at this point) is – What if we can show that finding design smells and refactoring them has a correlation with the product quality as perceived by the customer? In other words, can finding and addressing smells lead to a reduction in the number of defects that occur in the field? This is an open question at this point and it would be great to find some data points that help reflect on this question.
In summary, such “retrospective analytics” on existing codebases and corresponding bug repositories have the potential to reveal interesting “correlations” which can be leveraged for effective “predictive analytics”.