Refactoring vs. YAGNI

When introducing scrum or agile software development approach to a team or within a company, it may happen that the team members only grasp the buzzwords, but not the fundamental ideas behind them. This leads to misconceptions and contradictory situations. That’s what happened at my current project, when I asked a team member to refactor his code to increase its readability after a source code review. He responded with the words of our scrum master, which is the scrum master always repeats like a mantra: Done is better than perfect and you are not gone need it (YAGNI). Justified by these words he refused to do the refactoring. In the future (you are not gonna need it).

But how valid is this argument? Refactoring on the one hand and YAGNI on the other.

Project management perspective

From a project management perspective a radical usage of YAGNI and Done is better than perfect like in the statement from above compared to refactoring leads to advantages in a short-run. The developer saves the time and effort to touch the already working source code. Thus, the developer can proceed with other tasks. Thus, the risk of breaking already working code while refactoring can be avoided.

However, this approach leads to problems in the long-run, if the source code needs to be read or modified by other developers. First indications for problems already appear at code reviews. So future enhancements can be difficult, if the structure of the source code is chosen inappropriate and has been improved by a refactoring it.

Software development perspective

From a software development perspective the statement from above must be considered utterly critical. Wrong structured or unintelligible source code makes extension and maintenance of existing software seriously harder. Beside the fulfillments of the given requirements, software needs to be maintainable and readable. Due to this fact, refactoring is an approved method to achieve this goal. Software development clearly states the necessity of refactoring. Merely the question when to refactor needs to be considered. After all refactoring can take place when the source code is actually reworked in the future. This would be in the sense of Done is better than perfect and YAGNI as in the statement above. However, this approach leads to another problem. The knowledge about the behavior and purpose of the source code could already be lost at a future point in time. The cause could not be the same as the original author. Even the original author could forget the purpose and behavior of the code after a long time. These leads to problems when adding future enhancements or performing maintenance. For enhancements it may not be clear where to change or whichever part of the application. As a result integrating enhancements becomes significant harder. For maintenance to be almost the source code needs to clearly readable. Otherwise a lot of maintenance time is wasted trying to figure out what the code is. It is advisable to carry out the refactoring when the knowledge of the behavior and intent of the code are still present. Moreover, it is not the goal of the refactoring process. Despite post-processing, the source code may need to be refactored. However, this later refactoring is much easier and faster, because the source code already exists in an understandable and well-structured form and does not need to be transformed into a well-structured form.

Test-driven development perspective

When developing in a test-driven fashion, then the case is clear. Test Driven Development is based on the TDD cycle or red-green cycle, which consists of three phases: The test fails when a red broken test indication. In the second phase source code is added fixing the failing test. The test now succeeds causing the test indication to turn green. Refactoring is the third and final phase before a whole cycle is complete. Thus, the test-driven development cycle is not complete without a final refactoring. Refactoring takes place immediately and as soon as possible Done is better than perfect and YAGNI like stated above.

Agile software development perspective

The goal of agile software development is to deliver working software continuously and early. Flexible to fast reacting to change, the software quality needs to be high and the software itself has to be flexible. This procedure promotes incremental development. As already described in the software development perspective, subsequent refactoring involves time loss and problems in comparison to refactoring at creation time. Until the subsequent refactoring has taken place, the quality and flexibility of a software has dropped. Regular refactoring and a clean source code belong to high quality software. Under this premise, a postponement of refactorings is no option for this perspective.

Looking at YAGNI and Done is better than perfect in their birthplace, agile software development itself. They should not be able to make the necessary effort for future features at the present time. These features can be implemented, if necessary or when they are finally scheduled for implementation. The time freed up by this approach should then be used for the improvement of the software quality, which includes refactoring as well. YAGNI is an encouraging software to be flexible. Consequently, YAGNI and refactoring do not contradict, but even literally depend on each other.

Conclusion

Here is a short summary of all reasons from above:

In summary, refactoring at creation time is necessary in any case. Assuming that YAGNI and refactoring contradict each other is a misunderstanding of certain software developers.

Finally, a recommandation: It is often argued against refactoring that there are no clear goals. Taken to the extreme, a piece of software can be refactored and optimized for any length of time. It is necessary to define clear goals for software quality and refactoring. So a “Done” is thus achieved for refactoring. Thus, it is my advice to use the definition of done in scrum to define quality criteria using code analysis tools such as sonarqube and checkstyle. Then refactoring takes place until the source code meets the requirements.

“>

Related Posts

• 

  Street food berlin – the story behind the latest food truck

  Site: passenger-x.de Streetfood Berlin – The story behind the latest food truck Sure you like street food markets as much as I do. A wide range of…

• 

  School test: examination for a successful start in school

  School test: examination for a successful start in school Before a child is enrolled, one is school test necessary. The doctors check their physical and…

• 

  Broadcare Oral Shower in the test: current oral showers in comparison

  BroadCare Oral Shower in the test BroadCare Oral Irrigator Review: Read our review of the BroadCare Oral Irrigator here and compare it to other current…

• 

  Dental practice schulz – ts

  Property exchange Click here for the Henry Schein property exchange. Always up to date. Dental practice Aneliya and Norbert Schulz | Nuremberg-Altenfurt…