But incremental refectoring lets management see what it is buying sooner in terms of retiring technical debt. Ever heard of Netscape? Oh, not recently? Now i know, but time is runnig out. One example: Microsoft rewrote Exchange Server from scratch using C. I think this was a wise decision. If your code is a mess, I would advise you to rewrite it from scratch, with the intent for the code to be well organised, modular, and well understood. I believe that working on and servicing messy code is a losing strategy.
Another example from a different area: Architects nowadays build houses in a way that they can be cleaned easily. I … Read more ». How did you learn of it? Thank you so much, Eric!
I think I will not be needing the extra space, unless Kevin Mote wants more info. Thanks, again! The 3D application I had inherited was written with an engine designed to take advantage of modern video game hardware for multiple high-performance cores and high-end graphics hardware. I am Erik Dietrich , founder of DaedTech. Subscribe, and I'll send you a PDF with about 10 posts' worth of content from my book!
Oct 18 By Erik Dietrich. Oldest Newest Most Voted. Inline Feedbacks. Bud Goode. Anish Patel. Reply to Bud Goode. Reply to Anish Patel. Paul Coddington. Erik Dietrich. Reply to Paul Coddington. Reply to Erik Dietrich. Minnesota Steve. Steve Naidamast. Reply to Minnesota Steve. Jordan Whiteley. Ah, yes, there we go. Reply to escapist Fermin Saez. When you go to it you are not trying to load it as quickly as possible to make an impulsive purchase of some ETFs — you're probably doing your yearly check-in or enrolling for the first time.
You'll probably check your balance, your contributions, the performance of your holdings, and maybe even download a few tax documents. We found that users were coming less often, while spending far more time on the website, using many parts of it — the perfect use-case for a single-page web application. The initial load time was a low priority while seamless transitions between pages were of great value.
New applications were kept separate and had new code written with the new paradigm. This allowed for a quick, gradual, and seamless transition from old technology to new, with very little loss of all those years worth of things like tests and bug fixes. Unfortunately, some developers and institutions bank hard on convincing others that a rewrite is the best use of their money. To do this they rely on convincing others of the inferiority of older, battle-tested languages like Java and PHP to newly popular technologies like Node.
Maybe, even, the experienced Java developers that we have aren't as good as we once thought. This is contempt culture and it's prevalent in some software development communities. I know this because I was one of the developers who called old languages terrible, clunky, slow while claiming the superiority of my language of choice.
The same thing happened when I read through Martin Fowler's Refactoring — he transformed hard to understand, hard to change Java into code that is clear and easy to change to meet new requirements. After starting a new job at The New York Times — which has amazing code quality, and not just for an organization that is over years old — I found that the company still has some legacy Java and PHP services. It turns out that these services are so well-factored, with such well-established patterns, that they were incredibly easy to understand.
Less than two months into the job and I was able to traverse several of these codebases to find exactly what I needed. Back to rewrites. I mentioned earlier that some developers rely on convincing their managers that a rewrite is necessary; in some cases, even multiple-year, large team efforts to completely rewrite existing codebases. I've even seen a case where there were multiple rewrites in a row. No, I don't finally have the right programming language.
Maybe I finally have the right team, but probably not. I recently experienced this first-hand. In the codebase I'm currently working with, I encountered an error handling pattern that I didn't like; it seemed cumbersome and convoluted. My initial thought was to ignore this pattern, rewrite it, maybe even replace it with a better solution.
That was until I found that the original author put together an entire talk about this error handling pattern. It turns out that, while it may be a little confusing, it gives incredible transparency when you need to debug with application logs. The real problem is that I hadn't taken the time to understand how the error pattern worked. I was confused, which led me to dismiss it, rather than to improve it. Subscribe to my newsletter to get an update, once-per-month, about what I'm writing about.
Here's a rule of thumb: If your reason for rewriting the code is that you don't understand it, you should not rewrite it. Instead, you should spend the time trying to understand the code. Once you understand it, refactor the code to make it easier for the next person to understand. Instead of rewriting the error handling pattern I will probably try to improve a few method names.
This brings me back to Martin Fowler's Refactoring. Most of the time, if you feel that a rewrite is needed, you can probably just refactor a few pieces of the program and you'll be in great shape. Do you do hallway usability testing? It could change your career! Leave a Comment Cancel reply Your email address will not be published. We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. However, you may visit "Cookie Settings" to provide a controlled consent.
Cookie Settings Accept All. Manage consent. Close Privacy Overview This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website.
These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience. Necessary Necessary. Functional Functional. Performance Performance. This will dramatically decrease the time and cost of accommodating customers with special needs. We'll win more accounts and better meet the needs of our current customers.
Never, always refactor - the truth is if the code was written by you - you won't be able to do any better. Everything should be designed as a blackbox. Modular, Simple API, what is inside I think the main reason that justifies rewrites are for platform changes. For example, if you have a Windows desktop GUI application and the company owner decides they want the next version to be a web based application.
Although not always, in my experience most of the time this will require a rewrite, unless the original developers wrote very modular and reusable code hardly happens. According to Joel, big rewrites are the single worst strategic mistake a company can make:.
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. First of all, you probably don't even have the same programming team that worked on version one, so you don't actually have "more experience". You're just going to make most of the old mistakes again, and introduce some new problems that weren't in the original version. The old mantra build one to throw away is dangerous when applied to large scale commercial applications.
If you are writing code experimentally, you may want to rip up the function you wrote last week when you think of a better algorithm. That's fine. You may want to refactor a class to make it easier to use. That's fine, too. But throwing away the whole program is a dangerous folly, and if Netscape actually had some adult supervision with software industry experience, they might not have shot themselves in the foot so badly.
I took a job once, where the employer's prime motivation was to bring talent aboard to launch a long-overdue rewrite of a business-critical app. The question I failed to ask was, why have you ended up in this situation in the first place? It should have been a red flag, whether the cause was. So I'm going to agree with Joel in that a massive rewrite is probably a very bad idea - unless you have firm evidence that all the underlying reasons behind why a major rewrite seems so necessary have been dealt with , you're in all likelihood going to repeat the problem in due course.
As for client-controlled transactions Even then, I'm not sure that I would have done the rewrite, except that I had detailed knowledge of the current system's behavior, and it was relatively clean code that hadn't developed very many warts in its 11 years of life. To decide the point at which you should start over, you need to work out where the value of continuing on your current project falls short of the value in starting over.
The reason this is so difficult is that you make an accurate estimation of the team's development velocity on the new project until you actually start it.
That said, if, using a VERY conservative estimate of your development velocity on the new project, the project is estimated to give a worthwhile return on investment, then you have a business case for starting afresh.
Even then you want to limit the scope of your rewrite. The end result was speghetti code in the form of a finite state machine that spanned multiple classes and DLLs. We had a new requirement that was very different from the assumptions built into the code, and was going to be part of the company's patented value-add to its customers.
After spending time with the code implementing other features, I had a really good idea of how long it would take to figure out which of the several switch statements I would need to change, etc. My proposal was to rewrite the section of code that was the huge finite state machine--it should take me less time than extending the existing code.
I was able to consolidate into one DLL what used to be three, and provide a much more object oriented structure that would make it a lot easier to do the critical new functionality along with making it easier to add new functionality. There were three other applications using the libraries that needed the rewrite, so I didn't want to have to completely rewrite those programs. The scope was limited to the library and what was necessary to bind the library to the existing software.
My estimates weren't off by far, and the work paid for itself. Shortly after the redesign, I was tasked to add a new feature. What would have taken me a week with the old structure only took me a day with the new structure. In short, I would plan the re-write in phases, prioritizing first the update in libs. It might be that along the way, you can sneak in other optimizations, but the fact that you plan to defer some changes to a later phase can be a great way to stay on schedule and avoid getting "stuck.
For almost any real world scenario though I would just recommend refactoring in place. There tend to be too many hidden, unanticipated costs to rewrites when undocumented legal and business requirements start to pop-up and the last minute hacking things together last minute starts to ensue.
To some extent you might be able to get away with separating out your presentation, business and persistence layer and writing a new app that is fully backwards compatible with the legacy solution, or at a minimum can still handle data inputted by legacy solution.
I would say there is a third category in the Refactor vs Rewrite space And that's updating your language versions, compilers, and libraries Sometimes just adopting modern coding techniques has a great benefit. Take C for example, v7 code writes a lot cleaner, safer, and more concise than v Things like the Elvis and null coalescing operator help out a ton. Switching compilers might also breath new life into older code.
So might new libraries that might make things easier to work with and implement Networking is a great example of a spectrum of implementation difficulty. Also- embedded linux systems Think about installing new tools- switch to git from svn.
It doesn't always have to be a refactor vs rewrite.. Your architecture is probably in need of improvement, but it works What happens is that people are writing totally new apps with a different architecture, technologies,etc which have some features in common with the previous generation.
And it is called app 2. But this is not really a "rewrite" of the original in the sense that you are trying to achieve feature parity. Sign up to join this community. The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group.
Create a free Team What is Teams? Learn more. When is a BIG Rewrite the answer? Ask Question. Asked 11 years, 1 month ago. Active 1 year, 7 months ago. Viewed 71k times. I work in a fairly small company so the proposal has the possibility of being approved TL;DR When is a big rewrite the answer and what arguments can you use to support it?
Improve this question. Also, related: programmers. This is a great question. Very relevant, this situation occurs frequently in software engineering.
Add a comment. Active Oldest Votes. Developer ramp-up time is very high. If it takes any longer than below by experience level to ramp up a new developer, then the system needs to be redesigned. By ramp-up time, I mean the amount of time before the new developer is ready to do their first commit on a small feature Fresh out of college - 1. Too many use cases are executed on too few screens.
This causes training issues for the users and developers. Technical The coupling of components is so high that changes to a single component cannot be isolated from other components. A redesign of a single component results in a cascade of changes not only to adjacent components, but indirectly to all components.
The technology stack is so complicated that future state design necessitates multiple infrastructure changes. This would be necessary in a complete rewrite as well, but if it's required in an incremental redesign, then you lose that advantage. Redesigning a component results in a complete rewrite of that component anyway, because the existing design is so fubar that there's nothing worth saving.
Again, you lose the advantage if this is the case. Political The sponsors cannot be made to understand that an incremental redesign requires a long-term commitment to the project.
Inevitably, most organizations lose the appetite for the continuing budget drain that an incremental redesign creates. This loss of appetite is inevitable for a rewrite as well, but the sponsors will be more inclined to continue, because they don't want to be split between a partially complete new system and a partially obsolete old system.
The users of the system are too attached with their "current screens. A redesign lets you circumvent this problem, since they're starting with something new. They'll still insist on getting "the same screens," but you have a little more ammunition to push back. Some strategies for success: If you do, however, do not try to convert existing code. Design the system from scratch. Otherwise you're wasting your time.
0コメント