[RESOLVED] Philosophy of Permanence

A friend of mine has been urging me to take on a project for him at work. His project uses a program that was written in VB6 (or even VB5) more than a decade ago. After getting a hint about its location, I delved into a dusty removable HD, and found the source code. My friend is concerned that this program, written in such an old language, may fail sometime in the next few years. It may fail because of hardware changes, OS changes, requirement changes, or something like that. Due to the archaic nature, it would be hard to simply tweak the existing code, and all the people who were associated with that code are long gone.

Frankly, I was interested in taking this on for purely selfish reasons. I know these people, we've worked together on other projects, we're friends outside of work, and the project would also allow me to stick my thumb in some eyes that have earned it. So, it would be an enjoyable project to take on. It wouldn't be terribly challenging, though, as there really isn't any inovation to add, but it would allow me to be fully immersed for a few months.

However, I fear that I shouldn't be so supportive of this idea. My friend is mostly concerned that the old project is nearing the end of its life, and is no longer maintainable. That may well be true, but it hasn't died yet, it is fully functional, and after a bit of thought, I am thinking that it is a false promise to rewrite it in .NET just to move it into a modern age.

My thinking is that VB1-3 were one language, while VB4-6 were quite a bit different (I have heard this, but I never used VB1-3, so that's second hand only). If that is the case, then VB4 was released in 1995, marking the birth of that language, and VB6 was released in 1998, marking the end of that language. Plenty of code still remains in that language, but it is fading out slowly, and would die fast if the runtimes were no longer included in the Windows OS. VB.NET2002 was followed by 2003, but then it was changed considerably with the release of 2005, and I would say that 2005, 2008, and 2010 are all interchangeable, while the earlier .NET version are not so much. I would say that because virtually any project written in 2005 can be opened in 2010 without any problem, but that can't be said for a project written in 2003, which used a different startup model.

So, if VB1-3 had a run of four years, VB4-6 had a run of seven years (until VB6 was replaced by .NET and MS stated that there would never be a VB7), the early .NET had a run of three years, and the modern .NET has been around for 5 years and counting, is there any real hope for the stability my friend is looking for? If I were to rewrite his VB6 program in .NET2010 to take advantage of the most modern version, then it is highly likely that 10 years from now, whoever is in that position will be making the same case that the program needs to be rewritten in whatever is the going thing at that time.

The Y2K crisis came about because COBOL developers in the 70s and 80s couldn't believe their software was still being used 20 years down the road. These days, writing in VB, there is a window of less than 10 years before the ability to maintain the software becomes a legacy task using tools that might be hard to obtain and not well known. It seems like the only way to create continuity is to write in some language like C/C++, which is slower for development, but also far more stable. Even that may not work, though, because a change to the OS could make even programs written in those languages unsupported.

So after that long ramble, here's the question: Is it justifiable to migrate a fully functional program into the current flavor of .NET knowing full well that the current flavor of .NET is going to be yesterdays news in a few years, or is it better to leave a working program as it is because the replacement will be, itself, archaic in a decade?

Well, given that Microsoft seem to bring a new version of every two years or so it is a wonder you don't have to keep rewriting the same code every two years just to keep up with new technology.

I wouldn't rewrite it for the sake of rewriting it. Which is what it sounds like in this case. I'd only worry about re-writing it if there was a compelling reason to do so, like adding a feature... or fixing a bug... or if VB6 will no longer run on some given platform.

-tg

I'd have to agree with techgnome. Features and bug fixing are the only justifications for re-writing the app. I assume new features will bring more income and I also assume that re-writing will make bug fixing easier (although that's certainly not guaranteed) Otherwise, I'd just leave it be - the only thing I'd probably do is create a dedicated dev/build VM just for it, document the build process some (if that's relevant) and make sure there's a big note informing future supporters that the VM is there.

There is no income, just fish. It's always about fish with me.

I'm a bit surprised by these responses. They are exactly the position I was coming around to. I suppose the bigger question, the one that is more philosophical rather than practical, is: Does this ever end? And: Is it speeding up?

When I think back on the brief history of computer programming, it seems like there was a time in the 70s and 80s when you could write something and be fairly sure that they would still be functional for decades, so maintenance was a cost that might conceivably go away. Now, if you write in most languages, it is fairly likely that the language will go away, or be radically changed, within a decade, which is what was pushing this rewrite. If I wrote in some standardized language, such as C/C++, there would be a reasonable expectation that the language wouldn't really change in the forseeable future, but if the OS changed, and the API changed, then it may be that the language wouldn't actually run....unless it included its own OS.

It seems like we may be creating our own job security. The only thing that is constant is change, and we may always be trying to surf the flood.

Sometimes it's hard to justify an upgrade based on technology alone, and I think that's a major part of it. Back in early 2004, we installed a rather large cheque processing system based on .Net 1.0. After a mandatory upgrade to 1.1, it's still running and I don't see an upgrade happening any time soon. The customer flatly rejected a free upgrade we offered to 3.5 in the past - they just couldn't justify going through a testing cycle for something that would offer them no new features but would only make their IT guys feel warm and fuzzy.

Quote:

---

Originally Posted by Shaggy Hiker

When I think back on the brief history of computer programming, it seems like there was a time in the 70s and 80s when you could write something and be fairly sure that they would still be functional for decades, so maintenance was a cost that might conceivably go away. Now, if you write in most languages, it is fairly likely that the language will go away, or be radically changed, within a decade, which is what was pushing this rewrite. If I wrote in some standardized language, such as C/C++, there would be a reasonable expectation that the language wouldn't really change in the forseeable future, but if the OS changed, and the API changed, then it may be that the language wouldn't actually run....unless it included its own OS.

---

If you mean going from one framework to another say COM to .NET then that is the only time I would think about rewriting a whole project. That being said it is a bit of a shame to have to upgrade the legacy code when it becomes a urgency to do so. I'm not sure about you but I am stuck on programming in VB6 and will sort of sad when there comes a time when none of my legacy VB6 programs work anymore because of changes with the operating system, etc. Yeah, I know Vista and Windows 7, and also it looks like Windows 8 as well will support VB6 programs, however there has to be a time when VB6 support on OS's will finally come to an end.

Quote:

---

Originally Posted by Shaggy Hiker

The Y2K crisis came about because COBOL developers in the 70s and 80s couldn't believe their software was still being used 20 years down the road. These days, writing in VB, there is a window of less than 10 years before the ability to maintain the software becomes a legacy task using tools that might be hard to obtain and not well known. It seems like the only way to create continuity is to write in some language like C/C++, which is slower for development, but also far more stable. Even that may not work, though, because a change to the OS could make even programs written in those languages unsupported.

---

No, Y2K issues weren't just an issue for Cobol programs by any stretch of the imagination. Pretty much everything head to be investigated for 2-digit year fields and updated. Even Windows had some issues.

http://articles.cnn.com/1999-05-03/t...als?_s=PM:TECH

C and C++ are not as stable as you might think. They almost always rely on specific versions of C or C++ runtimes, and large C++ programs almost always involve one framework or another (ATL, MFC, Qt, etc.) which might go out of style or out of support. Unless you write carefully generic code and isolate all UI logic, which people only do when they need to, C++ programs are not trivial to port.

In reality VB6 programs are probably as solid as it gets. Everything in its ecosystem is frozen, which makes it easy for Microsoft to keep supporting it in new versions of Windows with few tweaks. At least until there is no x86 support anymore, for example ARM machines which are too underpowered to support a serious WOW64 subsystem. Unlike x64 systems an ARM WOW64 would be entirely software emulation, as it is on IA64 systems now. But most Itanium boxes are fairly powerful.


COM and .Net are not "frameworks." They are component models and implementations of such.

Quote:

---

Originally Posted by dilettante

C and C++ are not as stable as you might think. They almost always rely on specific versions of C or C++ runtimes, and large C++ programs almost always involve one framework or another (ATL, MFC, Qt, etc.) which might go out of style or out of support. Unless you write carefully generic code and isolate all UI logic, which people only do when they need to, C++ programs are not trivial to port.

---

Yeah, I made some generalizations, as people tend to do when they get on a whiny, philosophical, rant, but this is the only one I wanted to address. I tossed in the bit about the API to cover the ATL, MFC, Qt, OWL, and etc. That's what I meant about writing your own OS. The C/C++ languages are quite stable. The next standardization of each is unlikely to break existing language implementations, though the compilers may no longer generate fully compliant code. However, such programs get run in environments that are not so static.

MS is betting that peopl are changing their usage patterns to a more portable, touch model. I don't think businesses will be quick to follow suit, but overall, I suspect that MS might be right. That could mean that the whole hardware model that we have been using is about to shift, altering the OS in ways that will break all existing (until emulators are written). That remains to be seen, though.

mostly, when programs are renewed more reliable less rare codes are used and the code is more efficient, on the other side, the programmer seriously ages.

Quote:

---

Originally Posted by moti barski

on the other side, the programmer seriously ages.

---

Hoo boy, yes!! Some of these projects have certainly caused more than a few gray hairs.

Quote:

---

when programs are renewed more reliable less rare codes are used and the code is more efficient,

---

I would completely disagree with this. In my expereince, whenever an application is re-written it invariably results in a massive loss of stability. The extant program has had years of bug fixing to knock out any bugs that there were. Your new program won't have had any.

That leads me to the position I always take with this issue: If it works leave it alone.

Shaggy, the only compelling reason I can see that you've given for rewriting is a fear that tech might move on and mean the program could stop working. That's true, it could, but don't rewrite the program until it actually does. If it does move on you can always stick with the technology you've got until you've had time to rewrite the program so you're unlikely to find yourself facing an emergency rewrite.

I believe I have now convinced my friend of the wisdom of the position, and so, no re-write is going to take place. However, the question was philosophical rather than practical, since so many decisions about what actually gets done has more to do with politics rather than reason (if reason had prevailed, I wouldn't have the time to ASK this question, but that's a different issue).

What I was specifically pondering was whether or not the constant shifting of the environment that we work in ever justifies rewriting something to modernize it when it is currently functional. The near unanimous concensus was that it does not, and I agree with that.

This is something a few of our clients learnt the hard way when the support for realtime DOS was removed from the latest versions of windows. If you don't keep up with technology you'll soon wither out. If you shy upon spending a bit of time & efforts upgrading your applications to the new versions as soon as a new tested stable version is out, you might repent later when it's too late and you'll have to rewrite everything. There would be panic among your customers, huge financial losses etc. if it stops working suddenly one fine day due to hardware changes, OS changes, requirement changes etc. etc.

My suggestion would be: keep changing as and when things change.
Keep spending little by little on your applications and upgrade as and when a new version is out. This way everything goes on smooth. Even if you don't decide to upgrade immediately, you would surely get and idea about what and how much efforts you would need to upgrade when required. You should always keep working on new beta versions.

perhaps... but moving from VB6 to .NET isn't a trivial task... while moving from say FW3.5 to FW4.0 is fairly painless... if we were talking about a simple upgrade of the FW, then I think we'd all be pretty much in favor of the upgrade... but that's not the case at hand. And so that requires a different line of reasoning.

-tg

Just as a thought, there are a two justifications for undertaking a rewrite IMO:-
1. You've got spare time. Actually I'm getting the impression this one might apply to you at the moment. If it's a case of doing a rewrite or twiddling your thumbs you might as well do the rewrite. Just make sure you've also got enough spare time to cover stabalising the app as well.
2. The app is something you sell of the shelf. In that case your custoemrs probably want the latest technology because it makes them feel good and, apart from anything, you'd quite like the revenue of a repeat purchase. Microsoft don't need to keep giving us new versions of windows but they keep doing it.

Quote:

---

Originally Posted by FunkyDexter

In that case your custoemrs probably want the latest technology because it makes them feel good and, apart from anything, you'd quite like the revenue of a repeat purchase.

---

I can't remember the last time we've lost a sale because a software item wasn't running on the latest & greatest. In my experience sales are accomplished when the customer perceives that something has value. The only case when technology is amongst the top three considerations is when you're selling to developers or technologists.

Believe it or not, but the company I used to work for lost a potential sale because our application wasn't running on .NET. This happened about 6... maybe 7 years ago. never mind that the product had been running and was stable and doing just fine in VB6... oh well.

-tg

I was engaged in a sales pitch where the first question from the IT director was whether a system was based on .Net or not, so I get it. But these situations are rare and when they happen it's more likely than not that someone is looking for an excuse to show you the door. If you were in the market for, say, an ICR system that should be able to process 100.000 documents per hour and you found yourself one with good references, a good price and a healthy company to support it...would you really care if it's written in Asm, C++, C# or whatever?

The only time I feel that the technology part has value on its own is if you're competing with other products on a "me-too" basis. If you have the same features as everyone else and the same price as everyone else, then the tech question becomes reasonable. If you have a unique offering, whether the differentiation is based on features, price, track record, innovation or a combination of those, I feel that your technology platform becomes irrelevant.

As an IT manager, when I look at new products for our company, I look at them and try to figure out what they were made with. Apps with older styles of look and feel to their interfaces or that I see are written with older technologies, I shy away from because that typically tells me "This company had this program written 10 years ago, possibly by some college intern, and stopped caring about it. The next computer we get in with the next version of Windows or whatever may not work with it."

I don't know about any other corporate professionals, but I'm not going to take that risk. If I get the order to buy 20 new computers from Dell to get an expansion office running, the last thing I want to hear is: "Our shipping/ERP/contact manager/email client/backup solution/etc doesn't work with the new version of Windows installed on those new machines because the company who wrote it is too busy living off it's sales to bother to keep it modernized and well maintained!"

When support begins to waver and fall out for a piece of business-soft we use, I'm usually looking and researching what our next purchase is going to be. It doesn't matter that it "happens to be rock-solid for the last 10 years", what matters is it might not be rock-solid tomorrow because I have no confidence that software writer is looking that far ahead anymore.

Makes me think of my LANegram NET SEND replacement application posted in the UtilityBank here, with Installer MSI downloads I'm hosting myself.

It's all VB6, and I've had 750 binary downloads since I posted it. It isn't of much use to anyone not supporting Vista and Windows 7, and yes it works fine under Windows 8. Doesn't seem to be putting anyone off just because it isn't VFred or something.

@FD
what do you do with old programs that use unsupported .dll or activx ?

Quote:

---

I can't remember the last time we've lost a sale because a software item wasn't running on the latest & greatest. In my experience sales are accomplished when the customer perceives that something has value. The only case when technology is amongst the top three considerations is when you're selling to developers or technologists.

---

Actually I agree. It does happen so it's a consideration but the "repeat purchase" motivator's a far more important one if you're selling an off the shelf product. What I was trying to get across, though, is that, if you are selling an off the shelf product, there are a few reasons why you would want to undertake a rewrite before it's strictly neccessary.

Quote:

---

@FD
what do you do with old programs that use unsupported .dll or activx ?

---

unsupported or no longer functional? If it's no longer functional I'll have to rewrite it, but at that point my customer is going to pay me to do so. "No longer functional" is a pretty rare situation. If it worked yesterday and didn't today it's because the customer has made a change I don't neccessarily support. In that scenario the customer will pay me to update the software on a support basis.

As long as you're business model is about offering besopke development and/or time and materials support direct to the customer you have absolutely nothing to gain by pro-actively updating a piece of software. You're actually throwing away potential revenue, not to mention the extra risk you just took. If, and only if, your business model is about selling off the shelf software for which you don't want to offer the customer direct support, do you gain by pro-active change.

what are you talking about rewrite activex ? how do you get the activx or .dll source ?

You can only rewrite if you were the original author (and therefore have the source), or have access to the source.

A lot of VB6 programs relied on third-party ActiveX components, whose vendors have long gone out of business or moved to greener pastures. If you do not have the original setup diskettes, it's tough to set up a development environment.

We are in a situation where some our apps can no longer have a development environment due to the reasons mentioned above.

We are also in a situation where we do not have the source code to some of our production applications. This happens when your business gets bought / sold / merged / split over a period of time and the people in charge keep moving.

At this point of time, a good idea would be to start rewriting your applications, but that requires approval from the business. If the approval doesn't take place, the reported bugs are rarely fixed. The alternative is to fix the symptom of the bug by updating the data in the database.

is it common in big companies that most developers are clueless skill wize and there is one guy that actually knows how to get things done and technological problems are forwarded to him ?

I would say that such a statement would be a gross exageration of the truth, but it would be an instructive exageration. For any problem, every person will have a different understanding of it. Some will have a greater understanding, some a lesser, but no two people will have exactly the same understanding. Therefore, for each perspective on a particular problem, as long as you define your perspecitve sufficiently narrow, it is probably true that there is only one person who fully understands that perspective, and the rest do not. So, in any group of people, every person would be the sole expert for some problem, so long as you defined the problem domain with sufficient rigidity and narrowness.

yes and no... usually what happens is that people tend to specialize in a particular area. Mine for instance happens to be in dealing with Revenue/GL/AR/AP (Accounting) and SQL Data extractions... so that tends to be the kind of tasks I get (at least for the time being, while on this project)... It happens. sometimes intentionally, some times just by evolution (that's what happened to me, I sort of fell into this niche). It can be good and bad. Right now, I'm enjoying it as it's letting me gain exposure working with a part of the system that most people would rather not deal with (or can't). It's also allowed me to work with the developers that are working on the next generation of the General Ledger portion of the system. With my past and current experience, I'm able to provide input as to the short comings of the current architecture and give feed back on the new proposed layout.

In my previous lives, everyone was pigeon-holed and had their coding-empires... there was little in the way of sharing between teams and systems... which led to a lot of what you mentioned, a few key people that could actually do the work... I think it was a form of job security... that didn't work out very well for a lot of people. My current incarnation though... you have to know something about everything, there's still specializing, but with the dynamics of the teams here, constant shuffling of team members, you can't but help to know something about everything. You may still specialize in one area... but you at least have a working knowledge of the rest of the system.

-tg

I'm asking if it is common that in a company, employees that are supposed to have skills actually don't work almost at all and forward the poorly supervised project to one guy that is really good ?

In my experience... generally no... because the un-skilled don't last long. But that's my personal experience...

-tg

Quote:

---

Originally Posted by moti barski

I'm asking if it is common that in a company, employees that are supposed to have skills actually don't work almost at all and forward the poorly supervised project to one guy that is really good ?

---

Quote:

---

Originally Posted by techgnome

In my experience... generally no... because the un-skilled don't last long. But that's my personal experience...

-tg

---

In my experience, the technically unskilled with social skills move up the ladder to become project managers. :sick: :ehh:

Quote:

---

Originally Posted by abhijit

In my experience, the technically unskilled with social skills move up the ladder to become project managers. :sick: :ehh:

---

:D I've seen this happen more than once :D

Quote:

---

Originally Posted by ntg

:D I've seen this happen more than once :D

---

Yes and management can afford to do that because they need the technically qualified people to run systems. If a technically qualified person becomes the project manager, he's more likely to keep dabbling in code, rather than handle the team. This is undesirable.

"Those who can, do. Those who can't get promoted to management and out of the way..."

"If a technically qualified person becomes the project manager, he's more likely to keep dabbling in code, rather than handle the team. This is undesirable." -- depends... maybe undesirable for the team, but desirable for the PM. That's why I've said right from the outset with my current employer that I have absolutely no ambitions being a manager of any kind. None. I've seen their job, I don't want it. Instead, my career path is geared towards an architect role.

-tg

In many organizations "project manager" is a title only casually related to being an actual manager. They can seldom actually hire and fire, take disciplinary actions, etc. Often they are more like project secretaries or party planners, most valued for their organizational and communication skills.

This doesn't mean they aren't upwardly mobile, often quite the contrary. But they aren't managers.

Companies that take this style of workplace structure can become moribund with virtual and physical paper, lose technical talent, and become hollow shells where programming is now done by contractors. Sort of the old "How Britain lost its Empire" kind of thing, a nation of shopkeepers making less and less itself.

in the cases where there is one guy carrying the entire load of the project on his back and has very much knowledge, and the others don't really work, but make more money, is there a tradeof, is there an advantage or levarage the one guy gains other the freeloaders ?

Yup... they're screwed when he quits due to the stress...
edit - why is this even a topic of discussion? Doesn't really have much to do with the original topic.

-tg

I was going to mention that I'm amused at the direction this thread has taken. I've rarely seen a case where the discussion continued so long after the thread was resolved. I'm not complaining, mind you, but I resolved it back at post #13, and this one will be three times that number.

Personally, I think the situation where one person carries the whole load, and the rest of the team is all dead wood never really exists. If it does happen, it doesn't persist for long before the one person quits.

I'm not sure where you are coming from with this, Moti. Do you know of such a situation? It seems like the consensus is that it doesn't happen.

Oh I bet it does exist...but the question was if it's common and/or typical... which I don't think it is...

-tg

unimployment increase + ( big companies growing in profits and size, leading to unsupervised selection of employess by human resources devisions ) + many external human resorce companies with no actuall understanding of the many branches of work seekers's professional knowledge leads to :
many low quality employess being hired.

some companies and businesses might "solve" the resulted low profits with firing people left and right which would increase unimployment even more.

I heard in the kneset channel that israel is among the top countries with external employment ( via human resource companies ) & if I am not mistaken such stuff are on the rise world wide.

I remember an experiment with a monky seeing another monkey eating tastyer food and he prefered to drop both foods rather than eating.

I think, the solution for the not freeloader employee is to quit or delay the project until the bosses fix the thing.

How about doing the work for free, thereby driving the company out of business?