Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. (Robert C. Martin)

Read a story here about how an organization brought to its knees launching software that was buggy.

An organization does not always have to start software development in the cleanest way possible.  Deadlines, stakeholder pressures, there are tradeoffs that need to be made to launch a working software, including its inner quality.

At one point later, these technical debts need to be paid, by refactoring the code, improving its internal quality without adding features.

Technical books mostly explain refactoring from a technical perspective, but implementation in a project where multiple regionally distributed teams are involved requires several other perspectives which are not written in technical books.

Here are the lessons that I learn from our refactoring:

1. Developers don’t like it when other parties rewrite or tell them to rewrite their working code. Resistance will surface, because of several reasons: a) developers do  not understand why the code is smelly and needs to be refactored b) developers don’t have a good relationship with the other team c) tight schedule to release additional features d) developers come from different programming language will bring their own understanding of software engineering best practices which may not be applicable to the other programming language
2. There are developers who are good at solving problems but need to improve on software engineering best practices. Many of them are the heroes of the team, and the most resistance will come from them.
3. The Solution Architect is the key person, to give early communication and short multiple training, resolving resistance from the developers.
4. What is it for me? The developers need to know what are the benefits for them personally to do refactoring. Mention about future career prospects, and the benefit of a clean code should one wants to stay long term in the project.