Quote:
Dont these guys think of TESTING any of these patches? Is it just me or do patches seem to come in pairs...
Welcome to Software Engineering. I'm a professional software engineer for a major (read "second largest") defense contractor in the world, so I'm very familiar with the full lifecycle of software development. You can test code until you are blue in the face. That does NOT mean that all is going to be well when the code is deployed. No matter how "identical" systems are (the test bed, the staging platform, and the production box), we're not dealing with toaster ovens here. We're dealing with highly complex, sophisticated equipment by any standard. And that equipment doesn't always "behave" the way the development team wishes, or the QA department believes.
Quote:
you dont work in the corporate world do you? testing comes AFTER release. it makes no sense, causes TONS more problems and ends up making them more work in the long run. but buried deeeeeeep below the surface, some marketting expert has calculated that doing this will increase revenue in some way. and in todays world, the dollar seems > all.
That might be true in Retail or some other sector, but let me assure that testing in the software development world most definitely does NOT come after release in a major development house. Maintenance/"bug fixing" of ANY software system comes with a price tag that weighs in at 80% of the overall cost of development of that project. You heard me right. 80%. Postponing QA until after release of a software product will guarantee failure.
Again.... A lot of people here do not understand the QA cycle of a software product. Just because it works on Test does NOT mean it's going to work on Production. Until computer systems get either more simple, or so sophisticated that they can fix themselves, this will ALWAYS be the case.
The failure of Sony has nothing to do with their process. It has everything to do with their Customer Service.
1. You don't schedule "Planned Downtime" 3 hours in advance.
2. When you do have to take the servers down in 3 hours, don't just post the message to a web site. Broadcast a system message (many claim no system message was broadcast...I don't know since I wasn't online at the time).
3. NEVER (I can't stress this enough) NEVER give a "true estimate" of your downtime. If you're a developer, and you *think* the system will be down for 2 hours, you NEVER tell the customer it will be down for 2 hours!!! You should KNOW BETTER BY NOW that you WILL encounter something you weren't expecting, blowing your estimate right out of the water, and making you the "bad guy". When you tell the customer that their service will be down for 4 hours, and you bring it up in 3, you get a lot of attaboys. When you tell the customer that their service will be down for 2 hours, and you bring it up in 3, you are definitely the "bad guy", even though the work was the same and took the same amount of time.
SOE needs to fix their customer service, NOT their development staff.