Slashdot Mirror
When Rewriting an App Actually Makes Sense
vlangber writes "Joel Spolsky wrote a famous blog post back in 2000 called 'Things You Should Never Do, Part I,' where he wrote the following: '[T]he single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.' Here is a story about a software company that decided to rewrite their application from scratch, and their experiences from that process."
5. When it is written in Visual Basic. Always.
4. When I'm getting paid by the hour and it is written in Visual Basic. Always
3. When it was written in a mid-90s WYSIWIG bastard child of a mid-80s interpreted language.
2. When it uses a thousand "IF-THEN-ELSE" when it means to use regular expressions
1. When it is written in Visual basic.
I am about half way through the article in the second link, and it is really interesting, and informative. :>
Maybe not news, but it is worth your time (or at least mine).
Actually, from what I got from the article it seems they also felt that the basic design of the original version of application just wasn't good enough, that it was in fact seriously lacking and that a gradual rewrite would take longer and not accomplish what they wanted (to clean up and future-proof their application).
Greylisting is to SMTP as NAT is to IPv4
Hi!
I'm the author of the blog post. The Joel article is 10 years old, but not the one I wrote(the the second link).
Vidar Langberget
you must stop looking backward.
Drupal does indeed brutalize your database (see second link). So looking forward to D7 to clean this up. That alone was sufficient justification to rewrite the application :p
Unfortunately the author goes on to display his ignorance before this is all over: There are also other examples of total rewrites that have been successful. Apple's transition to OS X is a very good example. The classic Mac OS was an operating system with some good ideas, but the core architecture had a lot of problems. Did Apple make a bad decision to start from scratch with OS X? I don't think so. They brought over and improved the best bits from OS 9, and merged it with the solid Darwin core (much like we did). Uh, no, you are totally and completely fucked here. They started with NeXTStep, last updated in 1995; it was itself based on an older version of BSD (4.3?) and an older version of Mach. OSX is not a complete rewrite of anything. Its legacy stretches back into the 1980s, and so does its code.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
The problem is that companies usually rewrite for all the wrong reasons.
A good reason would be the emerge of a new technology that supports your problem much better, to the point where redoing your code from scratch means easier maintainance later. Usually this goes hand in hand with an old technology (the one you used so far) getting abandoned by its maker. A good example would be how I had to maintain a client/server app written in VB6 using DCOM. Not some quick hack, a full blown client/server solution it was never meant to be, that also has to communicate with a SAP interface and a few more nifty things that cried out "please rewrite me". The overhead to maintain it soon turned from insane to nuts and even the tinyest change required a team of four people to work for weeks.
Unfortunately, the reasons why something gets rewritten are usually different. Like at my next gig. A pretty well designed and fairly solid piece of code was thrown out when the original creator was fired and someone with an ego that required its own office took over and insisted we use "his" collection of libraries instead of that "old" libraries. We trashed about 2 manyears of labour down the drain to end up with what we had before.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
I just looked at their article, and 6 KB of the page was near-useless VIEWSTATE data. If they can, they really should disable the generation of that. It's a useless artifact of the broken ASP.NET WebForms approach, which isn't really even necessary for a blog like theirs.
Seriously, with a typical Slashdot posting resulting in 80,000 unique hits for the target site, they're going to waste over 480 MB of bandwidth serving up just that useless VIEWSTATE data.
I've seen rewrites/ports go quite well. Systems that were originally on mainframes and needed or wanted to be moved to cheaper hardware for cost - if it was the proper thing to do (Sometimes you really need the metal).
Another rewrite that went well was a bunch of code that over the decades became so convoluted to be a maintenance nightmare - modify one thing or add on functionality and then break a shit load of other things.
Just do these basica things and it'll work out.
Go back to the specs and start there.
Talk to the stake holders - yep, there will be creep but also feature reduction because there are things that they never used or because it doesn't make sense anymore.
Plan, plan, plan. No cowboy programming and hacking out shit. And document everything.
It can work.
RIP America
July 4, 1776 - September 11, 2001
I'm going to forward your blog post to several clients and colleagues. The clients need to see why I make sure they know what they want before we start development (they never understand how hard it is to change infrastructure on the fly or just "do it again"), and the colleagues because they need to stop selling one product as something else that can "do what you need with just a little bit of tweaking".
... until we sell it to someone else who wants "just one little change ...".
We do some small custom web apps for clients, and even a few that have the potential to grow into bigger (but not big) products. While rolling out one of them this week, to the first of three clients who have ordered it, I'm already designing a complete re-write of the core of this product. What started out as a small helper app for one client has turned into a PITA to scale up and out for these other clients. Clearly it's better to fix it now than to keep patching & splicing in order to make it work for them
Well here's a story from the stone knives and bear claws-era (early 80s):
Two programmers were tasked to convert the Atart VCS/2600 game Pitfall 2 to a Commodore=64 and Atari 800 computer. One said, "The Atari console is so primitive that it's easier to recreate the whole game from scratch," and the other said, "No just copy the 6502 code and then modify it for the varying graphics/sound chips." They then went their separate ways.
- The Commodore=64 programmer recreated the whole game from scratch, and produced a slightly-flawed but decent port.
- The Atari 800 programmer simply dumped the code directly, and then modified it. He produced a port that played identical to the original PLUS he had enough time left-over that he added a whole other game (basically Pitfall 3). So Atari 800 purchasers got two games for the price of one.
Reworking is faster than starting over. Even if the design is a complete mess, there's typically SOME modules that can be reused, and that's time saved
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
You're assuming that the original design isn't an organically grown mess of code that's grown and mutated over the last 10+ years (this is pretty common on the business world), preferably written in some proprietary and deprecated language (ASP + VBScript is a current classic, most likely pushed to the company as a good "business language" by some MS sales drone). After ten years of "organic" growth of such apps cleaning them up generally takes longer than just rebuilding from scratch in a sane language with proper separation of presentation, business logic and data storage, exporting the database to the new database and calling it a day. Really, I've done this more than once and sometimes these code bases end up so rotten that it's painful to fix minor bugs, stuff that should take thirty minutes ends up taking the better part of a day because the entire codebase is a total mess with include-o-mania run wild (anyone remember that from the PHP3 days as well? lots of if(condition) { include("filename.php"); } crap that almost impossible to follow).
Greylisting is to SMTP as NAT is to IPv4
I noticed that your regular expression doesn't allow the plus sign as a valid character in e-mail addresses. For example, a lot of e-mail providers allow receiving mail at, say, pino+regexlib@example.com, which gets put in the same mailbox as pino@example.com but tagged with "regexlib". See here for instance.
Look. Spolsky runs a dinky little software development firm that sells a little project management program. And it's still a dinky little software development firm after a decade. It's not like this guy runs a company that does anything critical, like avionics software, or anything really big and tightly integrated like Facebook, or financially significant like Chase's banking system, or leading-edge robotics like Boston Dynamics, or cutting-edge manufacturing like HyperMill. No, they just do Windows and Mac desktop apps. That's trailing edge technology at this point.
Some of the better shops don't hesitate to rewrite. Some have systems which intercommunicate by message passing and are designed to be rewritten in sections. (Facebook, works that way internally.) The bigger shops may have one team on the new version and a maintenance team on the old one; a small firm may not be staffed for that.
I want to rewrite my old code at work... But only for one reason: I am a lot better programmer now than 5 years ago. And 5 years ago, I was a lot better than 10 years ago. And in 5 more years, I have no doubt I'll feel the same way.
There's actually one other reason most programmers would like to rewrite what they're working on: They've solved the problem once, and now they understand it.
IMHO, you can't solve a problem properly without solving it twice. Unfortunately, that's just not, in general, tenable in the industry, and so instead we have things like XP, which encourage prototyping and refactoring, which accept that maxim and attempt to allow for it in the process. Unfortunately, *that* requires preeminent design skills, and that's something lacking in your average developer.
Whenever I hit my thumb, I blame the stupid hammer as well.
Or, in other words: a fool with a tool is still a fool.
You can use assembly and have decent code, with clear separation of concerns. Or you can have a 4GL programming tool and still make a mess. Which is exactly why some programmers are 10 times more productive than others.
So where I worked we had ASP+VBScript (supplemented with VB6 COM+ modules running with transactional integrity on an Oracle database) and clean modules, separation of concerns and code that we could easily understand and maintain (even the junior programmers had no trouble getting used to it in a few weeks). We built most of the business apps in the last place I worked on such a design. It still works, is very easy to maintain and transfers cleanly to IIS 8 and Windows 2008. All our database code is in a single (small) module, same as the business layers. Presentation layers is a bit more complex but when transferred to .NET you can just get rid of it altogether because .NET takes over that part. Which is exactly what is happening now, ofcourse.
Don't blame the tools for the lack of ability of most programmers.
Therefore, by the (faulty) logic you're using, you're just a cow with a keyboard - osu-neko (2604)
Don't worry about refuting a zealot, the two technologies have pretty much nothing in common anyway.
Not that I'm a fan of either approach, exactly, but this was just a cheap jab at Microsoft based on prejudice. You should be expecting that around here by now, your user id is low enough.
I have been through a similar project - rewriting a solution that did run under OpenVMS using Basic, Java, C++, C and a bunch of DCL scripts (that confusingly enough for DOS persons have the file extension .COM)
Target environment was Linux and language used was Java 1.6.
My experience when rewriting a legacy system that have a crapload of varying solutions that has evolved during 25 years or so you will find that there is always yet another functionality that nobody told you about - effectively doubling the development time. (This "Multiply estimated time by PI factor" statement isn't that far off.)
And there were some traps involved too - migration of the system had to be seamless for the users as much as possible and with minimal downtime. Since there were over 400 different customers with everything from 1 to 1000 users each involved this was to say the least "tricky". Especially since this was a 24x7 system. The solution was to write a replication protocol that replicated data between the old system and the new. The old system used OpenVMS indexed files while the new system runs a MySQL database and the data structures were different too, which made it necessary to write a replication solution. So when a customer was migrated it was effectively done by setting a flag that redirected them from the old system to the new system and they could continue working.
Of course there were bugs in the beginning, and user errors since the new system did have different functionality and behavior compared to the old. Bot none of them were causing any irrecoverable problems. Invoice printing was delayed, but no major amount of money was lost. The majority of the problems appearing didn't affect the end users at the customers, only the helpdesk service personnel and they were prepared for limitations ahead of time.
The amount of downtime for the system during the two years it has been operational has been very low. And this has given a different concern - too few "problems" with a system is also a problem because tech support will almost forget that it exists.
Specific problems with the application - especially in the beginning has been running out of PermGen space in Java. This at least partly due to design mistakes. But memory leaks that grows over time are very low. And the use of FindBugs has been very useful to trap a lot of errors (potential and real).
What the application does? - It's a management application for short-term lease of telephony at hospitals and similar (almost 400) and other services (a few) which enables and disables phone extensions, assigns numbers, allows instant move of an extension and provides invoicing for the rental and phone usage through processing of CDR:s.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Often a rushed, under-resourced or under-skilled s/w project will congeal into a large, brittle, solid clot,
which is not extendable without breaking things in mysterious prohibitive to fix ways.
Congealment comes from insufficient or ill-conceived architecture, and/or rushed or ignorant ill-fitting extensions or mods or "fixes",
combined with insufficient continuous re-factoring.
This code may be worth keeping on expensive life-support if there are many existing customers depending on it,
but make no mistake. Your codebase is already dead, even if its heart still beats.
So then, if you still need software with similar but slightly updated or extended functionality, you should rewrite,
and in doing so, make sure you get good architecture, take sufficient time to build each part or layer, evaluate the quality of
all third party libraries or frameworks used (on the "volleyball" principle that the weakest member of the team drops the ball
and determines the team's i.e. the system's quality), use continuous refactoring, with technical-risk based work prioritization
(biggest risks dealt with first, always), document the classes and methods
sufficiently, and include unit tests and/or invariants and pre-postconditions, so that there is a lower probability that
further extensions will start congealing into brittle, excess complexity.
If you can succeed at maintaining that discipline without going bankrupt, then it will have been worth it, because the value
of your new software capital asset will be much greater than previously.
Of course you should have done it right the first time, (and should have had management enlightened enough to let you,)
because it would have been much cheaper to do it carefully once, than the punishing expense of the original crappy
development and maintenance plus the rewrite. There IS a valid argument that by the time you let your s/w congeal into
a complex, brittle clot, you are already too late, and you should pull the plug, shed a tear, and walk away.
Where are we going and why are we in a handbasket?
Whether to do The Big Rewrite always boils down to one very simple question: do the expected gains outweigh the expected losses?
Usually, the argument against doing a rewrite boils down to two key points:
Those are certainly valid concerns, and IME it is often true that their impact is underestimated. However, what the doomsayers tend to ignore is all the potential benefits from writing a second version of something from scratch but with the experience gained from doing it once already:
I’m sure some rewrites really are just because a developer wants to write something new instead of working with what is already there, and those are almost always a bad idea IMHO. On the other hand, it can be annoying if someone comes in assuming that this is the only possible motivation for a rewrite, without considering whether there is another justification for the decision.
I'm not a real programmer. I used to play with BASIC back 25 years ago or so and I've fooled around with writing C code for microcontrollers a bit lately but my skills are very limited to say the least. None the less, I was able to parse that regular expression without too much trouble. That leads me to believe that it can't be all that hard for someone who codes for a living to understand it. Still, it would be helpful to spend a minute or two with some helpful commenting.
This ain't rocket surgery.
(Japanese beat-em-ups for example are notorious for vast wodges of copy-and-pasted assembly code that is hard to understand if you can't follow the Japanese comments).
Anyway, the kernel of a 2600 game (which is half the code) is completely unlike a C64 game engine. The game logic would have been easy to port so it would make sense to keep that. And I would hope the graphics and sound were much improved anyway (I quite like pitfall 2 on c64 as it happens).
But "dumping" the code (i.e. reverse engineering a 2600 game from just the ROM) is time consuming especially back then when the tools would have been non-existent. Now we would use a debugging edition of MESS but on a 4.7MHz PC it would be another matter altogether, and a lot of time things were converted "by eye" instead.
I worked for a company that rewrote the same application three times in different technology. 2 time using MS .net tech - aspx, .net desktop, and 3rd with PHP.
The first incarnation was a disaster from a performance/scalability point of view, but we did learn the (surprisingly complex) business requirements very well.
The second incarnation was good, developed quickly, but missed the target market -- nobody wanted a desktop app
The third performed much better than either predecessor, was simpler to maintain, and actually made money... still is.
There was some desire to rewrite it a fourth time, but that has been abandoned in favor of extending the existing system has been the current methodology.
The lesson here is "if it sucks, rewrite it". And more often than not, it is too costly to not rewrite it. Specifically, if the system was not rewritten a third time, the company could not (and would not) exist. As it sits, the product is quite good at what it does. The balance is looking 5 or 10 years forward and looking 1 year forward. If the system you are using won't last 1 year forward, let alone 10, a rewrite may be needed, duh!
The second lesson is "if it is not perfect, fix it". (In the third case it would last a year, but fixing it would maybe make it last 3 or 5 -- it's going on 5 now, and is looking good for another 5)
What this person seems to be faced with is the same thing as that of COBOL ... asp is old tech, nobody really wants to work with it, and it definitely is not perfect. A rewrite is the only sensible thing. (And yes, anything in COBOL should be rewritten too.)
Joel's position contradicts a paper I read years ago in an IEEE software journal that basically said you needed to plan on rewriting your application about every 7 years or have it collapse on you. The logic in the paper was based on two things I've found to be true in the real world. First, the world changes. Individually it's small changes, but looking at it on the half-decade-to-decade scale it can add up to huge differences in what's needed in the software. Second, software isn't infinitely extensible/adaptable. Any software has a basic architecture and world-view, and a limit beyond which it can't be pushed without an exponential increase in the time and effort needed to successfully make the changes. The two combine to mean that at some point it simply becomes technically infeasible to extend and adapt an existing system. The requirements have changed too much and you're having to fight the system trying to make it do, not just what it wasn't designed to do, but what it was actively designed not to do.
Now, business doesn't like this. It doesn't make sense from a business perspective, and it'd be much better to simply keep adapting and extending what's already there. But that ignores the fact that something must be technically feasible before you can even ask whether it makes business sense. If you've got the best idea in the world that'll make the business tons of money while giving you a virtual monopoly in the field and reducing costs by 99%, that basically is from a business standpoint the absolutely ideal thing to do, but it requires the manufacture of say room-temperature superconducting wire by the mile, then it just ain't gonna happen. How desirable it is from a business perspective doesn't matter because it just isn't technically possible at this point in time.
I also liken it to building a 20-story office tower. It's tempting to start with a simple one-story building and slowing add to it until you've got what you want, but the foundation of a one-story building just isn't going to be able to support a 20-story tower. You might be able to get 2 or 3 stories out of it, but at some point you're going to have to tear the whole building down and re-do the very foundations themselves to support the greater weight.