Code Refactoring and Scrum

February 25, 2016

Why code refactoring is important?

"Refactoring is a controlled technique for improving the design of an existing code base." Martin Fowler. So improving design of the existing code leads to some good results.

First of all the danger of introducing new bugs is reduced and this is also very important when it comes to restructuring of the system by adding new features or changing the existing. Code refactoring not benefit customers in the short term. In the long term the results of a well designed code are much more visible especially when the customer wants to extend the system with new functionality. Simply he will get it faster and with less bugs.

 

What happens when you don't do refactoring?

Technical Debt of course. We could say that there are 4 types of technical debt:

  1. Design debt

  2. Code debt

  3. Test debt

  4. Documentation debt

As Tushar Sharma remarks in the book "Refactoring for Software Design Smells: Managing Technical Debt", every type could be analyzed in the following parts.

 

Design debt includes design smells and violation of design rules. Design debt is the most difficult debt to deal with. That's because is not based on any code analysis tool or easy to follow rules. Nevertheless there are many books and best practices to read but the design is always a field of uncertainty. Mostly because the design decisions our countless and they are based on what is requested at the moment.

 

Code debt includes static analysis tool violations and inconsistent coding style. This is something more clear from design technical debt. There are some good tools out there to monitor the code via static analysis. Sonar is one of them and its pretty configurable (regarding the rules) to be a pain in the a@@ or more loose just to give you the feeling that everything is ok even if they are not..

 

Test debt includes lack of tests and inadequate test coverage. Tests not only test things when you make them.. the most important purpose for me is to refactor without fear! The more tests and test coverage you have the more easier it gets to refactor without introducing new bugs. The reason is because test will warn you that something changed, in the case that you accidentally modified it, in the output of a process.

 

Documentation debt includes no documentation for important concerns and outdated documentation. I believe that every system must guide the user from the installation to the use of it but lets face it.. Its very hard sometimes to do that. In that cases documentation should be in place and updated.

 

Iterative refactoring

Can scrum and refactoring live together? I think refactoring has more possibilities to live inside the iterations of scrum rather than other development methodologies. Code, test and documentation technical debts can be monitored at any methodology. But when it comes to the big elephant in the room which is the design technical debt then the scrum iteration is the place that could be dealt with.

One of the reasons that scrums exists is for giving the chance to stakeholders to give feedback and drive the deliverables. So this feedback hits directly to the current design of the system! The team will face it over and over again almost in every sprint. They will have to take decisions of how they will implement the new user stories.

 

If they are not taking the time to refactor little by little in each sprint, it will make their life hard. Soon they will realize how fast this pain comes.

 

Hard choices

The following pictures is from a game created by the Software Engineering Institute

 

 

Imagine that in every crossroad you can pick the fast road and go over the bridge or walk a little bit more and collect tools. The winner is the one who takes more tools. So it is a hard choice to make especially if you don't take into account that you may need a little refactoring in the next Sprint. Remember that on the planning meeting

 

I know we cannot be perfect on refactoring especially in the design part but try not to let a long time to pass before you refactor. Sometimes its not clear until you realize it in the middle of the Sprint. Take the hard path and... refactor it!

 

 

 

Please reload

Featured Posts
Please reload

Nikos Raptis -
Agile Coach, Speaker & Developer

I'm a scrum master, speaker and software developer. I love Agile values and principles and...

Contact me

© 2015 Created by Nikos Raptis

  • Google+ - Black Circle
  • Twitter Black Round