Any news on the upcomin Patch?

[Austin]

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]

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]

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]

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]

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]

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]

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]

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]

Perhaps we need an Ironic Works in the new patch

[albiedamned]

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]

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]

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.

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.

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]

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/showthread.php?threadid=55832

Try the above URL for more info.