Who Is Cryin' Now?

[Hack]

Not the ole Hackmeister...he is laughing his butt off.

The VBA folks here just found out (a stellar staff they are) that Office 2007 VBA no longer supports DAO, which is what 99.99% of all of their VBA apps use.

I've been telling them for the past 5 or 6 years they should rewrite these using ADO.

I got pooh pooed...

I'm a very sore winner...hey DAO folks

[kfcSmitty]

My buddy had the same fight with some people at the Ministry of Transportation about 3 years ago and they're in the same boat.

[abhijit]

Not the ole Hackmeister...he is laughing his butt off.

The VBA folks here just found out (a stellar staff they are) that Office 2007 VBA no longer supports DAO, which is what 99.99% of all of their VBA apps use.

I've been telling them for the past 5 or 6 years they should have rewritting these using ADO.

I got pooh pooed...

I'm a very sore winner...hey DAO folks

All you gotta do is resist upgrading to 2007.

[baja_yu]

That's what you get when management doesn't listen to developers.

[Pradeep1210]

I'm at least lucky in this respect that our management is quite open minded in this respect. As soon as a new technology is released and is somewhat stable, we start developing in that language, and slowly & steadily shed off the old languages. We are now preparing to move to VB 2010.

"OLD IS GOLD" doesn't stand in technology.

[techgnome]

It's not that they don't listen... it's jsut that often they don't care.

-tg

[baja_yu]

Here's how they were thinking: Why should we pay to rewrite something that works fine now? What? It might not work in the future?! We'll deal with that when it happens.

But when it does the time you have to do it in is substantially shorter, so it costs more, and because of the rush you get a half-assed job done.

[techgnome]

Oh, believe me...I get it... now stretch that out over a 6 year period... that was my last job. At least I no longer need to worry about that.

-tg

[Pradeep1210]

Here's how they were thinking: Why should we pay to rewrite something that works fine now? What? It might not work in the future?! We'll deal with that when it happens.

But when it does the time you have to do it in is substantially shorter, so it costs more, and because of the rush you get a half-assed job done.

NO. Actually this is the bad way to adopt a new technology.

Any code that is working and doesn't need a change should not be touched, unless the change is so minor that it hardly matters. e.g. upgrade a project from .net 2.0 to .net 3.5. We just upgrade the project with minimum changes possible. We do not try to embed the new elements in .net 3.5 into it. And that doesn't take more than a day to upgrade and test for broken pieces.

New projects should be started in the latest (or near latest) technology that's on the move.

New requirements in existing projects should be using latest technology if possible, otherwise use old technology. No need to upgrage all the modules just to satisfy a new technology change requirement.

So in our projects I see a mix of a lot of things. But that's fine and acceptable until and unless the old code has started behaving awkwardly or voilates any business logic. There may be two forms that behave similar while the code behind them are entirely different. e.g. One might be using heavy loops etc. while the other does the same with just one LINQ statement. But we know that the first form was developed using .net 2.o while the latter one was created in the time when LINQ option was available, i.e. .net 3.5.

By this process, the old technologies slowly takes a back seat and the newer technologies emerge to front.