Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Pastimes : SI Programmer Job Hunt -- Ignore unavailable to you. Want to Upgrade?

To: Green Receipt who wrote (66)	7/1/2000 11:03:06 AM
From: c.horn	Respond to of 86

David, what would be the timeframe for what you've suggested? How long would it take a person or persons to accomplish this correctly in your opinion?.. Of course the above is just an emergency patch approach to their process. Really to do it right someone needs to come in and analyze the process, document it. Improve the process, and implement changes so this problem never happens again.

To: Green Receipt who wrote (66)	7/2/2000 1:32:54 AM
From: Mark Marcellus	Read Replies (1) \| Respond to of 86

Really to do it right someone needs to come in and analyze the process, document it. Improve the process, and implement changes so this problem never happens again. I agree with everything David says, but that would not be enough. The problem is management, and if the current management stays in place the only change which would make a difference is a brain transplant. The bottom line is that if you have a management which believes in the integrity of the development process, stuff like this doesn't happen. If they don't believe in it, it doesn't matter what process changes you make, they will always be compromised in the end. I've been down this road before, as I'm sure many of you have. I have no direct knowledge of the inner workings of SI, but IMO this whole project followed the common but disastrous sequence of 1) Come up with the deliverables; 2) Decide on a deadline; 3) Inform IT. Of course at this point IT said that what they wanted couldn't be done, and the negotiations began. Once this point is reached, a sane development process is impossible because the objectives are no longer clear. Instead you get a lot of horse trading and a lot of crossed fingers (both the lying and hoping kind). The best one can hope for is to avoid a complete disaster (better luck next time, folks). I have no doubt that if current management is allowed to remain in place after this fiasco we will soon be seeing a message from John Busby acknowledging that there are "deficiencies" in the process. Some poor soul (or evil opportunist, depending on who they bring in) will make some recommendations, and trees will give their lives to the cause of improving the process. When all this is done, some band aids will be put in place (e.g. a version control system, if one doesn't exist already) and some pretty documents will be printed and put on the shelf. Speaking of version control, David is assuming that they don't have it because they didn't roll back the changes once it was clear that everything was broken. I'm not so sure. My own theory is that the team running this show made a firm commitment that the new database would be in place by the end of the second quarter. I'm normally not a conspiracy theorist, but this fits too nicely, and I've seen things like that happen too many times. It would explain the odd timing of the rollout (why not give all the programmers Thursday and Friday off and then do it over the long weekend?). It would explain why the changes were not rolled back after being implemented. And it would explain the apparent unwillingness to go public on the front page warning of the problems. As long as that doesn't happen, the wrap up memo can say the changes were successfully implemented with "a few kinks" that were later worked out. IMO, the only real solution to this mess is to put someone in charge who understands the software development process, is committed to doing it properly, and reports directly to Russell Horowitz. If that happens, everything else will take care of itself. If it doesn't, we will remain in Dilbert land.

To: Green Receipt who wrote (66)	7/2/2000 2:35:11 AM
From: Pink Minion	Respond to of 86

Perhaps the most important is to implement a version control system. Then at least when problems happen such as this they could quickly 'go back' and get it back operational in minutes I'm sure they have a version control system even if it's RCS. They moved to a new database which makes "going back" not quite so simple. But they should have still had a plan even if was to backload new data to the old database. What they need are the basic components of UML for software testing. Use cases and the test cases they would generate. A monkey banging on the keyboard could have found some of these bugs. God, please don't make go back and work for pointy hairs again.