Talk: Rewrite, Rework or Refactor
Speakers directory
Speaker:
David Legge
Talk description
Title:
Rewrite, Rework or Refactor
Short synopsis:
“Let's just rewrite this” is a common refrain in the software industry and even newly written code can quickly come to be seen as Legacy Code. It is often seen as the easy option, but can lead to months and even years of effort to replicate a system with the same set of problems. This session will look at the dynamics, risks and approaches associated with when this question is raised, using examples from a broad experience and perhaps some comparing of notes with the audience. At the end of the session, you should be able to make an informed, balanced decision which might even be the correct one.
Max size: 500 chars
Long synopsis (optional):
[Content described is based upon a 45 minute talk, but this could easily be extended to an hour] There are a number of reasons why a rewrite of a current solution is considered the answer to all ills. Sadly whilst some are legitimate, some of these just don’t consider the significant risks involved. There can be imperative or legitimate reasons to rewrite; sometimes the language of a codebase can just become obsolete, unstable, insecure, or unsuitable for the purposes of the solution. Equally the recruitment of new staff to work in that language can become the bottleneck, with the skills disappearing from the market. But sometimes it can just be a jump to a shinier technology, chasing the microservices dream or latest industry trend. But what are the risks? Firstly, there is the sheer amount of elapsed time to reimplement and replicate the existing set of features, and the rewrite is often not able to be released and deliver value until *all* the existing features are in place. The problem here, as witnessed first hand, is that the first deliverable becomes so large as to be unmanageable; Software Development has diseconomies of scale, as Allan Kelly says. And for all that time the original codebase must be maintained. All too often new features are required on the original in the interim, making the rewrite having to aim at a moving target. Secondly, there is the amount of effort required, ie the sum of all the development effort on replicating something you already have. Not to mention the management time and opportunity cost of working on something else. And is the existing product or application being maintained and updated in the meantime? Thirdly, when you consider Conway’s Law as well as technical and organisational culture, will a rewrite deliver the value anticipated or hoped for? If the organisation has produced a codebase with minimal automated testing what is to say that a new ‘Greenfield’ replacement will suddenly be developed with sufficient test coverage or developed under Test Driven Development (TDD) methodologies? Software produced by the same people under the same conditions is likely to have similar outcomes. The only way to break this loop is by making sure you learn from the mistakes. Was the original really as a prototype for the rewrite? or has the organisation and team failed to ensure the code, tests and pipeline were up to standard? Fourthly, in trying to rewrite, you are in danger of having to reimplement an existing application warts and all. Suddenly bugs and workarounds have become features, and the expected behaviour is that of the existing product, not that of the original requirement. This can add significantly to the complexity of the solution, where ‘accidental’ (unnecessary) complexity introduced by the original solution has become part of the ‘necessary’ complexity of the domain. Finally, there is significant risk that once the decision is taken, or even before, to eventually retire the existing application, the team and organisation can psychologically ‘give up’ on maintaining high standards, either deliberately or not, and the existing codebase can rapidly degrade. Problems are not fixed or addressed, and worse, new work is done in a more slapdash manner, with the result of a death-spiral. But what if the time and effort you were going to spend on rewriting was spent on taking the existing system in hand? It’s Software not Stoneware™ after all; teams can become afraid to change the code leading to ossification and a loss of working understanding of the code. So what are the alternatives? Well that depends on the motivation for the rewrite. If it is to update the UI, then moving the existing backend to a rest server and ‘skinning’ the application with that afternoon’s hottest javascript framework might suffice. The rest of the application may be heavily affected if the original architecture did not separate the presentation layer from the business logic and other workings. This highlights the importance of using APIs to decouple the application's architecture. If it is the lack of testing, then starting to introduce tests over time may be a more profitable approach, as described in Michael Feathers’ Working Effectively with Legacy Code. As the level of automated testing progresses the more the codebase can be improved so that it is also more testable, and ultimately enables refactoring of the existing codebase. With poor code quality or architecture, then a conscious evolution of the codebase over time can be more productive, using techniques from Michael Feathers book. Sometimes instead of wringing hands over the quality of the codebase it comes down to getting out there and fixing it. Whilst a Move Slowly and Fix Things is usually the correct approach, when a legacy system needs re-architecting there sometimes needs to be some creative destruction to get from A to B; you can’t make an omelette without breaking eggs. After all, the architecture is often defined as the things that are hard to change. Regardless of everything else, if the principles of Continuous Delivery are applied to the existing system much can be achieved: having a build pipeline, single click deployment, database automation (ahem). Modularisation, introducing strong, clean APIs, decoupling of components, updating and wrapping of dependencies all improve the structure of the code, and your ability to understand, maintain, extend and change it. Separating out the state from the operation of business logic can be essential to allow reasoning about the state whilst refactoring to immutability can bring clarity to thinking. Through the talk I will provide examples of the different approaches that I myself have used in different projects, to resurrect codebases and deliver value, without throwing the baby out with the bath water. I will also invite the audience to relate their own experience. It’s amazing what you can achieve with the existing codebase. And often it can be done with less effort than employing a full rewrite. Rewriting can sometimes be the correct decision, but it is not risk-free as sometimes presented. This session will explore these risks and when it might be the right and wrong answer. Ultimately, this session should help you come to a considered and balanced decision. ------- Timings: 5 mins - Introduction 5 mins - Interactive section on ‘Why do a rewrite’ 10 mins - Rewriting: the risks involved 5 mins - When a rewrite might be the best option 10 mins - What are the alternatives? 5 mins - Tie up & Conclusions 5 mins - Questions
Max size: 5000 chars
Tags:
Speaker directory:
Listed in directory
Not listed
Speakers directory