blue3c said:
Well thats easy. Realease it when it is done. DOH!
Realease it when you have tested it, this actually means playing the game from the media it will be shipped on and on multiple systems. Playing the game till the end. Looking for the bugs on the list you may or may not have.
If the game fails, hmmm. Just thinking out loud here. Don't ship.
If your testers and staff can not get the product out on time, start throwing the axe.
Deadline are meant to be made. But being flexible and fluid in todays business world will get you far. It keeps your customers happy and if they are happy you make money.
Truthfully it sounds like poor deciesions made by upper manegment. Easily solved. AXE EM.
Come up with some standards.
Stand behind your product. If on the side of your product is says this hardware is required and this is rec, and it doesn't work on it. Who made the deceision to print that. AXE EM. Somebody has to step up. The customer should not have to finish a product he paid good money for. It does not say some assembly required.
Let me just start out by saying that I have been a professional programmer/analyst/engineer for over 20 years. My current position is Software Configuration management. I don't do the testing, myself, we have a test section for that. But a key part of my job is ensuring that what gets released to our customers is exactly the same product that got tested.
That said, we have a fixed release schedule (every six months) driven by factors external to our organization. (What we do is correctly called "sustainment" or "maintenance", because our products already exist; we just make sure our customer can continue to use them.) Our development cycle begins when the customer tells us what he wants in the next release. After the laughter subsides, we then discuss what we can
realistically provide. The customer identifies his priorities, and we try to do as much as we can. We can't always make it, and I am often delivering patches for several months after the official delivery. (Admittedly, many of these are not defect repairs, but enhanced capability the customer wants that we didn't have time to include in the initial release.)
Now, our customer is actually very satisfied with our work. It took us several years, but they now understand the level of effort involved in maintaining their software. They also will not come up with more money so we can hire additional people, so they know they are limited in what they can ask for. (You can have it good, or you can have it fast, but you're not going to get both.

)
OTOH, another side of the contract I work on, sometimes called "modernization" (they take our products, and convert them to client/server web-enabled apps) is falling behind. They've been working for 18 months, and haven't got any real product to show for their efforts, yet. <ost of them are putting in 60-80 hrs a week (I do 40 - it's enough). Yet, because of cost overruns, they are cutting 30% of the developers next month. But Management is remaining untouched. Management rarely gets "AXED", as you put it. Even if they're at fault. It's even harder when management is a company that has contracted your company to do the work. (E.g., Take2 vs Firaxis.) A lot of developers would love to release software "when it's done". But that doesn't seem to
ever work in real life.
Hmm, kind of rambling. I wrote it during breaks at work.
