An agile enthusiast who seeks excellence in software engineering. This is how Patroklos Papapetrou defines himself. Let's have a techdebt talk with this greek "software gardener" who recently published a very interesting approach on how to identify & remediate resign patterns with code metrics and agile practices, based on the original article written by Michael Duell.
It's now a tradition for our techdebt interview: how do you define technical debt?
Technical Debt is designed to communicate the full liability of un-addressed issues in your code base clearly—what they could potentially cost you, and where they're coming from.
To explain it to my colleagues and the companies I work with I bring a common but simple and easy to understand real-life example: Financially speaking, debt is an obligation of a creditor to the debtor. For instance, when you take a loan from a bank, you're committed to make a monthly payment until you cover all the original amount plus the accrued interest. Usually, the loan is repaid in a fixed period of time. Miss a payment and you'll see the total amount you owe, the debt, increase due to additional interest (and fees,) so you need more money to meet your obligation.
Similar principles apply to technical debt. The difference is that there is no initial obligation. It starts when the first commit takes place and it's increased every time you add some new code to a project. It's like when getting a new credit card. On the first day the balance is zero, but every purchase (commit) is a charge to your card (technical debt) that eventually you'll have to repay.
Forget to pay your technical debt back and you'll see your code becoming harder and harder to maintain and understand.
What are the common symptoms you've already met in real life? Of course, without naming companies you worked for XD
Before some years joined a team that was working on a long-term project. Unfortunately when I became member of the team the technical debt was already at very high numbers and we had some really hard times to reduce it. I'll never forget their reaction - which was definitely a symptom of the high technical debt - every time I asked them to build / add a new feature to the product. "It will take so much time, and we don't know what are the possible side-effects. We'd rather prefer to develop the product from the scratch!" .
Their words might sound exceeding but the truth is that these guys were so discouraged that even the simplest functionality was like a mountain to climb for them.
Could you explain to our readers the concept of resign patterns?
Resign patterns are anti-patterns (bad practices) that are applied by software development teams, especially in projects under pressure and tight deadlines. The original article
that defines these patterns was originally written a decade before by Michael Duell. It's a humorous approach of the real design patterns. If you're familiar with the design patterns you'll notice the analogy between their names their symptoms and of their consequences. Take, for instance, the Adapter pattern, which is used to wrap an existing class or a third-party library with a new interface that can be easily used by the system. One of the resign patterns is named "Adopter" and it's described as the creation of a class to host orphaned methods. If you apply this pattern you'll end up with a huge class containing several methods that have only one thing in common. The Adopter class!
I think that studying the resign patterns is a very convenient and funny way for development teams to understand anti-patterns, identify if they've already applied any of them and eventually eliminate them.
You recently worked on code metrics that highlight these resign patterns. Tell us more about that...
I am a big fan of agile practices, addicted to software quality and I try to use as much as I can the design patterns. When I read the initial resign patterns article I thought that I could combine all these by adding some value to the original post. My purpose was to provide a list of hints for my readers to quickly work on the anti-patterns they've applied.
So for each one, I tried, at first, to find all possible software metrics that decrease when you apply it. I think there's one (the Stake pattern) that there's no obvious related metric because it's more business/manager oriented than technical. Now that you know the affected metrics it's time to see how you can improve them by simply following some agile practices you might have already adopted in your development process. I think that the final result - the combinations of resign pattern/affected metrics/suggested agile practices
- is a very nice reference for quick wins in software quality.
In your opinion, what is the worst practice in code that generates the hardest technical debt to be remediated: code duplication, lack of comment, poor code coverage, high code complexity...?
This isn't an easy to answer question. It depends on many factors (project/software type, project phase, technologies and frameworks used etc.) . However based on my experience I'd vote for code complexity. Spaghetti code is not the father of all evils but it might be the root cause of other factors. A complicated code is most of the time hard to understand. Thus hard to maintain and almost impossible to write unit tests.
Usually, developers don't even think to touch these parts of the system and prefer to leave it to the original creator of the code. Imagine now what happens if the author decides to change job or is allocated to another project. Complex code may hide, also, many duplications. It's a very common (bad) practice, especially followed by young developers, to copy-paste large blocks of (considered) working code that they don't understand (because it's too complicated) and modify just a few lines.
Last but not least, my experience has shown that that most of the critical or blocker violations of the project can be found in its most complex parts. So, to sum up, start by refactoring the complicated code and you'll see that you'll address more factors at the same time.
Software Quality Measurment now tends to become a mainstream discipline. What would be major empediments for a developer to concretlely improve code quality? Tools, methods, management pressure...
Today, continuous inspection is what unit testing was a decade before and continuous integration 5 years ago. More and more teams try to continuously measure, manage and improve the quality of their source code. The truth is that there are plenty of tools (commercial or open source) that can simplify this process and methods like the Mikado method that provide guidelines to eliminate the technical debt. Furthermore, non-technical managers begin to realize that higher level of software quality, increases team productivity, simplifies maintenance tasks, which means higher sales and less time to bring new features to the market. But none of these is enough, not even all of them together.
Developers should clearly understand why improving software is so important. They should be able to distinguish how the various quality factors (violations, coverage, duplications etc.) affect the health of a system, their productivity, the team collaboration and the development process. They should also know how they can improve each factor by applying best practices. And finally they should learn by their mistakes so the next time their code will not reflect again the same quality flaws.
It's not about the numbers that a tool will give you. It's not about the practices that a method will teach you. It's not even about the increased sales your boss might demand. Improving your (and your colleagues') source code means that you respect yourself and your team and will surely make you a better developer.