Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

When Rewriting an App Actually Makes Sense

timothy posted more than 4 years ago | from the old-app-was-starting-to-fester dept.

Programming 289

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."

cancel ×


Sorry! There are no comments related to the filter you selected.

And why? (-1, Troll)

SchizoStatic (1413201) | more than 4 years ago | (#32304732)

Why are we pointing this out 10 years later? How is this news?

Re:And why? (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32304756)

Why are we pointing this out 10 years later? How is this news?

because it generates ad views. best way to deal with these stories is to never post in them. less than 10 comments would send a message.

Re:And why? (3, Informative)

XnR'rn (793753) | more than 4 years ago | (#32304776)

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).

6 KB wasted on fucking VIEWSTATE data. (2, Informative)

Anonymous Coward | more than 4 years ago | (#32304870)

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.

Re:6 KB wasted on fucking VIEWSTATE data. (4, Informative)

vlangber (566882) | more than 4 years ago | (#32305008)

Thanks for noticing..

The blog module uses templated controls. When you bind data to a templated control, all that data get's stuffed into the viewstate as default. To fetch the comment content, the template for a comment has this snippet:

<%# Container.CommentContent %>

As default in .Net, a literal control is created for that data. Strangely Microsoft decided to make EnableViewState enabled by default for automatically created controls. The reason the viewstate is so big on that page is because I forgot to put the above snippet in a Literal control with viewstate enabled:
<asp:Literal runat="server" ID="litBlogCommentContent" EnableViewState="false" Text=""></asp:Literal>

I usually check the size of the viewstate, but none of the blogposts I checked had any comments, so I didn't catch it when we created the site. I'll update it as soon as traffic slows down a bit.

Re:6 KB wasted on fucking VIEWSTATE data. (5, Funny)

Rockoon (1252108) | more than 4 years ago | (#32305586)

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.

Are you suggesting a rewrite?

Re:And why? (4, Interesting)

Z00L00K (682162) | more than 4 years ago | (#32306026)

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.

Re:And why? (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32304782)

Frosty pos7t!

Re:And why? (1)

neumayr (819083) | more than 4 years ago | (#32304772)

Just a reading comprehension test.

You fail by the way. Epically.

Re:And why? (1)

Ixitar (153040) | more than 4 years ago | (#32304802)

If you bothered to RTFA, then you would see that this was a posting about a blog entry that is only two days old. It is a discussion about a current rewrite project and their comparison to the blog posting of ten years ago.

Re:And why? (2, Informative)

vlangber (566882) | more than 4 years ago | (#32304812)


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

Re:And why? (3, Insightful)

WrongSizeGlass (838941) | more than 4 years ago | (#32305156)

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".

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 ... until we sell it to someone else who wants "just one little change ...".

Re:And why? (0, Troll)

tomhudson (43916) | more than 4 years ago | (#32305750)

Here' let me help you :-)

  • Mistake # 1: "CMS was developed using Active Server Pages, and consisted of around 80,000 lines of VBScript code"
  • Mistake # 2: "new CMS based on Microsoft .Net 2.0"

    Einstein said something about making the same mistake and expecting different results ...

Re:And why? (1)

fishexe (168879) | more than 4 years ago | (#32305940)

Einstein said something about making the same mistake and expecting different results ...

No he didn't. That was Rita Mae Brown in her book Sudden Death [] , but that never sounds as dramatic or important as claiming it was Einstein.

Re:And why? (2)

The End Of Days (1243248) | more than 4 years ago | (#32306014)

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.

Re:And why? (1)

fishexe (168879) | more than 4 years ago | (#32306302)

Don't worry about refuting a zealot, the two technologies have pretty much nothing in common anyway.

I don't think the difference in technologies is actually relevant to his point. If company X is known to make unreliable products for reasons relating to corporate culture, then "use tech A from company X" and "use tech B from company X" are essentially the same mistake even if tech A and tech B are automobiles and recombinant gene therapies. I think that was more of his point. Having used Visual Studio fairly extensively (in the pre-.Net days) I'm also inclined not to use ASP or .Net based on my experiences even if they bear nothing in common with old VS other than company of origin.

I was just taking issue with the Einstein citation, which bugs me every time I see it because it's so blatantly false and it contributes to spreading ignorance.

Re:And why? (1)

Chris Newton (1711450) | more than 4 years ago | (#32306020)

I'm the author of the blog post.

In that case, would you mind explaining something that is confusing me, please? It sounds like you started the rewrite in early 2005, planned to release in mid 2006, and actually had a finished product in early 2007, which isn't on schedule but is hardly unheard of for a software project. However, you then seem to jump to saying the new version wasn't available across your entire international market until 2010. What happened in between?

Here's my short list (4, Funny)

Anonymous Coward | more than 4 years ago | (#32304762)

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.

Re:Here's my short list (2, Insightful)

beakerMeep (716990) | more than 4 years ago | (#32305036)

See if someone put in a bunch of cryptic RegEx, I would re-write it as If-then-else statements.

For me readability > length of code.

I always find it funny when developers are struggling to fit their code on as few lines as possible. Like the forgot how to scroll or something.

Still, if it was written in Visual Basic, I'd let you take care of it.

Re:Here's my short list (0, Interesting)

Anonymous Coward | more than 4 years ago | (#32305062)

> See if someone put in a bunch of cryptic RegEx, I would re-write it as If-then-else statements.

Rewrite it as regexml! [] ;)

Re:Here's my short list (1)

turgid (580780) | more than 4 years ago | (#32306156)

Sweet baby Jesus and the orphans! Whatever next?

Re:Here's my short list (1, Informative)

rockNme2349 (1414329) | more than 4 years ago | (#32305106)

Do you really think that a thousand if-else statements is more readable than a regex statement. If it takes you one hundred lines of code to test for one condition, then the code becomes less readable, even if each piece makes more sense. RegEx is optimized to test for formatting of a string. This is what it was meant for.

'If Email Address
If (String.RegExMatch("^([a-zA-Z0-9_\-\.]+)@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([a-zA-Z0-9\-]+\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\]?)$")) Then
'Do Stuff
'Do Other Stuff
End If

As proof of the point I'm not going to try and program the same functionality with If-Else statements. If you are using regular expressions correctly you leave a human-readable comment explaining what the regular expression matches.

But I think the important point to take away here, is that we can all agree that VB sucks. =)

RegEx copied from []

What, no plus sign? (2, Informative)

tepples (727027) | more than 4 years ago | (#32305256)

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,, which gets put in the same mailbox as but tagged with "regexlib". See here [] for instance.

Re:What, no plus sign? (1)

rockNme2349 (1414329) | more than 4 years ago | (#32306266)

Sorry about that. I just used that as an example and did a quick search for a code. I agree that I am frustrated when a program doesn't validate, but the entry is to specification. The poster after you posted a link to a proper email regex string.

Re:Here's my short list (4, Informative)

hjf (703092) | more than 4 years ago | (#32305318)

dude, THIS is the regex to validate an email address: []

Re:Here's my short list (1)

TheLink (130905) | more than 4 years ago | (#32305916)

Looks like replacing that with a combination of if-else and regexps would be more readable :)

For those who don't want to follow the link: (1)

fishexe (168879) | more than 4 years ago | (#32306066)

I tried to C&P the link contents in but /. said "Filter error: Please use fewer 'junk' characters."

Re:Here's my short list (0)

Anonymous Coward | more than 4 years ago | (#32305116)

Still, if it was written in Visual Basic, I'd let you take care of it.

I'd definitely do a rewrite. What's the other option? Maintaining an old VB program.

Microsoft had a crack-team of developers working on maintaining an internal management app written in Visual Basic 3 around 1998. The code got jumbled into something vulgar... Something evil. After a couple gallons of whiskey [] , well... we know the rest.

Re:Here's my short list (5, Insightful)

Tanktalus (794810) | more than 4 years ago | (#32305126)

Regarding regexes, I've gone both ways: I've had my developers remove regexes where they were trying to use them, and I've had them add regexes where they were trying too hard to avoid them. Regexes aren't the answer, they're a single tool. You need to use them right. And the /x modifier in Perl helps a lot, allowing you to put useful whitespace and comments in the code (and a regex is code as much as any other language).

As for "as few lines as possible" - you need to do it right. When you span your code over 3 pages, that's not readable anymore. I harp on this with my developers all the time: SCOPE. Scope applies to variables, comments, and functions. The less I need to look at to understand what you're doing, the more likely it is I'm going to understand it. A huge 3-page if-elseif-elseif-else is going to be something I'm not going to understand, as I'll have forgotten all the conditionals by the time I get to the end to know really what scenarios are left - sequential access. A concise regex, on the other hand, is something that I can skim over just by moving my eyes - random access. These concerns aren't just valid for storage media (tape vs DVD/HD). Of course, 40 characters of regex special characters with no whitespace (either horizontal or vertical, preferably both) is generally going to overwhelm most readers, and is going stupid in the other direction.

Yes, readability trumps length of code. But sometimes that means to use a regex (or two or three - why make one big cryptic one when multiple simpler regexes can do the job?). And sometimes, that means avoiding them when what you really want to do is better done by another piece of code.

My favourite new-to-regex example recently has been someone trying to pull apart colon-delimited text with a regex. Woops - there are better language constructs for tokenisation, whether that's strtok in C or it's split in Perl (or better, Text::CSV_XS). Got rid of that regex in a hurry.

Re:Here's my short list (4, Interesting)

Sarten-X (1102295) | more than 4 years ago | (#32305908)

My supervisor is (rightfully) wary of regexes, due to their reputation for unreadability. My favorite solution (in Java): Make a bunch of string constants to match various elements, then assemble those strings together into more strings, which are finally assembled into a single real regex. Sure, it takes about 15 lines for a moderately-complicated regex, but readability is superior to using 15 lines of indexof and substr.

And now, to just bring up a topic that I have a personal interest in:

Nobody knows how to write parsers anymore. I've never seen a recent university CS curriculum that covers parsing with respect to different parser constructs for different languages. Sure, the students learn to load up the chosen XML parsing library and pull in XML, and they learn to take text from stdin, but there's seldom any emphasis on what to do with more screwy formats. Maybe, just maybe, they might get exposed to different languages through a compilers class, but generally not how to process different languages outside of lex/yacc. This bothers me greatly.

Re:Here's my short list (5, Insightful)

Surt (22457) | more than 4 years ago | (#32305440)

You should think about investing in learning tools. Regex is a well documented, well understood, capable feature of all modern languages. How many weeks will you spend debugging / refining your thousands of if/then/else when you could trust years of testing that has been done on regex engines? Your statement reminds me of novices who avoid ?: in favor of if/else because it's 'cryptic'.

Re:Here's my short list (1, Insightful)

Anonymous Coward | more than 4 years ago | (#32305484)

It's a pity that compiler therory is so underused. Not applying Computer Science to write systems leads to lower quality software.

Re:Here's my short list (3, Insightful)

WDot (1286728) | more than 4 years ago | (#32305606)

You could just put in a comment that says "This regex tests for an email address."

I've massaged if-else code into regexes before. Having several if-elses for a piece of data is rickety and (in my opinion) would take more work to rework than a regular expression if the data changed.

Re:Here's my short list (1)

istartedi (132515) | more than 4 years ago | (#32306194)

Bingo! You stole my thunder. Mod parent up Insightful. The solution to the infamous regex problem is to comment them. Your style guide should even have something like, "any regex longer than N characters should have a comment next to it". Developers who live, breathe and eat regex should be mindful that it might look like line noise to the rest of us, or that we might be able to parse it in 15 minutes whereas we can read your comment in 2 seconds.

Re:Here's my short list (5, Funny)

PRMan (959735) | more than 4 years ago | (#32305084)

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 multiple five-to-ten thousand line case statements
1. When it is written in Access basic.

This is why I am currently rewriting everything from scratch in .NET at my company.

Re:Here's my short list (0)

Anonymous Coward | more than 4 years ago | (#32305172)

Still with the MS love eh?

Re:Here's my short list (2, Informative)

Surt (22457) | more than 4 years ago | (#32305448)

That has to be the +5 funniest thing I've read in a month. Thank you, I just about fell out of my chair.

Re:Here's my short list (1)

fishexe (168879) | more than 4 years ago | (#32305966)

3. When it was written in a mid-90s WYSIWIG bastard child of a mid-80s interpreted language.

In what universe is a language developed in 1964 and first marketed by Microsoft in 1975 a "mid-80s interpreted language"?

Re:Here's my short list (1)

Provocateur (133110) | more than 4 years ago | (#32306206)


For the noobs, thats What-You-See-Is-What-I-Got, normally after some software that was promised to deliver ABC gets XYZ instead, after paying M thousand dollars, and is in the process of being reported to upper Management.

Missing the point (1, Insightful)

Anonymous Coward | more than 4 years ago | (#32304790)

Joel was pointing out a case where an application was rewritten IN THE SAME LANGUAGE. These guys rewrote their application to move it to a new language / platform. It's not a REWRITE, it's a PORT.

Re:Missing the point (4, Informative)

mikael_j (106439) | more than 4 years ago | (#32304800)

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).

Re:Missing the point (1)

mwvdlee (775178) | more than 4 years ago | (#32305112)

Besides, it's not like a clean-room implementation when you do a rewrite.
Sure, the architecture and language may be different, but a lot of the old code would likely still be used as "inspiration".

Re:Missing the point (4, Interesting)

commodore64_love (1445365) | more than 4 years ago | (#32305216)

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

Re:Missing the point (2, Insightful)

mikael_j (106439) | more than 4 years ago | (#32305244)

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).

Re:Missing the point (4, Insightful)

St.Creed (853824) | more than 4 years ago | (#32305904)

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.

Re:Missing the point (1)

mikael_j (106439) | more than 4 years ago | (#32306252)

I didn't blame the tools and since asking you to re-read my post will probably do nothing I'll try to explain it.

Certain tools are more dangerous than others. Few people can cause large-scale damage with a screwdriver but most people can do serious damage with a few sticks of dynamite even though both can be equally useful for different purposes. A bit extreme perhaps but the point is that VBScript is not a very good language for apps that you wish to keep maintaining and adding features to, add into this the fact that it is often mandated from above ("You will use this dynamite when erecting the wall, I don't care if you think a hammer is a better tool, I'm the CxO DAMNIT!"). These business applications also tend to be built according to specifications which are missing crucial features and when upper management realize that features are missing they feel that "it's just a few lines of code" so they allocate one or two programmers to add the feature with a three day deadline even though properly implementing the feature would require more programmers several weeks in order to properly restructure the code, instead you end up with ugly hacks. After a few years this codebase begins to look like a building held together by twine, duct tape and the occasional 2-by-4 hammered in place just to keep a wall from falling down. Now when you're working with a codebase like this it tends to get to the point where you end up accepting that things will break when you fix other things because all the different parts seem to be connected in the strangest way ("Why does the foo module crash when we fix the divide by zero bug in the bar module?" "Oh yeah, I think a couple of years ago someone decided to use part of the bar module for some of the foo processing to check if the input data was erronous").

Basically, the tool may not be useless but when coupled with an environment in which the tool is only being used "because I say so" and there is never enough time to do stuff properly certain tools can definitely be more dangerous than others (IMO one of the advantages of object oriented languages and designs is that with a proper base design it is a lot easier to keep parts of an application separate from each other which makes rewriting only part of the app easier).

An example of a typical "VBScript horror" is the "include-o-mania" I mentioned, this was also common with a lot of non-OO PHP code. Basically you'd have programmers put dozens of include statements in their code in the fashion I detailed above which made the code close to unreadable. While the language may not have outright encouraged this it sure made it tempting.

Porting games written in assembly (1)

tepples (727027) | more than 4 years ago | (#32305338)

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."

But then how would one have ported a 2600 game to the ZX Spectrum, ColecoVision, MSX, or Sega Master System, all of which use a Zilog clone of Intel's 8080 CPU?

Sometimes to move forward (3, Interesting)

rxan (1424721) | more than 4 years ago | (#32304818)

you must stop looking backward.

Re:Sometimes to move forward (4, Interesting)

dotancohen (1015143) | more than 4 years ago | (#32305612)

you must stop looking backward.

And loose all your users. They are in your 'Backwards" direction.

I have filed or triaged well over 1000 bugs for KDE since KDE 4 came out. Forget about the missing features from KDE 3 to KDE 4, they don't care about breaking compatibility from KDE 4.n to KDE 4.n+1. Even Kaddressbook, one of the core KDE apps, had severe functionality loss from KDE 4.3 to KDE 4.4. Amarok, Koffice, and other lose severe core functionality when their "new versions" were actually "technology previews" with dot-oh version numbers.

Re:Sometimes to move forward (2, Interesting)

Anonymous Coward | more than 4 years ago | (#32305922)

The new Amarok just blows period. They could have actually done mockups and put it to a vote using a poll on their site, produced two or three demo UIs with only basic functionality implemented, put it to another vote and gone with that. In the end, the devs really just wanted to reinvent the UI because table views are so 2001.

The result is slow as a pig, ugly and more confusing then the old one.

Hell, I hate it so much that I now just use a Konsole instance running MPlayer instead. mplayer album/*/*.flac FTW.

Re:Sometimes to move forward (0)

Anonymous Coward | more than 4 years ago | (#32306118)

Something like this perhaps? []

some other scenarios (1)

ascari (1400977) | more than 4 years ago | (#32304830)

First, I suspect everyone agrees that rewriting an app rarely makes sense for a small company with limited R&D budget like Spolsky's. (Better spend whatever money there is on comfortable chairs and parties for the summer interns, right?)

But if you have the budget and market share you have some good reasons to rewrite from scratch:

1) You can generate fresh revenue by forcing your users to upgrade due to icompatibility issues.

2) You can ease the burden of backward compatibility by creating a new baseline.

3) You can strengthen your old brand by coming out with a "new coke" that is so crappy that everybody will clamor for the old stuff.

4) There might be (unforeseen) technical or architectural issues that make a rewrite a sensible option.

Re:some other scenarios (1)

Quarters (18322) | more than 4 years ago | (#32305516)

Maybe you should read Spolsky's 2000 article. He doesn't use his small company as an example. He uses the rewrite trials and failures of such other 'small' companies as Microsoft, Borland, and Netscape.

One some /. er commented on Spolksky... (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32304838)

One day here on /. someone commented that Joel Spolsky approximately was approximately saying something interesting as often as sunlight shined in his a*** and I feel this way too.

Kudos to him for, for it is spam free (but the uptime is pathetic and the realization overall really sucks balls, and I've got 3.5 K rep there so I know the sh*t) and definitely took up.

But most of his writing are downright bogus : his lame article on Unicode was really some "oh oh I get it" moment except that it was full of mistake and didn't "get it" until he engaged in revisionist article-editing history.

The non-sense advice to "never rewrite anything from scratch" is directly inherited from the oh so wonderfull "MS mentality" that consist in "upgrading" bloated insecure piece of mediocre software.

Where would Apple be now if they didn't make the major shift to Un*x? (btw, Apple's market cap recently passed MS, don't know where they're at now, but they did pass MS not long ago).

To me the dude's a joke. But kudos for I don't like Spolsky. I don't think he's smart. I don't think he knows much (he pretty much knows jack sh!t besides the MS stack idiosynchrasies) overall. But respect on is free from spam and free from intrusive adds (there are still adds, but they're not bad). This should be an example for a great many spam
infested and add-infested websites: die "expert exchange", die non-moderated spam-ridden Usenet newsgroups.

But what Joel Spolsky and his Jeff Atwood blog about? Bullsh!t of the "oh oh, I get it now" type, except that they really don't get it.

Re:One some /. er commented on Spolksky... (0)

Anonymous Coward | more than 4 years ago | (#32305802)

I agree. I don't know why slashdorks (or anyone else) sucks his e-cock. He's a former MS mid-level manager. If anything he writes strikes you as intelligent, insightful, or advice worth following, you're probably totally lacking in common sense or real world experience.

Re:One some /. er commented on Spolksky... (1)

Sarten-X (1102295) | more than 4 years ago | (#32305944)

Mostly agreed, and I'll sign my name to it.

Spolsky's got some decent ideas, and knows a lot about what he talks about, but his idea of "good" and "bad" makes me cringe. He's one of those folks who's built up a following on what little they had to talk about, then ceased to think further. Now (and for several years), he writes about half-baked lists of do's-and-don'ts that never even come close to covering exceptions.

Pick opensource (0)

Anonymous Coward | more than 4 years ago | (#32304846)

You take the plunge and do a full rewrite from ASP ... to .Net 2.0?

That was a golden opportunity to move to an opensource stack. If it had been PHP for example, the complete rewrite probably won't have been necessary. Just replace the depreciated functions and constructs as required.

(PHP is just an example. No language flaming idiots please.)

Re:Pick opensource (1)

vlangber (566882) | more than 4 years ago | (#32305320)

The rewrite was mostly based on problems with the underlying design, not the platform switch. When we had decided to rewrite it from scratch, .Net was chosen as the new platform.

If you think the effort needed to make a new web content management system that can compete successfully with established players like SiteCore, EPiServer, Alterian, Ektron and Kentico (basically the mid-range platforms and products as defined by CMS Watch ) is a matter of changing to PHP and replacing functions, you're insane.

Re:Pick opensource (1, Insightful)

Anonymous Coward | more than 4 years ago | (#32305550)

(PHP is just an example. No language flaming idiots please.)

Your entire post is equivalent to a language flaming post, you idiot.

Why should they go with an open source stack? If they're MS-oriented folks, they have more in house experience with those products and they'll be easier, faster, and simpler for them to use.

I'd personally have ported to something multi-platform (no, sorry, mono doesn't count), but that's mostly my technical background and the fact that I prefer to be vendor independent. Other people or organizations without my particular history and concerns can, and do, come up with equally valid solutions to things that differ from mine.

Ugh (4, Interesting)

drinkypoo (153816) | more than 4 years ago | (#32304850)

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.

Re:Ugh (1)

morgan_greywolf (835522) | more than 4 years ago | (#32304980)

But Apple did rebuild their GUI shell, application APIs, etc. from scratch. Sure the underlying OS is based on legacy code stretching back into, really, the 1960s (BSD itself was, after all, based on AT&T's Unix), but the GUI and application APIs were totally new.

Re:Ugh (5, Interesting)

drinkypoo (153816) | more than 4 years ago | (#32305076)

But Apple did rebuild their GUI shell, application APIs, etc. from scratch. Sure the underlying OS is based on legacy code stretching back into, really, the 1960s (BSD itself was, after all, based on AT&T's Unix), but the GUI and application APIs were totally new.

That is totally and completely false [] . "Cocoa [] is one of Apple Inc.'s native object-oriented application program environments for the Mac OS X operating system. It is one of five major APIs available for Mac OS X; the others are Carbon, POSIX (for the BSD environment), X11 and Java. [...] Cocoa is the continuation of several frameworks (primarily the App Kit and Foundation Kit) from the NeXTSTEP and OPENSTEP programming environments developed by NeXT in the 1980s and 1990s." "Carbon descends from the Toolbox [] , and as such, is composed of "Managers". Each Manager is a functionally-related API, defining sets of data structures and functions to manipulate them. Managers are often interdependent or layered.
Newer parts of Carbon tend to be much more object-oriented in their conception, most of them based on Core Foundation. Some Managers, such as the HIView Manager (a superset of the Control Manager), are implemented in C++, but Carbon remains a C API." And I should HARDLY need to touch on POSIX, X11, or Java, the former two of which were already functions of NeXTStep, and the latter of which was not invented at Apple.

There is NOTHING in OSX which can reasonably be believed to have been invented (in any sense of the word) for OSX! Period, the end. ALL portions of OSX contain legacy code, from the microkernel to the presentation layer. They didn't go from Display Postscript to Display PDF because it was easy, they did it because they couldn't just throw over Display Postscript and be able to utilize existing GUI code. They didn't throw out the GUI and replace it, they replaced the engine under it, then made it work on that engine. The appearance of the GUI is still customizable, as it was under NeXTStep, by mangling the images it's made of.

Re:Ugh (1)

Suiggy (1544213) | more than 4 years ago | (#32305042)

A better example of complete rewrites would be iterations on game engines where vast swathes of legacy code get thrown out and are completely rewritten from scratch.

Re:Ugh (0)

Anonymous Coward | more than 4 years ago | (#32305086)

Unfortunately the author goes on to display his ignorance before this is all over:

The discussion is about code reuse and whether or not to rewrite applications. It is not about how much code Apple reused in one of the examples... or how much you know about Apple's kernel. Try commenting on the points TFA was making. Like most here you are focusing and complaining on details that are not germane to the discussion. So what if he is off a little in one point (as stated elsewhere, Apple did rewrite most if not all of the GUI and APIs, if not the OS kernel)?

Re:Ugh (2, Insightful)

jeti (105266) | more than 4 years ago | (#32305098)

The original rewrite of MacOS was Copland, which used up Apples development resources for five years before it was cancelled. []

Re:Ugh (3, Insightful)

drinkypoo (153816) | more than 4 years ago | (#32305190)

The original rewrite of MacOS was Copland, which used up Apples development resources for five years before it was cancelled.

Yeah, I remember that, it's what convinced me to stop being a Mac user. I had the INIT or CDEV or whatever that made your MacOS look like Copland. Then they cancelled it and brought out another shitty MacOS, and I ran like hell and never looked back. All the years from System 7 through System 9 were sad, abusive times to be an Apple customer. They kept bringing out inadequate hardware at astounding prices and almost spent all their cachet. Another year or two and they wouldn't have had enough fans left to float OSX.

Re:Ugh (1)

noidentity (188756) | more than 4 years ago | (#32305268)

And Mac OS X isn't an application, either, so he's doubly wrong. (BTW, your subject line is uninformative)

There are actually a few good reasons (4, Interesting)

Opportunist (166417) | more than 4 years ago | (#32304864)

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.

Re:There are actually a few good reasons (2, Interesting)

jonwil (467024) | more than 4 years ago | (#32305044)

Often the problem is that there are things that should be rewritten (either whole apps or specific sections of code) but no-one is willing to green-light such a rewrite even though the rewrite will take less time than bolting hack after hack on top of the old system.

Re:There are actually a few good reasons (1)

coryking (104614) | more than 4 years ago | (#32305724)

even though the rewrite will take less time than bolting hack after hack on top of the old system

Often the problem is we developers are wildly optimistic in our estimates of how long such a venture might actually take. Especially if we are talking about code we dont know much about. Until we really get to know the problem domain, it all sounds so easy :-)

In my opinion, what Joel really is against is a wholesale "drop everything you are working on and rewrite the entire app". From hard-won experience, he is right... When you drop everything you are working on, you stop pushing out exciting new features to your customers. Said customers get pissy that nothing seems to be changing and start to look elseware for their software fix.

Doesn't matter if the product is internal or something for the public. If it is internal, the teams who use your product start getting pissy with your team and look to out you. If it is external, your customers look to buying or using other competing products (like jumping from Netscape to IE5 and IE6).

If the old code really does suck (and if it is a combo of classic ASP and vbscript, it really does suck), the best route is to look at how to migrate your infrastructure a bit at a time to a better one.

For example, when you improve the admin site that uses ASP/vbscript, all new code has to use javascript and .net 4. Then hack the load balancer so that the requests get routed either to the legacy platform or the new platform.

Basically when you add a new feature or improve an existing one you port it to the new platform. That way you still maintain excitement by pushing out cool things while in the background you are improving your codebase. Yeah it might take a bit more time to crank out each new feature or fix, but at least you are cranking out bits and pieces instead of nothing for 5 years.

Course, this is my opinion. Yours may very.

Trademark (0)

Anonymous Coward | more than 4 years ago | (#32304894)

"App" is Trademark(TM) to App le computer inc. If you try to use it for your own stuff not app rove by app le expect to receive in iNjunction.

The best break all the rules (1)

angryphase (766302) | more than 4 years ago | (#32304914)

It's a bad idea to roll your own. In fact, Joel Spolsky (Who's comment this blog post is the basis of) even went on to explain that in some cases, that's a complete lie ( [] )

So really "It's a bad idea to roll your own, except when it's a good idea".

There are times for a rewrite and port. (4, Insightful)

AnonymousClown (1788472) | more than 4 years ago | (#32304954)

The article was interesting in how they made their decision and I don't think it was necessarily a bad decision - assuming their assessment of the old version was correct. The process looked like it broke down in the design and planning phases. The article didn't go into detail on the design and planning; which kind of leads me to believe that may have tried to do the "superstar" programmer thing and rewrite it over a weekend. Anyone whose been in development long enough has heard the "he coded it over the weekend"stories and the programmer "street cred" it gave - at least back then.

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.

Re:There are times for a rewrite and port. (1)

fishexe (168879) | more than 4 years ago | (#32306024)

Just do these basica [] things and it'll work out.

Fixed that for you.

The exceptions Joel should have included (4, Interesting)

michaelmalak (91262) | more than 4 years ago | (#32304994)

Joel's article implicitly had some tunnel vision because it did not state any exceptions. The general rule of thumb as to when to rewrite an application are:
  • Change in platform paradigm. This has happened five times thus far (post-ENIAC):
    1. Mainframe to MS-DOS
    2. MS-DOS to Client/Server
    3. Client/Server to Windows
    4. Windows to Web
    5. Web to mobile
  • Vast improvement in software technology (and you have a software project/product that requires significant expansion or improvement), such as:
    1. Machine code to Assembly
    2. Assembly to spaghetti
    3. Spaghetti to structured
    4. Structured to OO
    5. Proprietary unsupported language for obsolete sluggish database to SQL

Magic Online? (1)

thomasw_lrd (1203850) | more than 4 years ago | (#32305032)

I thought the article was about Wizards of the Coast and their horrible foray into online gaming.

Treat a rewrite as a new product (1)

davidwr (791652) | more than 4 years ago | (#32305068)

How long did it take you to bring "version 1.0" from concept to new product to the "2.0" version that the market considered useful and bug-free?

Use that as a starting point for how long it will take to do a rewrite, then adjust up or down for things like:

*how many features will be in the rewrite that weren't in the 2.0 version (e.g. a rewrite of MS Windows today would take much more effort than writing MS Windows 3.1).
*time already invested in internal projects that will be used in the rewrite version (e.g. experience writing the NeXT OS greatly reduced the time it took to write MacOS X 10.0).
*other factors too numerous to list here.

Sometimes it makes sense to treat your pre-release product as a throwaway prototype rewrite BEFORE you go to market. Yes, this means starting the testing cycle all over again, but it gives you an opportunity to correct design flaws or maintainability-killing bugs while you still have a chance. Unfortunately, sometimes the competitive marketplace forces you to go to market with what you have, a bug-ridden, nearly impossible-to-fix product that will make a little money so you can have the funds to redo it from scratch for version 2.0, er, version "II, 1.0."

Re:Treat a rewrite as a new product (1)

drinkypoo (153816) | more than 4 years ago | (#32305300)

*time already invested in internal projects that will be used in the rewrite version (e.g. experience writing the NeXT OS greatly reduced the time it took to write MacOS X 10.0).

As I covered elsewhere [] , OSX is just the latest revision of NeXTStep. I did make ONE error in that comment: there is one thing in OSX that didn't come with NeXTStep or come from legacy MacOS (like the toolbox code) in some form: Grand Central Dispatch. That's not a central API, it's totally optional, but it is an exception to what I said, so it's fair to mention it. It's not the experience that made NeXTStep [] 3.4, er I mean OSX 10.1 so quick/easy to release, it's the fact that it's made of more legacy code than new stuff. It is simply not a useful example when talking about complete rewrites since nothing that came with OSX originally was completely rewritten, and by nothing I mean absolutely nothing. Not Cocoa, not Carbon, nothing. This statement is not intended to take anything away from it as an Operating System, only to correct this revisionist view of history that you and others seem to have about OSX.

Re:Treat a rewrite as a new product (1)

larry bagina (561269) | more than 4 years ago | (#32306028)

Quartz, Core Graphics, Core Animation, Core Foundation, etc.

Why I want to rewrite (0)

Aladrin (926209) | more than 4 years ago | (#32305072)

The article says that any developer will tell you that they want to rewrite the code they are working on. It claims it's because it is harder to 'read' code than 'write' it.

I disagree.

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.

Code I write today is cleaner, easier to read, more efficient, and easier to work with for new projects.

Re:Why I want to rewrite (4, Interesting)

Abcd1234 (188840) | more than 4 years ago | (#32305662)

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.

Only 80000 lines... (1)

AdamInParadise (257888) | more than 4 years ago | (#32305102)

... and most of them run in a controlled environment (server-side). So lots of Joel's advice is not going to apply.
Then they have the balls of comparing their move to the transition from Mac OS 9 to Mac OS X!
In the end, while their story is interesting, it adds really little value to the "Rewrite/No Rewrite" debate.

Joel's article needs an update... (1)

MoHaG (1002926) | more than 4 years ago | (#32305124)

Netscape's rewrite might have cost them market-share at the time, but Internet Explorer is back at trying to catch up with Firefox, which might be easier to extend because of that newer codebase...

(And from when I forgot to log in: And WTF is up with the captcha? It doesn't change, even when it is obviously unreadable (A 8 / a / 0 with a line through is hard to make out with 2 guesses))

Re:Joel's article needs an update... (1)

Rockoon (1252108) | more than 4 years ago | (#32305570)

Actually it seems to me that Firefox is right back where Netscape was...

...too bloated to fix. Where its not bloated, it seems to suffer from Fancy Design Syndrome.

Simple rule... (1)

McNihil (612243) | more than 4 years ago | (#32305148)

rewrite ONLY if it means it yields less lines of code to maintain with the same functionality. Use whatever language necessary to keep the length of code to a minimum.

If the code doesn;t look as if it has been refactored even once... junk it.

So very much better than the Sausage Machine (1)

lawrence.a.sim (564242) | more than 4 years ago | (#32305162)

We had one of our apps Sausage Machined, very sad... Translate one chunck of code into worse code in another language and different platform. A complete from scratch re-write would have been SO much cleaner (and maintainable).

One typical problem (1)

jeti (105266) | more than 4 years ago | (#32305164)

Rewriting an application can work if the developers know what they're doing. However, these rewrites are often side projects. If considerably more resources are spent to extend the original application, the rewrite will be behind until it gets cancelled. On the other hand, a rewrite is always a risk and betting your company on it is insane. In most cases it's safer to refactor the original implementation, even if it's more work than starting from scratch.

Here's a good example (1)

Low Ranked Craig (1327799) | more than 4 years ago | (#32305260)

When your "enterprise" ERP application is written in VB6 with a roll your own alternative to ADO, half your business logic is in stored procedures that can be 5,000 lines long and 30% to 40% of your code was written to spec B.

5 points if you can name that product

Re:Here's a good example (1)

spells (203251) | more than 4 years ago | (#32305964)


Don't pay so much attention to Joel Spolsky. (5, Interesting)

Animats (122034) | more than 4 years ago | (#32305298)

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.

Re:Don't pay so much attention to Joel Spolsky. (3, Interesting)

kmike (31752) | more than 4 years ago | (#32305898)

Yes, I never understood why so many pay attention to Joel's inflammatory rants.

I don't even want to start on his company's product (Fogbugz). Seriously, ASP/VBScript translated to PHP? And then inventing a new programming language just for a web app with ability to output in several other languages? Ugh.

Re:Don't pay so much attention to Joel Spolsky. (2, Insightful)

Vellmont (569020) | more than 4 years ago | (#32306296)

Yes, I never understood why so many pay attention to Joel's inflammatory rants.

Partly because he's a fairly good writer, and partly because he seems to offer simple solutions to the larger problems of software, and partly because he's right at least some of the time.

I DO think he's just dead wrong on this issue though. In my experience starting from scratch is something that should be very carefully considered, but rejecting it outright on general principles is wrong. I really don't care much about his bona-fides or how successful he's been. People with big impressive resumes working for some fashional part of the industry writing in the cool language of the day can say some really stupid things.

The problem starts when people start believing someone PURELY on the reputation alone, and turn their brain off. There's a few figures like that that gain a lot of hero status. Joel is one of them, Bernstein is another. A lot of people actually don't like thinking very much, and prefer ANSWERS to hard questions (even if they're the wrong answers). The cult figures in software offer these answers, defend them to the death, and attract people with similar attitudes. It winds up looking like these guys have large followings, when in reality they have minuscule, but extremely dedicated and vocal ones.

Summary ignores the single most important quote. (1, Insightful)

Anonymous Coward | more than 4 years ago | (#32305348)

From the article: "we experienced a lot of the hardship and trouble that he talks about, so we can easily see how many companies could get into trouble during such a process. If the board of directors had known in 2005 that we wouldn't be ready to re-launch in the international market until 2010, I doubt we would have gotten the green light for the project. "

And that says it all. In this case, it worked out; but it was quite possible that during that 5 year window with no releases that a new competitor could have emerged with a few new features, and these guys wouldn't have been able to respond since their code rewrite was still years away from being ready. Everytime a customer said "We'd love to buy your product but your competitors have feature X and you don't", these guys lost a sale since they couldn't counter "well, we have a new release of our coming out in a couple months with new features". Spending five years rewriting code from scratch instead of incrementally improving the existing code and doing a new release every year could quite possible have caused a company to run out of money and go out of business as customers moved on to the competition.

The reason to iteratively refactor your existing code rather than rewriting it from scratch isn't cause it produces a better end result -- it's cause iterative improvements allow you to periodically stop and ship a release every six months or a year (with one or two new features and a slightly cleaner code base) and then continue refactoring again for the next release. But rewriting from scratch means you can't ship a release for (in this case) ***5 years***. And the world may well have forgotten you by then.

Re:Summary ignores the single most important quote (1)

fishexe (168879) | more than 4 years ago | (#32306050)

To paraphrase your post in the words of Steve Jobs [] :

Real artists ship.

Similar Experience (1)

eulernet (1132389) | more than 4 years ago | (#32305368)

We faced the same challenge at our company recently.

My company publishes a CMS for specialized niches.
The product started around 2002, and we developed it without real direction, since we added functionalities as we needed them.
The first years were great, since we were the only ones to release such a tool, but some concurrents emerged after a few years, proposing a much cheaper alternative.

As we built the project without long-term view, adding new functionalities took more and more time, since the codebase was hard to maintain (for information, we mainly use VB.NET with a lot of XSLT).

Two years ago, we realized that the interface could be improved for the customers, but it was impossible to do it with a reasonable amount of effort.
Thus, the CEO decided to start a new product, and we used an interesting approach: the customers approach (or technically, BDD, behaviour driven development).

The idea is to describe scenarios and implement them one after another, using agile methodologies.
For this kind of approach, you really need to hear about your customers, and write the scenarios that they need, and it's obviously impossible when you start your company.

The project is now radically different, but not yet released, since it's really a subset of the previous project.

What we discovered is that we needed to maintain the old codebase, because our consultants still used it, and it is difficult to sell the new project, since it's really different.

So I would suggest that if you want to totally rewrite your codebase, you need to place a few resources on maintaining the original project, since it won't probably die before a long time...

Old crappy code (1)

Frankie70 (803801) | more than 4 years ago | (#32306256)

That old crappy code has undecipherable bug fixes for 100's of obscure difficult to reproduce bugs. Many of them which could be hit only under really strange customer usage scenarios & which tooks days to reproduce, days to fix & many more days to fix whatever the fixes broke.

So unless you original software fully automated testsuites covering every functionality & you have added a bug fix verification test for each bug which has been fixed since then, do not rewrite something from scratch.

when rewriting, go wider, not narrower (1)

catmistake (814204) | more than 4 years ago | (#32306290)

TFA says they released their software 2006, and expected it to be in use for at least 10 years. I realize the benefits of DotNET, quick development, compatible with the most popular platform. I don't think there was any mistake in starting from scratch, in and of itself. And I don't think the downside of developing in DotNET has even materialized yet, and so long as the product pays for itself before it becomes obsolete, I think they're OK. But I have a feeling that, and I admit my prejudice, that the devs were blind to any other possible solution because of Microsoft. DotNET was they're ONLY option... never even considered that it was, never considered anything else... never considered. If a mistake was made, that was it... and again, it may not make any difference because the product may still be successful even with lock in. But there is no doubt they're software will not be a major player in 2016 having been developed in DotNET.

Rewrite if existing s/w congeals (2, Insightful)

presidenteloco (659168) | more than 4 years ago | (#32306306)

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.

Code doesn't rust, but skill does improve (1)

Mike216 (1808602) | more than 4 years ago | (#32306308)

I've always thought his article on this topic skipped over dealing with the fact that rarely, if ever, is code so perfect that it wasn't at least a little 'rusty' in the first place. There's only so far you can go with refactoring before it would just be more efficient to start from scratch.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?