Project Management

Refactoring – Standard Process or Stretch Goal or Self-Discipline?

From the PM Canvas Blog
by
This blog is a repository of professional learnings from my 8+ year journey of project and program management. I will share best practices and ideas, and explore project management as a profession in the digital age—and how project and program mangers should upskill themselves to stay ahead of the curve. I would love to hear your comments!

About this Blog

RSS

Recent Posts

Business Analyst to Product Manager

Refactoring – Standard Process or Stretch Goal or Self-Discipline?

Is Artificial Intelligence a Doomsday or Blessing for Project Manager?

Demystifying Myths about Scrum

Scaling Delivery Using Scrum Framework


Categories: agile, delivery, scrum


What is Refactoring? How does it affect the Product?

Refactoring is nothing but modifying the internal structure of the code without altering its external behavior. I’ve seen multiple projects where developers storm with full enthusiasm to develop features as soon as they see what is needed. Moreover, when the team size increases the effects of less maintained code gets compounded as more and more developers starts committing the code changes. As you can imagine, when technical debts loom large, accommodating features becomes extremely challenging. You will start to have unhappy stakeholders as you will not be able to move faster as the technical debt starts pulling you down. If you are not making effort to curtail the technical debts, you would have to pay down doubly in the longer run. I would say, paying down technical debts in one of the easiest ways of improving the quality of the code.

Should it be a Standard Process?

Wouldn’t it be easy to add refactoring as a part of definition of done. This will assist developers to have a checkpoint on how much code has been committed and cleaned up for every iteration. You could also use a metric like number of files checked in vs number of files refactored. Refactoring is always a collective effort mimicking the collective code ownership from eXtreme programming. This way each and every individual gets to know what is happening around each and every feature technically. Refactoring as a process can provide comfort to developers in improving the throughput as the tests gets executed faster without any side effects. Imagine your house is untidy and would it look good in adding decorative items or furniture’s without cleaning it in the first place? Just like how you clean your house to look great, it is also an art of cleaning up your code base habitually to enhance the product outlook technically.

The art of software craftsmanship lies in the practicing the principles and methods tirelessly for longer time. Gaining the knowledge and skill to develop cleaner code alone would not entail success and makes your product (render your service) better but sweating over it would. You’d need to practice it tirelessly over and over (fail of course couple of times) to learn art of refactoring or writing better piece of code. Establishing refactoring as a process, would certainly make all developers follow it meticulously without bypassing it.

Should it be an item on the Product Backlog or Stretch Goal?

On the other hand, as a Scrum Master or Project Manager, you could also negotiate with product owner or stakeholders to underline the importance of cleaning up the code base for better stability. This can be done in several ways and can be left to the team on how to allocate time and effort for refactoring every iteration. Considering an ideal team of 9 members and 2-week iteration length, the team can allocate 5-7% of the team’s capacity or M size story could potentially added every iteration for refactoring effort. But this could also lead to conflicts between the product owner / stakeholders and the development team due to prioritization challenges. Say for e.g. Marketing team would say “I need these features to go in next sprint and is non-negotiable as it would help the company in reorganizing the portfolio to serve customers better”.  

This can be achieved based on mutual agreement between both the parties and the effort should come down slowly as the team matures and learning curve flattens. The team can also think of different approaches to solve the problem either through pair programming, peer code reviews etc. This can help the team weed out some of the technical debts every now and then. All of the activities carried out for the refactoring effort should be factored in the story size accordingly. Alternatively, team can also pick up the refactoring effort as a stretch goal and accomplish within the iteration. This can help avoid the friction between the development team and stakeholders. The team will uncover many things during the iteration and would probably spend extra time and energy to accomplish what has been committed for the iteration. These changes can make the team lose focus on the refactoring and eventually the purpose of cleaning up the code base becomes defeated. The stretch goals make the team feel like crushing the weight instead of a lofty aspiration in these circumstances.

Should it be a Shutsuke (Self-Discipline)?                  

Having explored the above methods, let’s also look at making the refactoring a daily habit to the developers through constant coaching and some development aids. Every team will go through Tuckman model of Forming, Storming, Norming and Performing stages in each and every project. Initially the team may not have the time and energy to focus on cleaning up as they will have a lot to deal with in terms of design thinking, user experience, demos etc. But it is also equally important to seed in the thought of making the refactoring also a habit to each and every development team member. It gives clear advantage to ingrain these thoughts early in the development stages along with other activities. Most of the team will never think about refactoring as a primary responsibility and always give step motherly treatment.

There are also lots of development tools (open source) that can aid developers in reducing the technical debts. It can quickly throw a report on how many static code violations are present categorized by critical, major and minor. The team can address these violations as a part of each iteration to accomplish the goal of cleaner code. Manual code review has become a thing of past and there are tools as well that can help annotate code from any code repositories and provide comments on the modularity, quality, reusability as well. Technical leads can use these tools that can come handy to provide their review comments to the developers. Scrum Master can also provide coaching to the development team and reiterate on the importance of cleaner code for product quality. Like I said earlier, the development team should practice hard on these engineering practices to become better at software craftsmanship.

Conclusion

Refactoring is certainly one of the critical engineering practices that can help pay down technical debts earlier in the game. It is often said that the sum of good design and development effort is equal to poor design, development and operations effort combined. It is imperative that developers understand the impact of refactoring early stages of the project and becomes a habit in their daily routine. As mentioned earlier, refactoring is a collective effort by the team that can be accomplished through the methods suggested above. It is always left to the best interest of the team to see how it can he accomplished depending on the nature of the team and project. But it is always a healthy practice to clean up the code then and there instead of someone helping to formalize the process of tidying up. It is said that your daily routine becomes your habit and eventually your behavior.

Posted on: July 16, 2019 06:38 AM | Permalink

Comments (2)

Please login or join to subscribe to this item

Please Login/Register to leave a comment.

ADVERTISEMENTS

"To you I'm an atheist; to God, I'm the Loyal Opposition."

- Woody Allen