|
Have a very large project more than 70k LOC. The project definitely needs some code refactoring in Core Framework and in other parts as well. There was NO time set in the beginning of the project for refactoring. However with time and more than 40 developers joint and left the project. From my perspective is indispensable. What would be your key points in arguing and defending a proper software development principle? |
|||||||||
|
|
When working on legacy or brownfield application it is tempting to do a "spring cleaning" hoping to refactor the whole thing back into shape. That is in no way justifiable use of resources. After all, how is halting development on working software (only working code can be refactored) jusitifiable? Can you guarantee the time spent on the Big Refactoring Phase is going to pay off later and not cause degeneration on the project? How do you eat an elephant? One bite at a time. Whenever you need to implement new feature or fix a bug you see if that part needs reimprovement. Like the boy scout rule says: "Always leave the campground cleaner than you found it." Refactoring shouldn't be a separate phase, it is part of every day development. When you get this culture of quality introduced to the development team, the quality will improve. After that there is not anything to justify to the management. |
|||||
|
|
In general, refactoring should be done in order to enable another change you need to make to the code or as a natural clean-up step after a change has been made to the code. In that case, there's nothing to justify. Refactoring is simply part of the process of doing work on the project. The time is billed to the task you were working on when you did the refactoring. If it ain't done in small increments, then it ain't really refactoring, eh? |
|||
|
|
|
Refactoring, like any other activity, must have a clear goal defined for it. Once that goal is clear, you would consider the current project status and life cycle stage. For a development project that is 80% complete, 30% behind schedule you should justify refactoring effort based on the goal set earlier. In this example, if the code pieces were unit tested and is working fine in a development environment, it is hard to justify refactoring. The fact that 40 developers left may not be as dramatic as it sounds. I'd expect that those developers have delivered working code that was reviewed and tested. So, unless there are known problems in this code, I'd leave it as is. The idea is that in a large project like yours, I'd expect that there were standards and procedures and that the code is not a complete mess. Remember that refactoring will cause many if not all tests that has been made to be repeated. Also, since the refactoring of this size can't be done by a one or two senior members, the refactoring may introduce problems that did not exist. This is a risk that should not be neglected. Having said that, it is not unusual to add tasks to a project when the unforeseen happens. So, if the developers disappeared for some reason, that that would be considered an event of a special nature and whatever actions to remedy the situation must be taken. It would be treated like a fire or an earthquake, etc. In summary, I would not refactor large working code in a large project for no good solid technical reason, specially that we all know that most project are usually in late status. |
|||||||||
|
|
All good answers here - but may I add a business dimension to this. Let me ask you WHY/So-What? (think of your pointy hair boss (PHB) :)
PHB: why?
You: It'll make things easier to fix
PHB: So-what?
You: It'll increase throughput - we'll get new builds out the door quicker?
PHB: So-what?
You: Err...Happier customers?
PHB: WTF?
You: I mean increased recommendations, greater satisfaction,
more profit sooner due to low turnaround
PHB: Oh! Sounds nice. But it only "sounds" nice can I see it?
You: WTF?
PHB: Show me the money! (i.e. numbers please)
You: Oh! Brb...(go and put some numbers in simple spreadsheet to make your case)
Basically you must make a business case - run some numbers to clarify your thought process and get the numbers to reflect the 'benefit' objectively. You'll also know how much time it'll take, approximate costs etc. It should make sense. If it's worth it you'll get the green signal and maybe spearhead the initiative too :) If you think how can I measure everything try this book |
|||||
|
|
Imagine that you are in front of a long and huge wall. You need to go to the other side. Either you refactor the wall in order to build a door, or you go around it. Estimate the time for both solutions and you get your justification for refactoring. Don't forget to multiply the time in the second solution by the number of people needing to go to the other side of the wall. |
|||
|
|
|
As I read in one of the other answers, eat this elephant one bite at a time. I'm involved in auditing a large international project, where team members are geographically dispersed. After building the first two versions of the software the team agreed that their approaches, style of coding and building solutions is inconsistent. They agreed to write new parts of the application following the new rules and convention and when (and only then) they have to change some of the old code, they first refactor it to meet the new convention. Everything is working quite well. The refactoring process is almost in its 5th month, some of the code is refactored, some still isn't. New features are brought in time, clients are happy, devs are happy, QA team is also happy. A win-win situation :) |
|||
|
|
|
Main point of refactoring is to make things easier in the future. You cannot show profits of refactoring unless you compare multiple long-term projects few done with and few without constant refactoring. It is generally accepted across developers, that refactoring decreases cost of maintenance and implementation of changes, but those are hard to prove from business standpoint. The key reason to implement refactoring is to reduce Technical Debt. Also, refactoring should be continuous process and time spend on the refactoring should be included in development task itself. Having special "refactoring task" is not good idea. |
|||
|
|
