Formal verification is one of those last vestiges (especially in academia) of the idea that it is possible to prove that software programs are correct. It's true for very small focused programs which do not have to interact with anything i.e. self contained.
In practice, the effort required to formally prove that your software is correct is impractical. For "real" software systems, the number of unknowns introduced via API's, O/S and Hardware Interfaces, even just user interaction makes such "proofs" grow exponentially in complexity. If you are a software engineer, then you should realize that you will NEVER have the certainty of knowing something will work guaranteed every time. Formal verification is, frankly, a pipe dream.
IANAL, but what you're describing seems to be a serious breach of ethics on the part of the lawfirms involved. Yes, some lawyers actually take their ethical obligations to society and the courts seriously.
I think you or your lawyers would be well advised to immeadiately contact the ABA (American Bar Association) and talk to them about your situation. The simple fact they cannot produce a client-attorney agreement when a lawsuit has been filed in your name is pretty damning. More then that, their behaviour after the fact is plain out wrong and the ABA may be able to help redress that.
When it came to Civ 4, did you decide to write the entire system from scratch or did you build off of parts (or all) of Civ 3?
If you did have to throw out a substantial part of the original code base, how did you go about deciding what was worth keeping and what needed substantial reworking?
Interface wise, I think the Microsoft dev products are pretty good and I felt they tended to improve with each version. Guessing based on my transition from VC6 to 2003, you shouldn't have too many problems with the new look and feel.
Now, I'm assuming that you're also planning to change the compiler you use in VC6 to whatever they've got for 2005. And this is where things get fun.
At my last job, we switched compilers on two occassions. The first time was a disaster, and our QA team was flooded with defect reports - see, as we did this shortly before a major release and learned a painful lesson.
Recently, we migrated from VC6 to the VC7 compiler. We continued to compile both versions for almost a year before we finally committed to the new compiler. I think the newer compilers are better for error detection in the compilation phase, but you will have to carefully watch out for subtle bugs that don't appear simply because of how the compiler used to behave.
A couple of years ago, there was a great article in Dr. Dobbs about using multiple compilers from different vendors as a great way to help catch errors in your code as well as use safer programming practices. Our migration pain highlighted just how much this one practice could have spared us in the long run.
The prime movers for certification in any place I've
worked for has always been the management teams and/or HR. It just makes life easier for them. But if you're a software developer like me, the only thing you care about is can this person do the job, and do it well? Certifications last right up until I get to see your code.
Obviously, your article shows you feel you're being screwed by the current system. Before you lay the blame squarely at HR/Management feet, realize that you use certifications in your own life to filter out the crap you deal with. It's easier to trust some university to tell me this guy should be a doctor, then pick up enough domain knowledge to figure that out myself.
What I don't understand is that you recognize that a cert is just a filter, but you don't elaborate on your attempts (if any) to bypass it. If you've got the skills to work there, then you need to figure out how to get that across (get a recommendation by someone, talk directly to the people you'd be working with/for etc.). Lacking a certification just means you have to work a bit harder to get in the door. And frankly, if all they really care about is how many certs they have on staff - doesn't that send a warning signal to you that you might not want to work there?
The only people talking about the slump are those
who are being spoon fed from the movie industry. There's a heavy vested interest on the part of the industry to act like they're in a slump and blame it on something (piracy especially).
Three of the eight highest grossing domestic releases of all time were released last year in February (Passion of the Christ), May (Shrek 2) and July (Spider-Man 2). The top two films of last year release by this date has put $740 million into the till by now. This year, the top two have been good for $530 million by this date... a different of about $210 million, which by itself makes up for all but about $90 million (or about a 2% drop from last year) of the current "slump."
I've got a more technical/CompSci'ish question for you, just looking for feedback from the development side of things:
What have you been doing about code evolution in the game?
You obviously forsee this codebase being in existance for probably another five years (just look at EQ), and it's already been in developement for over three. How do you manage the complexity of this system? I'm thinking in three areas:
What's your test philosophy (unit tests, test case matrixes, automated/exploratory)
Every developer hates documentation, but obviously you have even more need for it. How do you balance documentation vs. actually getting the code written.
Whenever a change/bug fix is proposed, what's your own internal process for addressing it and how has this evolved over the project's life?
Have you considered doing a post mortem?
WoW obviously has a large codebase, and generally your team has been able to deliver fixes (every now and then a bugfix backfires).
Slashdot Mirror
Formal verification is one of those last vestiges (especially in academia) of the idea that it is possible to prove that software programs are correct. It's true for very small focused programs which do not have to interact with anything i.e. self contained. In practice, the effort required to formally prove that your software is correct is impractical. For "real" software systems, the number of unknowns introduced via API's, O/S and Hardware Interfaces, even just user interaction makes such "proofs" grow exponentially in complexity. If you are a software engineer, then you should realize that you will NEVER have the certainty of knowing something will work guaranteed every time. Formal verification is, frankly, a pipe dream.
Oh . . . wait . . .
IANAL, but what you're describing seems to be a serious breach of ethics on the part of the lawfirms involved. Yes, some lawyers actually take their ethical obligations to society and the courts seriously. I think you or your lawyers would be well advised to immeadiately contact the ABA (American Bar Association) and talk to them about your situation. The simple fact they cannot produce a client-attorney agreement when a lawsuit has been filed in your name is pretty damning. More then that, their behaviour after the fact is plain out wrong and the ABA may be able to help redress that.
If you did have to throw out a substantial part of the original code base, how did you go about deciding what was worth keeping and what needed substantial reworking?
Now, I'm assuming that you're also planning to change the compiler you use in VC6 to whatever they've got for 2005. And this is where things get fun.
At my last job, we switched compilers on two occassions. The first time was a disaster, and our QA team was flooded with defect reports - see, as we did this shortly before a major release and learned a painful lesson.
Recently, we migrated from VC6 to the VC7 compiler. We continued to compile both versions for almost a year before we finally committed to the new compiler. I think the newer compilers are better for error detection in the compilation phase, but you will have to carefully watch out for subtle bugs that don't appear simply because of how the compiler used to behave.
A couple of years ago, there was a great article in Dr. Dobbs about using multiple compilers from different vendors as a great way to help catch errors in your code as well as use safer programming practices. Our migration pain highlighted just how much this one practice could have spared us in the long run.
Obviously, your article shows you feel you're being screwed by the current system. Before you lay the blame squarely at HR/Management feet, realize that you use certifications in your own life to filter out the crap you deal with. It's easier to trust some university to tell me this guy should be a doctor, then pick up enough domain knowledge to figure that out myself.
What I don't understand is that you recognize that a cert is just a filter, but you don't elaborate on your attempts (if any) to bypass it. If you've got the skills to work there, then you need to figure out how to get that across (get a recommendation by someone, talk directly to the people you'd be working with/for etc.). Lacking a certification just means you have to work a bit harder to get in the door. And frankly, if all they really care about is how many certs they have on staff - doesn't that send a warning signal to you that you might not want to work there?
I quote from Dave Poland:http://www.thehotbutton.com/today/hot.butto n/2005_thb/050621_tue.html/
There is no slump.That last line should have been:
Have you considered doing a post mortem?
Thought I'd deleted that text at the end.
What have you been doing about code evolution in the game?
You obviously forsee this codebase being in existance for probably another five years (just look at EQ), and it's already been in developement for over three. How do you manage the complexity of this system? I'm thinking in three areas:
Have you considered doing a post mortem? WoW obviously has a large codebase, and generally your team has been able to deliver fixes (every now and then a bugfix backfires).