“Retrospective analytics” on existing codebases and corresponding bug repositories have the potential to reveal interesting “correlations” which can be leveraged for effective “predictive analytics”. This article explores this interesting idea.
2. Leveraging Smells for Analytics
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.
LEVERAGING SMELLS FOR ANALYTICS WWW.DESIGNSMELLS.COM
3. 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”.
About
the
Authors:
Ganesh
Samarthyam
(sgganesh@gmail.com)
is
an
Independent
Consultant
and
Corporate
Trainer
based
in
Bangalore.
Tushar
Sharma
(000.tushar@gmail.com)
is
a
Technical
Expert
at
Research
and
Technology
Centre,
Siemens
Technologies
and
Services
Pvt.
Ltd.,
Bangalore.
Girish
Suryanarayana
(girish.suryanarayana@gmail.com)
is
a
Senior
Research
Scientist
at
Research
and
Technology
Centre,
Siemens
Technologies
and
Services
Pvt.
Ltd.,
Bangalore.
LEVERAGING SMELLS FOR ANALYTICS WWW.DESIGNSMELLS.COM