Any news on the upcomin Patch? - Page 2

Austin · July 11, 2002, 11:05

Quote:

Originally posted by MarkG
in that case i fail to see how you would find such a thing ironic. you're not a simple gamer not knowing that in the real world bugs are being "born" even in the process of correcting other bugs....

I find it ironic because you beta test something, to find the bugs, so you can fix them in a patch, which you then beta test, so you can find the bugs, so you can fix them in a patch for the patch, which you then beta test, so you can

There's a hole in my bucket......

From my own experience at least 3/4 of the bugs are generated during the development not by the programmers, but by management changing the spec on you every five minutes and then expecting the original delivery date.

Each day your short in the development process turns into 5 during the patching process, at least.

Austin

MarkG · July 11, 2002, 15:41

so there's 1/4 of the bugs created by developers' error and therefore in any case a patch must go through a testing ("beta") process and therefore there is no irony in something that is to be expected

Dan Severn · July 11, 2002, 16:02

I've been itchin' ta' make scenarios- Civ3 is so much better suited for them than civ2 was. Even then, a great wealth of creativity, art, and history was passed on by virtue of the civ2 cheat mode. ahh, the good ol' days- when ye had to hack files one by one to get the desired results- none of this sissy editor crap.

I'm kiddin', a scenario editor will be a great boon to Civ2's worthy successor. A good computer game is one that destroys your personal life and your job and leaves you destitute because you HAVE to get that rail link accross the mountain chain to bring fire and sword to those infernal aztecs

Great fun, a little dangerous.

heh heh heh

dunk · July 11, 2002, 17:00

Quote:

Originally posted by Trip
I think, finally the Coracles and JTs of the world will have to shut up for once, thank goodness...

That'll never happen. Don't fool yourself.

I'll assume that culture flipping will still be around, so that guarentees that Coracle at least will be unable to shut his / her yap.

Anyhoo, I agree that most people don't understand the amount of work that goes into programming. I've taken a few programming courses in my day, and let me tell you... It's tough to make a mortgage payment schedule program run properly on the first, second, third, even 15th try. And that's without any graphics or cool interface options.

Plus, beta testing is needed because you're never, ever going to find all the bugs within the development team. It's just like proof-reading a report, another set of eyes is always good.

dexters · July 11, 2002, 18:35

I find it ironic that people who claim to be in the software industry for any amount of time can find it ironic that developers beta test patches.

Deathwalker · July 12, 2002, 04:02

Quote:

From my own experience at least 3/4 of the bugs are generated during the development not by the programmers, but by management changing the spec on you every five minutes and then expecting the original delivery date.

From my exsperience most bugs in code are the results of the developers code, but the problems do not ocure until all the code is intergrated into the final product. Thats why most companies who work on programs do intergration testing

Austin · July 12, 2002, 10:36

Quote:

Originally posted by Deathwalker

From my exsperience most bugs in code are the results of the developers code, but the problems do not ocure until all the code is intergrated into the final product. Thats why most companies who work on programs do intergration testing

And how do you think those bugs get into the code?

Like I said it's been my experience that most of the time it comes as a result of changing the spec half way through, then expecting the original delivery date, which of course means the developers are now rushing, which both produces more errors and leaves you less time to find and fix them.

When I'm given a project and told to estimate a time, that estimate means "give me this much time, and the product will WORK'.

I don't work under the usual paradigm of "we'll fix it with the next release". What usually happens is 2/3 of the way through management changes it's mind, and now you are essentially building a product and a half in the time neccesary to build one product.

Either that or the developers are lazy idiots that should be canned.

Anyway my original comment was meant to be tongue in cheek.

Austin

albiedamned · July 12, 2002, 15:44

As a lifelong software developer myself, I agree with Austin. The non-technical people are always changing the requirements on us, causing us to rush and thus inducing bugs. I'm currently on a project where we're redesigning an in-house accounting system. The project has lasted 18 months, and we're nearing rollout, and now they've decided they need a contingency plan to roll back if the new system fails. Of course the code to convert from the old system to the new took months to develop, so the code to go in the other direction will also take months. But naturally they don't want to adjust our deadline!

My solution to this dilemna is simple. When someone asks me for me an estimate on how long a project will take, I come up with my real answer, then double it, and increase the unit. So 1 day becomes 2 weeks, 2 weeks becomes 4 months, and 4 months becomes 8 years.

Of course patches need to be tested. All code changes need to be tested.

Destroyer · July 12, 2002, 16:10

Perhaps we need an Ironic Works in the new patch

albiedamned · July 12, 2002, 16:16

Sorry to go so far off topic. If anyone has any real news on the upcoming patch, I would love to hear it. I too am about to start a new game, and I might wait if I knew the patch was imminent.

Nah, what am I talking about - I'm not going to wait and not play this weekend!

Boris Godunov · July 13, 2002, 00:40

Quote:

Originally posted by Ben Williams
Why get all excited about a patch you know nothing about?

But we do know a lot about it, they told us already what will be included.

Big things, my friend!

Austin · July 16, 2002, 14:21

Quote:

Originally posted by albiedamned
As a lifelong software developer myself, I agree with Austin. The non-technical people are always changing the requirements on us, causing us to rush and thus inducing bugs. I'm currently on a project where we're redesigning an in-house accounting system. The project has lasted 18 months, and we're nearing rollout, and now they've decided they need a contingency plan to roll back if the new system fails. Of course the code to convert from the old system to the new took months to develop, so the code to go in the other direction will also take months. But naturally they don't want to adjust our deadline!

Classic.

Quote:

My solution to this dilemna is simple. When someone asks me for me an estimate on how long a project will take, I come up with my real answer, then double it, and increase the unit. So 1 day becomes 2 weeks, 2 weeks becomes 4 months, and 4 months becomes 8 years.

This works, but the problem then becomes the competing software company that doesn't allocate this time and underbids you on contracts.

Sure, their code will suck ass and be full of bugs, but by then it's too late.

Quote:

Of course patches need to be tested. All code changes need to be tested.

And guess which part of the time budget gets sacrificed when the suits screw up your timeline? The time you would have spent testing has to be spent on things like that contingency plan.

Austin

kring · July 17, 2002, 03:06

It is due out Friday, with a readme due Wednesday, if testing doesn't find any problems. Check the front page here or at CFC or 1BC.

Also, sometimes bugs occur when people try doing things the program wasn't designed to do. Or, in something that wasn't found because it is almost never used.

http://apolyton.net/forums/showthrea...threadid=55832

Try the above URL for more info.