Why continue writing legacy systems?

Question

I have a student position working on some websites for my school. Everything my school does is in VBScript/ASP Classic. I'm a bit confused about something. I can understand that my school as a LOT of code written in VBScript, and that migrating it would be a phenomenal task. But is it just me, or is it kinda stupid that they make us write new programs in vbscript?

I mean, I can understand why they wouldn't want to try to keep up with the latest and greatest technology. And I can understand how much of a pain it would be to maintain a whole bunch of programs written in widely varying programming languages. But at a certain point, don't you have to move to a newer technology for new stuff? Am I missing something here?

Answer 1

It is harder to maintain two separate codebases immediately, although it's much easier in the long run when you can stop supporting the old code.

Otherwise known as "you can have a cookie now, but you won't get dessert later"

Answer 2

From expierience, legacy systems work, whereas those fancy newfangled web 2.0 applications tend to scale badly, have severe security issues and require a lot more maintenance man-hours.

Therefore, if you have the choice between writing legacy system and writing a new system, you would want to go with the legacy system.

Answer 3

It does seem a little ridiculous to make students work with old technology, but it doesn't hurt you to learn something that you may not be learning in school. Learning to adapt to different methodologies and learning how things were done in the past is really good experience.

As Jimmy mentioned above, maintaining two separate codebases is difficult to maintain, it's even more difficult to maintain code written by a temporary (school position) developer who is no longer around.

Answer 4

@Dylan: I agree completely that it's not bad for someone in my position. I'm just a little annoyed with it. :)

But I was really more curious what the ideal solution to this is.

Answer 5

There are a few points to consider when it comes to legacy code:-

• Maintenance - can the other developers (and new developers coming in) maintain the code? They might only be able to program in the language already in use so doing a project in Ruby or Haskell might limit the pool of maintenance engineers to one person - you.
• Interoperability - how well can your solution interact with the rest of the codebase? Can you call functions in the legacy code? Can the legacy code call your functions?
• Support - your school might have a support contract with Microsoft (though actually I think ASP is no longer supported) or a third party vendor limiting your ability to move to a new system.
• Bringing in new developers - if the system you want to move to isn't popular it'll be hard to find developers who are able to do the job meaning the company could get utterly stranded if people left.
• Management Will - unfortunately there's often a degree of reluctance to any change from management which can stand in the way of innovation.
• Stubborn colleagues - you may have some old VBScript holdouts who can't face learning a new system - a lot of the 'other 95%' developers who don't care don't want to make the effort to move to a new system, they may pride themselves on being ASP experts and don't want to lose that.
• Cost - of course, as you mentioned, it's often not worth it to port vast amounts of code. One other thing to consider as Joel Spolsky has highlighted, is that the legacy code contains a lot of information about customer requirements - it incorporates those hacks that get the system working just the way the customers want it, it's been debugged and battle hardened, you're losing a lot moving away from it.

Basically I'd say you have to make a business case for it if you still feel it's the right thing to do, taking all these points in to consideration, find an argument for using language/system x that overcomes them.

Answer 6

It seems in this case, like school is preparing you for the real world where you will find legacy systems. As someone else mentioned, it won't hurt to learn it.

Answer 7

One thing I've learned recently about legacy systems while working on projects for a government agency is you can't just replace (or redesign) legacy systems because too many (100+) other systems depend on it.

To top it off some downstream systems use direct access to the legacy databases. Which means you can't even change/improve the legacy system without breaking something else.

This becomes a software engineering nightmare.The ugly system just gets uglier exponentially.

Answer 8

I'd just say

Yes, you're right. There's nothing wrong... just...

maybe they were afraid that when you left the school (maybe in the next 3 years or whatever) they will be the maintainers.

So it make sense that you write new programs in a language they have so much experience using.

That's what I think.

Answer 9

I find that it's all fuelled from business perspective.

Why should a business change their systems if what they have right now is fully functional and causes no problems? It's the same reason why so many businesses run poorly-designed web pages; why spend money when there are no tangible benefits?

If new technology is worth implementing then you will need to propose this solution with tangible results. For example, if a designer were to tell a client that the small cost of implementing a new CSS-based layout would cut the page size by half, lowering hosting costs, maintainability for current and future staff, with accessibility benefits for all visitors to the website then these tangible benefits could be attractive.

Answer 10

No, you're not missing anything. It's irresponsible to both current and future developers, as well as to the business to continue to write programs in a language that has been declared dead for 7 or 8 years.

Legacy or extensions to existing code are one thing - but continuing to churn out new code because you don't want to take the initial hit in time or money to train your devs in "new" technology is a good way to saddle yourself with an unmaintainable codebase.

Officially, the ASP runtime (ASP.DLL) should be supported until somewhere around 2018. But, that doesn't mean it will be included or an option in Windows/IIS for each version above that. AAMOF, including it in the next Windows version will just increase the support lifetime - which I'm not sure MS wants to do.

At some point, you'll have the aging Windows 2008 server that you have to keep running for your classic ASP code that no one can maintain or understand. It'll be full of Sql injections, poor coding practices, and unpatched vulnerabilities. Then, a rewrite will finally be ordered, but will fail miserably because no one who developed the original code is still around - so nobody knows what it does. Anyone who worked with custom software on NT 4 (or OS/2) way past its prime will know what I refer to.

Continuing to write new code for that platform is a boneheaded move.

Answer 11

@ Mark Brackett: "classic ASP code that no one can maintain or understand. It'll be full of Sql injections, poor coding practices, and unpatched vulnerabilities. Then, a rewrite will finally be ordered, but will fail miserably because no one who developed the original code is still around - so nobody knows what it does."

1) Classic ASP is very easy to read on first glance -- it's virtually syntactic English -- hence its initial popularity with people learning to program. True that more complex applications take a little more time to fully discover, but that's the nature of the work.

2) You make it sound as if bad coding practices and SQL injections are inherent to the language. They are not and I have to wonder why you would choose to spread this misinformation. A good coder can make ASP robust, scaleable and easy to maintain.

3) If the language is no longer common then that means there is more work for contractors with knowledge of legacy systems.

I suspect there will still be mission-critical systems running on VB even in the middle of the next decade for many of the reasons mentioned higher in the thread.

Answer 12

Some organizations do work with the following method

Scary, yes...

I just love despair.com

Answer 13

If you write new programs, they aren't legacy systems. Legacy systems are systems you don't replace, just expand.

Answer 14

Classic ASP can be be pretty clean if you put some effort into it.

True MVC separation is kind of tough/impractical to achieve, but an ASP application doesn't need to be any dirtier than, say, your average PHP application.

I do a lot of maintenance on legacy ASP code and generally I do the following when I have the chance to refactor the portion of the app I'm working on:

1. At the most basic level, just try and get the presentation and business logic separated.
2. For whatever reason, it's like nobody who wrote ASP ever knew that there were actually some OOP features in there. Later versions of ASP supported classes and everything. While VBScript is still not a full OOP language (no inheritance) you can really clean up your code by breaking common functionality out into classes.

ASP can be quite performant if you make use of strategic caching via the Session/Application objects and let the database do most of the heavy lifting. True, you can't scale past a single web box (without session-aware load balancing) if you're making heavy use of caching in those Session/Application objects, but with these strategies a well-designed ASP application can handle millions of data-driven pageviews a day even on a modest modern server.

Don't read this as a defense of ASP; just a survival guide if you're stuck with it. In an ideal world, yeah, we could all ditch our legacy ASP applications for something sexier tomorrow.

Answer 15

Does the new programs written in VBScript perform the tasks being requested? IOW, does it work? If so, why go on to something new? Another way to look at this is to think about what .Net would you switch to:

1. 2002 - 1.0
2. 2003 - 1.1
3. 2005 - 2.0
4. 2008 - 3.5

How long should a technology be out before you can accept it as something that can be used and has the bugs known if not worked out on it? This is just looking at things from the other side which I'm not sure you've thought of the answers to these kinds of questions.