How do you get your team to participate in quality assurance practices: Refactoring

Question

In XP Programming, code refactoring is at the core - it provides outstanding benefits. However, most developers seem to fear refactoring. As the project manager of your team, you not only need to meet deadlines, but also need to provide good quality source code to client. Also, as a leader, you need to think about ways for your team to improve themselves.

I believe Refactoring of code frequently is a good practice that developers should have. The problem is, some developers being too familiar with old way of working, are resistant to refactoring.

How can you ask your team to actually do code refactoring? What did you do? (if you have past experience)

Answer 1

It's good to care about the quality of your work, and refactoring (if well done) is a good way to provide quality but... let's face some inconvenient truths:

1. Continuous refactoring is a learning process, simply deciding to do it it's not enough and if you're at the beginning you immediately realize it's going to take time before you get used to it (and you'll make several mistakes along the way)
2. Refactoring (often times) does not bring any immediately visible value to stakeholders. "You know boss, I've spent the last half day trimming down that class and splitting its responsibilities to 3 different components", "That's super cool, I'll give you a raise!", said no boss ever.
3. Some developers fear their code will break if they change something, or worse they'll break other people's code, and will maybe have go through a lengthy and very painful process.

I guess you need to address those concerns first if you want to have your people on board. The way I usually do that is (in no particular order, and with a very opinionated pick-and-choose approach, depending on the context):

1. Start specific: identify something that could be improved. It will probably have to be small and "simple" enough at the beginning. Sit together with one of your guys, don't ask to refactor but go through the process with him/her. Spend time discussing why option A is better than B, listen to their concerns. Do this as much as possible, especially at the beginning
2. Little refactoring is better than no refactoring. Reassure people about the fact that they don't need to go through a lengthy and painful refactoring. Splitting one responsibility, introduce a seam, add a test. 30 mins of work per day sometimes are good enough to "train" people to do refactoring regularly
3. Show them what refactoring patterns they could use. I.e. https://www.infoq.com/presentations/Testing-Refactoring-Legacy-Code
4. Spread the word: let the team have the chance to sit together to discuss problematic pieces of code, and how they were (or could be) refactored.
5. Sell (if needed) the approach to whoever manager/stakeholder could be concerned, and try to shield the team from whatever interference may happen. Too often those efforts are killed by managers who don't understand why somebody should change code that is working ("I pay you to write good code. If you need to rewrite it then you did it wrong in the first place"). My approach towards those situations is simply to include everything in the generic definition of "development activities". That is refactoring effort is not made explicit unless necessary and it simply counts as "development" work, the same as automatic testing, etc.

Hope it helps, good luck!

Answer 2

I'm usually in the opposite position - when developers want to do so much refactoring that it starts to encroach on delivering business value. That being said, refactoring is a process like any other, and I have had teams fearing process change. It's about convincing the team to come with you.

The link that you have pasted tells your team why refactoring is good in general, but it would be more helpful to be more specific. For your team, why is refactoring important? Is it about a complex code base that is difficult to extend? Does it not scale? Do features take too long? Is the ramp-up time for new developers too long? Any change to a process is supposed to fix something - so be clear about what you are trying to fix. By approaching it from fixing broken things you can also validate if there are other things apart from refactoring that should be introduced.

Then when you have your team understanding what it is and why it's important, it becomes about how to actually get them to do it. First you will need to get rid of any roadblocks that stop them. That might mean allocating more time to building automated tests, or allocating more time for pair programming. Second, it's about checking that it's being done. When I introduce a coding standard change, I get one or two engineers to perform second-level code reviews across a random set of sprint work to see how many commits conform to the new standard. Then we discuss the findings in the retro so that we can talk about why the results looks a certain way.

In summary, refactoring is a process. Understand why you are implementing a new process. Help people get started. Talk about the results. Good luck :)

Answer 3

Fear of refactoring implies unrealistic expectations in your work environment. I would work to remove that fear first of all. If you want an automated enforcement tool then you will probably find that a suite of unit tests, that reports code coverage, will be the most-recommended approach. However, all that really enforces is that unit tests are being written; not real refactoring.

If you have reusable code, I suggest packaging it as a nuget (or similar) package and re-using it. Update your nuget and deploy to each service that uses it as part of your next update.

Packaging like this can encourage both comprehensive unit tests as well as logically factored components.

Then you can ask questions like "why does this nuget have component-x dependencies" and "why didn't you use nuget-y that already has that functionality".

Answer 4

Refactoring is a skill, like any other skills you need to practise it often to learn it well and be confident with it.

Here is what I would do to increase their refactoring skills:

• Execute the 4 example TDD coding dojo sessions, which rely heavely on refactoring: https://app.pluralsight.com/player?course=the-coding-dojo&author=emily-bache&name=the-coding-dojo-m4&clip=3&mode=live
• Let them read the Clean Code book or watch the Clean code fundamental videos of Unclebob. He explains why readable code is so important for maintainability and extendability. The only way to keep your code on this level is by refactoring.

I have seen teams gain enormous confidence in refactoring after slowly getting used to the refactoring skill in this way.