Stan Lippman's VC6 rant

| 10 Comments

It's been a busy week. We got back from Verbier on Saturday and I'd hurt my knee, so I was sad, and limping and slow. I then had a mass of things to do to finish all of my client obligations by today. I collected up some blog postings that I was going to reply to, when I got a moment, and now I have a moment I find that one of them has vanished...

Edit: Yay! for the Wayback machine ;) Here's the original posting: http://web.archive.org/web/20041211175803/http://blogs.msdn.com/slippman/ Something that I didn't mention at the time was the passion that Stan was displaying; for all his lack of understanding as to why it was hard for some people to move from VC6 at the time. You can't fault him for how passionate he is about his work and his product!

My copy of SharpReader tells me that Stan Lippman had written a blog posting on 9th Dec about how he's annoyed (to say the least) about how some people haven't moved from VC6 to the latest, greatest version that everyone has been working really hard on... An understandable sentiment from someone who's intimately involved in a project, but, perhaps a little out of character - I guess he had one of those wine moments that I have sometimes... ;) The posting has now disappeared, which is a pity as I now have nothing to link to...

Anyway, the point is, Stan would like us all to move to VC.Latest and some of us haven't.

The problem is that for those of us who have to provide clients with code and project files for version X of Visual Studio it's not actually that easy for us to upgrade. Due to the way that later versions of Visual Studio can read earlier versions of project files it's easier to actually work in the earliest version that you need to support and then simply let the tools create the later versions of the project files when you need them for a client who has upgraded.

Stan, if you want people like me to upgrade to the new compiler and use it as my tool of choice then you need to have the new compiler's IDE support writing out backward compatible project files. An add-in will do. But I want to maintain ONE set of project files and if the only compiler that will let me do that is VC6 then I'll stick with that as my tool of choice until my last VC6 client upgrades. If the latest, greatest version supported a "write out a set of VC6 project files" option (and preferably I'd be able to select VC6, VS7 and VS7.1 and whatever else and generate the lot all in one go...).

10 Comments

some companies ask consultants/contractors to use the newer VS2003 ide in preference to the old VC6 one.
however, some of these contractors actually resist going to 'the new platform', saying something like this: 'i know the old IDE better, so i'll stick with it'.

what do u think of that?

I'd say it depends. It happened to me at one point during my last project - as you know... However, it turned out that the 'requirement' wasn't really that important to most of the senior stakeholders on the project and it was viewed as lower priority than hitting the date. Given that a conversion to VS2003 could happen automatically and painlessly at any point in the project it seemed, at the time, to be more important to produce a working system on time and if that meant using familiar tools rather than the latest version then that was an acceptable trade-off - it's just a simple risk management thing. It's always nice to have a client pay for me to learn new tools and techniques and had the requirement been important to them I would have done so. Unfortunately, as is often the case, the date won.

'the senior stakeholders', more often than not, do not understand or care about what IDE is used. the problem is, that the stakeholders which do know and care are not involved in the process of deciding these things until its too late, if ever.
also the reason the 'requirement' was not deemed important is the same (above): to be able to decide what and why, one has to have understanding. the fact that not all stakeholders were 'in the loop' can only be a criticism of the whole process...right?

Given the fact that a move "up" to the new compiler is, essentially, a free move and is automatic if you open the old projects with the new compiler then I don't really think it actually really matters that much... It can be done at any time. It's free. Who cares.

If it really is an issue; e.g. you find that the new compiler produces code that's so much tighter or better or whatever, and having that code in production over the old verion is a real gain in value, then I'd say it's up to the techies who "know" to make sure that everyone above is aware of the issue and includes it in the plan... Even simple things like changing compiler for something that's "known" to be better can be a nightmare if it involves a complete new test cycle or whatever just to get the code into production...

So yes, "the process" was probably at fault, and IMHO the techies in the know were possibly the ones who were failing...

"IMHO the techies in the know were possibly the ones who were failing..."

Are you a techie in the know, or a techie not in the know? :)

"... It can be done at any time. It's free. Who cares."

again, i have to disagree. this is purely your speculation, having declined to do the work. the client will now have to wait for 'conversion time' to decide if it is a free move or not. also, its so much free-er if it doesn't need to happen at all...

Actually I didnt decline to do the work. I was expressly asked not to do it when I asked the people who were actually responsible for directing me and signing my timesheets. Sometimes you have to know have to ignore the random noise and distractions and focus on the actual task at hand.

in that case whoever expressly told u not to do the work made a mistake, IMHO. the person who will now be doing the conversion will no doubt be able to assess whether he/she thinks the advice to do it in vc7, from the beginning, was noise or not, and if the conversion is free. lets hope it is ;-)

i would like to make sure 'this person' does not make the same mistake again.

IMHO find it strange you should think of good advice as noise, but its to be expected when the main motivation is a deadline. again that is a critisizm of the process. most contractors/consultants would prefer to take the path of least resistance. i know i've been there ;-)

Many a project has failed to deliver due to blindly following "good advice" and "best practice" and blindly adding technically clever gold plating rather than staying focused on the actual goal and delivering a working solution to the problem at hand.

In any project there are a huge number of things that can be done better and look like obvious wins when looking back with 20/20 hindsight - "how could these people have been so stupid"? Unfortunately unless documentation is kept that details why all project decisions were made and how one decision impacted another then this kind of post project recrimination is always possible.

As for consultants taking the path of least resistance, I guess it's just a difference in view point, but often I find that it's the permanent employees that tend to use the "that's the way it's done here" and "it's the process that's at fault, not me" as excuses for living an easy life and pushing responsibility around rather than taking it. Personally, I prefer to try and have the serenity to accept the things I cannot change, the courage to change the things I can, and the wisdom to know the difference... It's that last bit that's the killer...

except that we're not talking in terms of hindsight. the jury is still out...the conversion has not been done!
lets wait and see what happens - this thread is in danger of disintegration into a meaningful speculation...

in a perverse way i would like u to be right wrt this - but my experience is pulling the other way ;-)

Leave a comment