Why do bugs come back?

[MarkAusten]

Bad source control, bad testing / lack of automated test scripts and / or bad software design are the usual causes. Probably a combination of them all.

In practise you can have good source control, good testing, many automated test scripts and good design and still you get bugs. It's just that with the situation you have stated you get lots and lots more bugs.

I once had the chance to look at the open bug list for an early production version of Microsoft Word. At that time there were over 100,000 open bugs. Admittedly most of them would never occur in normal use, but that was the list.

Astonishing.

 

[MarkAusten]

This happens because companies let work several programmers on one program. Compared to the early days in programming where one person hat the complete overview about everything, today nobody seems to have a complete overview and this only can end up badly.

On the other hand, no one person could write Elite or any complex software product, in a reasonable time. Having a good view of a product like this requires above excellence in all the disciplines used. Software architecture, coding, requirements gathering, logic, programming language (Elite uses several), database design, database normalisation, database query optimisation, graphic design, graphic coding, sound design, sound recording, wide area networking, local area networking, physics, mechanics, science fiction, alien rationale, alien motivation, alien language, game translations(English, Polish, American, Australian, Japanese, Germans etc), testing, test scripts, test automation, procedural asset generation, back story and so on.

I'd say that having just one person do all this is pretty much an impossibility.

 

[Arindor]

Why do bugs come back? Because they...

Spoiler

Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you

I'd rep you but I was rickrolled.

 

[4gui4]

Why is it that a bug can be fixed in one patch, and then a few updates later it "comes back"? If it's fixed it should be fixed, right? I understand why there could always be NEW bugs, but not why old bugs can just reappear at any time. And the devs have to be told about it every time they come back, and sometimes it takes a concerted push from the community to get these bugs fixed a second or third time.

It seems especially weird when it comes to things which appear to be straightforward state toggles:
FA-off not staying.
The fiasco with throttle up/throttle zero at end of hyperspace jump.
Right now Escape Pods have reverted back to being "Illegal Salvage"
The Evacuation Passenger Missions are requiring faction rep again.
Dark Side of planets have started lighting up again.

Why is that?

I don't even want to try to understand, is not my job.

 

[Sentenza]

This happens because companies let work several programmers on one program. Compared to the early days in programming where one person hat the complete overview about everything, today nobody seems to have a complete overview and this only can end up badly.

No project today can be completed by only one person, not if you want it to be ready before 2050. It isn't 1983 anymore.

 

[sqzbox1]

Just like to say - this thread is not about why bugs happen. I think we all understand about that, and about limited testing issues and so on. The real question is - why does fundamental code that works perfectly and has nothing to do with new features suddenly get broken? For example, why should potshotting PP stop working? Nothing in 3.0.3 touches on that. Why should throttle settings after countdown stop working? Nothing touched on that in the new update. And we aren't going to get any answers so while it is nice to vent a little, the thread is actually rather pointless.

 

[Viajero]

Stay frosty son.

 

[Sentenza]

Just like to say - this thread is not about why bugs happen. I think we all understand about that, and about limited testing issues and so on. The real question is - why does fundamental code that works perfectly and has nothing to do with new features suddenly get broken? For example, why should potshotting PP stop working? Nothing in 3.0.3 touches on that. Why should throttle settings after countdown stop working? Nothing touched on that in the new update. And we aren't going to get any answers so while it is nice to vent a little, the thread is actually rather pointless.

When a major new release is developed most of the code is rewritten from scratch, not reused, especially if there are drastic changes. For example, we now that BGS data structures completely changed from 2.x to 3.x so all the relevant code must be rewritten. What happens next is that programmers working on new code must rely on DOCUMENTATION to reproduce behavior in the new code, because even if they are the same team who wrote the old one they would not remember everything they wrote. Now if documentation does not cover every single little change done in code - and it never does, because documentation takes time and time is money and you know... - the team ends up coding the wrong thing.

 

[Exigeous]

When a major new release is developed most of the code is rewritten from scratch, not reused, especially if there are drastic changes. For example, we now that BGS data structures completely changed from 2.x to 3.x so all the relevant code must be rewritten. What happens next is that programmers working on new code must rely on DOCUMENTATION to reproduce behavior in the new code, because even if they are the same team who wrote the old one they would not remember everything they wrote. Now if documentation does not cover every single little change done in code - and it never does, because documentation takes time and time is money and you know... - the team ends up coding the wrong thing.

Me thinks someone has never worked in development, at least not at an enterprise level. As Luke said "Amazing, every word of what you just said is wrong"

~X

 

[crushdepth]

Why do bugs come back? Because they...

Spoiler

Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you

Urgh. Fanboi!!!

 

[NW3]

Just like to say - this thread is not about why bugs happen. I think we all understand about that, and about limited testing issues and so on. The real question is - why does fundamental code that works perfectly and has nothing to do with new features suddenly get broken?

Because, in a complex program, there can be non-obvious interactions. Perhaps ED is too "tightly coupled"; that is what should be separate code modules "know too much" about the inner workings of other modules. Regardless, "fundamental code that works perfectly and has nothing to do with new features" must have some dependency on a change made elsewhere.

This is why you MUST have copious unit-tests, to catch these issues before they are released to the public. As a software engineer, it is clear to me that FD needs more automated testing. That's the ONLY way to "keep fixed things fixed".

 

[znôrt]

Urgh. Fanboi!!!

you have been babelfisched

it is clear to me that FD needs more automated testing.

yes, i think this is the most important realization of this thread, and the take home message.

"Amazing, every word of what you just said is wrong"

indeed, but even a broken clock is right twice a day and he might actually be onto something:

i speculate frontier's developement process is quite peculiar and unconventional. it often feels like they regard releases as a kind of end goal, a complete version of the game, then there's a few hotfixes and that's it. imagine they just burnt it on a pile of cds for sale, sent them away, then celebrated, and end of story. which is how game development worked a few decades ago. would explain why it's seemingly so darn difficult for them to release updates in the middle of the road, except for some quick server fix when it's absolutely necessary. of course they continue developing the game but it just seems there is no technical continuity between releases. i imagine them by then fully engaged in the new story and possibly unable to address or even reproduce anything pertaining to ... the 'old game'.

with this mindset, like, every version is a separate piece of artwork, there is no notion of 'continuous integration' or maintenance, or to treat your codebase like the living thing it is, that needs to be curated and managed, and your motivation to automate is far less. and in such a scenario it wouldn't be far fetched to imagine that some parts of the code were indeed throwaway pieces. in such a scenario it would even be understandable that qa operations would slack off considerably. why bother? so there's a bug in the old game? meh, who cares about that dead horse anyway, we're in the new thing already which is totally different. this would be another explanation for regression: bugs get fixed in versions of the code that have no connection whatsoever with the next product, which was branched just after release, possibly even before the last hotfix.

of course that's not how modern software development works, but then again frontier isn't your average software engineering company either. it's a peculiar bunch of artists and coders and cheerleaders rallied by a celebrity from the 80s, and i absolutely don't mean that in a bad way. au contraire, that's exactly the bunch of people that manages to produce this damn nice looking and awesome feeling game, so praise the thargoids! just, their ways in the path of the software warrior seem to be indeed a bit weird.

anyway, i think adding an automation and a software management expert to the bunch wouldn't hurt, and spare them quite a few pr hits.

 

[Bortas]

They never stopped, there were dark and light places before just as there are dark and light places now

They did. They were perfectly dark in 3.0. You really needed your headlights to see anything. People were happy about this issue finally being fixed after more than 2 years.

I was finally having fun driving around on planets for the first time.

But then, one patch later it was as broken as ever again

 

[MarkAusten]

Because, in a complex program, there can be non-obvious interactions. Perhaps ED is too "tightly coupled"; that is what should be separate code modules "know too much" about the inner workings of other modules. Regardless, "fundamental code that works perfectly and has nothing to do with new features" must have some dependency on a change made elsewhere.

This is why you MUST have copious unit-tests, to catch these issues before they are released to the public. As a software engineer, it is clear to me that FD needs more automated testing. That's the ONLY way to "keep fixed things fixed".

Agreed, but when was the last time you were able to write an application "properly"? I was handed one two weeks ago that had to be delivered, production quality, in 6 weeks and using a language that I'd never used before and an architecture that was new to me as well. Writing the unit tests would have taken the bulk of the 6 weeks with no production code to show for it. It I'm lucky there'll be time enough after delivery to retrofit some unit tests but I doubt it. Unit test are pretty much a "nice to have" category for much of the work I do and I expect that FDev are the same.

 

[NW3]

Agreed, but when was the last time you were able to write an application "properly"? I was handed one two weeks ago that had to be delivered, production quality, in 6 weeks and using a language that I'd never used before and an architecture that was new to me as well. Writing the unit tests would have taken the bulk of the 6 weeks with no production code to show for it. It I'm lucky there'll be time enough after delivery to retrofit some unit tests but I doubt it. Unit test are pretty much a "nice to have" category for much of the work I do and I expect that FDev are the same.

I understand. However, the rush doesn't allow time for quality.

Do you consider a bug-free product to be a "nice to have" feature?

Personally, while unit tests do take significant time to develop, they often speed up other parts of development. For the project I work on, the app takes about 90 seconds to start up and then you have to load a document, and then you have to test your changes. That usually takes more than 2 or 3 minutes total. I can run a unit test in under 10 seconds, so my debug/test cycle is much more efficient with unit tests. The big payback is in quality and reduced maintenance.

 

[MarkAusten]

I understand. However, the rush doesn't allow time for quality.

Do you consider a bug-free product to be a "nice to have" feature?

Personally, while unit tests do take significant time to develop, they often speed up other parts of development. For the project I work on, the app takes about 90 seconds to start up and then you have to load a document, and then you have to test your changes. That usually takes more than 2 or 3 minutes total. I can run a unit test in under 10 seconds, so my debug/test cycle is much more efficient with unit tests. The big payback is in quality and reduced maintenance.

Don't get me wrong, I'm all for unit tests. I just wish I was able to use them. The business imposed restraints prevent me from so doing. Nevertheless, the current app will be useable and pretty much production quality without the tests but it sure would be easier with them.

 

[Sentenza]

Me thinks someone has never worked in development, at least not at an enterprise level. As Luke said "Amazing, every word of what you just said is wrong"

~X

Yeah? Come and say that to the development team here, maybe they will listen to you.

"Guys? How come all the monitoring API calls suddenly stopped working? What do you mean, you did not know they were there???"

 

[Jimmy Joe]

They're bugs, Wyatt. You know all your smart talk about live and let live? Ain't no live and let live with bugs.

 

[Arkadi]

I wanted to post something smart, but hey, I was heavyly ninja'd...

Zombies. It's all about zombies.

Because software development is complex and difficult.

Copy / Paste error. You knows it.

Skynet..

because noone is so stupid to bring back the same bugs again and again and again and again

Usually this is due to poor sanitation and food being left out.

You never get all of the bugs out of a system...
... until the very last User is DEAD!

Kaocraft said: Why do bugs come back?

They are trying to invade our space. Seems logical that they will be persistent.

They're bugs, Wyatt. You know all your smart talk about live and let live? Ain't no live and let live with bugs.

Guess one of those answers must be right!

I think skynet is a close guess. It must be Guardians rampant AI coming for us. Isn't that obvious???

 

[Bearcat]

Why is it that a bug can be fixed in one patch, and then a few updates later it "comes back"? If it's fixed it should be fixed, right? I understand why there could always be NEW bugs, but not why old bugs can just reappear at any time. And the devs have to be told about it every time they come back, and sometimes it takes a concerted push from the community to get these bugs fixed a second or third time.

It seems especially weird when it comes to things which appear to be straightforward state toggles:
FA-off not staying.
The fiasco with throttle up/throttle zero at end of hyperspace jump.
Right now Escape Pods have reverted back to being "Illegal Salvage"
The Evacuation Passenger Missions are requiring faction rep again.
Dark Side of planets have started lighting up again.

Why is that?

Its economics. There are software engineering methods that can minimize bugs, but only the military will pay for it. You are able to buy this incredible game for something like $30 - $50. To get a game like this with dramatically reduced bugs you would need to pay $300 - $500. That's just the way it is.