Tracking change and innovation in the enterprise software development community
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Posted by Vikas Hazrati on Nov 24, 2009
The goal of refactoring and rewriting is, to improve the sanity of the system by improving the code readability, structure and clarity. A clean code would be easier to maintain and enhance. However, on many occasions Agile teams have a tough time deciding between the two.
Michael Dubakov suggested the following reasons for the code base getting worse over time,
- More and more features. It leads to increased complexity.
- Shortcuts and hacks to support “We need this fancy search till August. Period!” features
- Developers rotation. New developers don’t know all the fundamental decisions and ideas behind the architecture. Knowledge gets lost with transition inevitably.
- Development team growth. More people - less communication. Less communication - bad decisions.
Michael suggested that, though refactoring and rewrite might lead to cleaner code however, both the techniques bring chaos to the existing system. Refactoring is an incremental activity hence it touches some portion of the system at a time. This creates chaos at local levels and might be easy to contain. Rewrite on the other hand is a more invasive change and results in a bigger chaos in the system. Due to the wider impact, the stabilization period of a rewrite is much longer than that of refactoring.
We have the old system during rewrite, so chaos is constant. After the public release chaos increases significantly. Quite many new (and old) bugs and quirks are expected, so stabilization period is longer.
Peter Schuh suggested that often teams use the words interchangeably there by resulting in more confusion and chaos. Teams should understand that rewriting is riskier proposition as compared to refactoring and hence should use the terminology accordingly. According to him,
It’s just semantics. Well … it’s only semantics until someone gets hurt. Rewriting code is a risky and sometimes painful endeavor. It doesn’t always end well. If we execute a rewrite but call it a refactor and the whole thing goes pear-shaped, no business person is going to stop and think about semantics. They’re just going to cringe the next time they hear the word refactor.
Guido A.J. Stevens made an interesting observation. He suggested that the question is not between refactoring and rewriting but it is between either: refactor, or else: rewrite AND refactor. He suggested that even when a team decides to rewrite the system they would eventually have two systems running in parallel. The old system which would require refactoring and the new system which is being rewritten. The combination becomes an overly complex task. According to him,
Maintaining an aging code base, AND writing a new system, is going to be a huge drain on your resources. Your team is split and will run into delays. You'll have to plan and carefully execute a transition. Meanwhile, your competitors don't have your time-to-market problem and will try to steal your customers. If you can stare this reality in the eye and still want to bet the firm on a rewrite, you may have a chance of succeeding.
Naresh Jain had the following suggestions specifically for legacy code. Refactor when the code is difficult to understand and the team is not sure of what it does. Rewrite when it is clear what the code does but it is difficult to understand.
Thus, refactoring is the preferred way to incrementally improve the system. It is slow paced, improves quality with small and constant improvement. Rewrite has its advantages however, in most situations it is a riskier option and the teams can never be sure about the outcome. As Joel on Software suggested,
It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.
Design in Agile, Software Craftsmanship, Product Development, Testing @ QCon London in March
Technical Debt and Design Death
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
In growing trend of Technology being the back bone in most of the buiness companies, in the same way technical people need to know the business, I see a demand for business people knowing the technology becomes imperative. So some of the design practices we use like refactoring, eventhough it goes not have any meaning to business, but I think that keep system little more stable and reliable than before. So we need to cross train business people to understand some of the technical/design methodologies we use. Those days of clear separation is fading way...Collaboration with overall system knowledge is becoming mandatory for successful launch.....
Interesting piece. Thanks. I'm wondering how many have seen this movie before in prior lives? Team demands that they have to rewrite and gets approval to do so. Months in to the project they begin to realize how high they've jumped from and they are without a parachute. Due to market pressures the product needs to be released to drive sales, revenue, or to stay competitive yet they are still rewriting plumbing and many of the core features in the product still haven't been added back in let alone any of the new desired features. With time running out before they hit the ground with a rather large splat they have no choice but to reach for the reserve chute...they resurrect the old code that worked, refactor a few key bits, and make their commitment... Nobody is happy. I've seen this movie at least 4 times (unfortunately once on my watch many, many years ago) and it always seems to end the same. Just sayin'. ;o)
Now, I'm leading the refactoring of a on-line application, whose code hasn't been cleaned for more than two years. Actually, I cannot help myself to consider to rewrite it at all, but finally I decide to control my step and divide the whole process into several rounds of local refactoring, and now the first one has been finished. It is more practical for me to collect resource and persude the business peoples that the risk is under control.
I think that the following reasons will lead also for getting worse code over time:
- Misidentifying requirements / Changing of requirements frequently.
- The pressure made by the business (the owner of the application) to have something that works. In this case the first worries of the team will be delivering as soon as possible which will lead to a completely ignoring of code quality.
I'm totally agreed with you, I’m using the same approach as you. It’s very interesting, I did not find it very hard to convince my business to use this approach to improve our code and our delivering.
Still, sometimes you must switch platform for some reason. Then you have to rewrite. If possible it is best to split up the code into pieces to be able to port a part of the time to better deal with the problem of concurrent development (old+new). The thing that people don't always think about is that there are some things one should take with them from the old crappy code. The general flow/organization of the old code. There can be some important solutions and bug fixes that one can reintroduce. Sometimes the general flow of pages/screens/object can be good enough even if one doesn't understand the code and it is this that takes up a lot of time when coding.
Nice article, I am only missing some good arguments for the other side. Do they even exist?
I am big fan of refactoring but it's not the panacea.
Refactoring is incremental, therefore it is a linear process. Unfortunately, the development of software systems is far from being linear. It is actually quite non-linear and that means that some (bad) changes in the code are potentially irreversible (or would be ultra costly). The physic guys call it entropy: when the paste is out of the toothpaste tube, you will have a hard time putting it back in that same tube. In a system, the higher the entropy, the most likely you will be able to "simply" refactor.
On Joel's note "It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.", two things:
1) Between developing a system with a defined set of features in 2004 and developing a system with this same set of features in 2009, there is going to be probably at least a 50% productivity advantage for the latter. Why? simply because software is one of the most efficient industries in terms of productivity gains each year (who spend time to write SQL code manually besides DBA nowadays?).
2) There is something else called the "experience curve effect". It says that the more you perform a task, the more efficient you get for that task. Even though this effect has been demonstrated for manufacturing, I also think it is very meaningful in the software development industry.
Rewrite has its place for some situations, and it is not completely stupid! :)
Sometimes, refactor and rewrite has become an ordeal, even more for those who are proposing the Re factor or Rewrite suggestion. Other dev guys often think that there logic is being tormented into pieces(funny isn't it !). Even sometime you will find a file of 1000 LOC where more 500LOC are commented; reason, they can be used in latter part of the project.
Of course, if proper code reviews has been done then probably the situation called "rewrite" wont arrive and if it does then probably for advancement of certain components or new technology.
I agree with your approach. Incremental steps offers less risk than re-writing the whole application. It is very important especially for software product that is already out in the market.
Sometimes, refactor and rewrite has become an ordeal, even more for those who are proposing the Re factor or Rewrite suggestion. Other dev guys often think that there logic is being tormented into pieces(funny isn't it !). Even sometime you will find a file of 1000 LOC where more 500LOC are commented; reason, they can be used in latter part of the project.
Of course, if proper code reviews has been done then probably the situation called "rewrite" wont arrive and if it does then probably for advancement of certain components or new technology.
Code reviews are ideal, but let's face it, ideal situations are very rare, especially if you're tasked to improve a Java code written 10 years ago when design patterns and framework does not exist yet, and public and static modifier are abused.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
10 comments
Watch Thread Reply