How long do bugs generally go unfixed for?

[KocLobster]

Just curious if there is an average turnaround time for bugs that aren't critical...for example, I discovered a fairly common bug, where solar panels collect energy and pretend there isn't a planet in between them and the Sun...this happens on the lakes of Minmus, up to a certain altitude as well.

http://bugs.kerbalspaceprogram.com/issues/1129

http://imgur.com/a/1FTHR

Edited March 21, 2016 by KocLobster

[kiwi1960]

depends on the bug, and how easy it is to cure.

 

minutes... vs never

BTW, in real life, you only need light to power solar panels... even moon light will give you some power... mine gives about 1 volt with a full moon...

direct sunlight to power panels is not needed... but I accept that they shouldn't work if you have a probe out by Pluto..... not sure of the formula KSP uses.

Edited March 21, 2016 by kiwi1960

[Claw]

There's no set timeline, and I'm not sure that any stats are tracked for an average turnaround.

As kiwi1960 said, minutes to never. It depends a bit on what sections of the game are receiving attention, what's coming down the pipe, and what time developers have available. Unfortunately there will probably always be more things to fix and tweak than there are available hours. Especially as KSP continually updates and changes.

[KocLobster]

Thanks guys. Of course I understand this, and relatively, this is a pretty minor bug anyways. I just had no idea how quick SQUAD in particular gets to things. You're right, there's always going to be more issues to fix than time available. Seeing how this bug is pretty well documented, easily reproduced, but has been around for years now, I assume this bug in particular probably won't ever be fixed. I think it gives KSP a little extra flavor.

[Snark]

6 hours ago, KocLobster said:

Seeing how this bug is pretty well documented, easily reproduced, but has been around for years now, I assume this bug in particular probably won't ever be fixed.

You'd be surprised.  Bug fixes can turn up at any ol' time.  For example, a Devnote Tuesday post a couple of weeks ago called out several fixes for old, long-standing bugs, including one that has been driving me up the wall for as long as I've played KSP (copying of action groups for symmetry parts).

So, maybe it'll get fixed with 1.1!  Or maybe not, but in 1.2!  Or maybe never.    But don't give up on them, it's largely a function of how hard it would be to fix, coupled with what other higher-priority things there are to work on, and how much player grief it causes.

Also, the fact that Squad has a public bug database for KSP lets you see what bugs have already been reported, and also what priority Squad has assigned to them, which is great for giving you visibility into their decision process.

[numerobis]

At a previous employer, we had a bug category called "neverland" -- bugs filed, verified, and not slated to be fixed ever.

Once in a blue moon, issues would get fished out of neverland and fixed because someone had a slow day and got personally annoyed at the bug (or a customer decided to pay us to fix it) but mostly it was a write-only part of the database.

And that was software that people paid thousands for in annual license fees.

[Sirad]

8 hours ago, numerobis said:

At a previous employer, we had a bug category called "neverland" -- bugs filed, verified, and not slated to be fixed ever.

Once in a blue moon, issues would get fished out of neverland and fixed because someone had a slow day and got personally annoyed at the bug (or a customer decided to pay us to fix it) but mostly it was a write-only part of the database.

And that was software that people paid thousands for in annual license fees.

We call em 'the Black Hat' Bugs that never planned to get fixed without noticing the customer about it.

[AlamoVampire]

There is another issue at play: will fixing bug x cause bugs y z? Messing with code at one point could affect something way earlier or further down the road. I think there are a few bugs here from before I joined at version .21. I think.

[pandaman]

Intermittent bugs that can't be reproduced easily can be a nightmare to pin down,  never mind fix.  And some bugs that can be really easy to reproduce, can still be extremely difficult fix, or even pinpoint the 'actual' cause.  It's just an individual case by case situation. 

 

[kiwi1960]

2 hours ago, AlamoVampire said:

There is another issue at play: will fixing bug x cause bugs y z? Messing with code at one point could affect something way earlier or further down the road. I think there are a few bugs here from before I joined at version .21. I think.

Is true... Bug begat bug b who begat bug c ... fix bug c and it caused bug D which couldn't be fixed because no one could pin it down.... then that caused bug E which then gave the clues needed to fix bug D which in turn also cured bug E but that caused bug F to appear.... fixing that caused bug B to return....

its a never ending nightmare.

 

[QPDO]

Guys ... I don't know if you notice, but stating this shows that you have no idea what you are doing in your job. Maybe you should feel lucky that you are living today as I think of a sword smith that forged faulty weapons with that attitude until the relatives of the (dead) customer appear and fed him some glowing embers. He might say it was due to bad iron he got delived... or somebody distracted him while he heated the metal, but in the end its his fault he made a sword that broke. A fault he knew or at least could have known if he cared.

Guess thats the difference between a craftsman and a guy that just does his job.

[HebaruSan]

34 minutes ago, QPDO said:

Guys ... I don't know if you notice, but stating this shows that you have no idea what you are doing in your job. Maybe you should feel lucky that you are living today as I think of a sword smith that forged faulty weapons with that attitude until the relatives of the (dead) customer appear and fed him some glowing embers. He might say it was due to bad iron he got delived... or somebody distracted him while he heated the metal, but in the end its his fault he made a sword that broke. A fault he knew or at least could have known if he cared.

Guess thats the difference between a craftsman and a guy that just does his job.

I don't know if you notice, but stating this shows that you do not have a job, at least not in software.

[Hodari]

1 hour ago, QPDO said:

Guys ... I don't know if you notice, but stating this shows that you have no idea what you are doing in your job.

No, it just shows that YOU have no idea what you are talking about.  Come back when you've written a program with a few thousand(let alone the hundreds of thousands or even millions that games take these days) lines of code that works absolutely perfectly.  Especially given the complexity of what this game is trying to do, the fact that it has to work on computers with a huge range of specs, different operating systems etc.  And then start adding on more features and having to go back and fix any new issues they cause as well. 

Swordsmithing isn't exactly simple either and it certainly has its own subtleties, but writing a program like this is easily several orders of magnitude more complicated.  Not to mention having had a few thousand years for people to work out all of the best techniques and other details.  And even then, swords broke all the time.

[numerobis]

Swordsmithing is a perfectly good analogy.

The blacksmith knows for sure there are imperfections in the sword -- that's just a constant in materials science. The good warrior knows for sure the sword is not exactly perfect, but knows its foibles, and lives with the fact that one day it will break.

Regardless, if it cuts off the giant rat's head, it's fit for purpose.

Someday someone comes up with a better weapon, say a musket. It too has its imperfections (like how you can't hit the broad side of a barn, or how they occasionally blow up) and yet, it better fits the needs of the day so it largely replaces the previous weapon.

[Snark]

10 hours ago, QPDO said:

Guys ... I don't know if you notice, but stating this shows that you have no idea what you are doing in your job. Maybe you should feel lucky that you are living today as I think of a sword smith that forged faulty weapons with that attitude until the relatives of the (dead) customer appear and fed him some glowing embers. He might say it was due to bad iron he got delived... or somebody distracted him while he heated the metal, but in the end its his fault he made a sword that broke. A fault he knew or at least could have known if he cared.

Guess thats the difference between a craftsman and a guy that just does his job.

Hi QPDO,

I'm assuming from your post that you have never worked as a professional software engineer on production code.

Software bugs are one of those things that people who haven't worked in the industry often misunderstand.  In particular, it's easy not to realize just how hard software engineering is.  It's a combination of extremely difficult technical problems with some hard economic realities.

I don't work for Squad, so I can't say any more than you can what their internal processes are like.  I have, however, worked as a professional software engineer for over 20 years, for a variety of companies from little startups up to multibillion-dollar behemoths, and I can tell you there is no such thing as a bug-free product.  No matter how many bugs your QA folks find and squash, there will always be more bugs.  It's essentially mathematically impossible to make a software product of any complexity 100% bug-free; just like it's basically impossible to make anything 100% clean.  Rather, it's a question of how many bugs and how bad are they.

Of course software engineers don't want to ship bugs.  We take pride in our work, and want to write code that's as bug-free as possible, and we put a lot of effort into testing our code to try to find and squash bugs before we send it out the door into the hands of waiting customers.

However... finding bugs isn't free.  Testing takes time, so does fixing.  So you have to ask yourself:  do you want a product that's 90% bug-free?  Or 99%?  Or 99.9%?  Or 99.99%?  Or better than even that?

Each one of those extra "nines" adds a lot of additional time and expense.  (Kind of like how you can quickly and easily wipe off a plate to get it mostly clean, but it takes millions of dollars of work to get something Hubble-space-telescope-mirror clean.)  And there's only finite time and money available.  So it comes down to a sad but unavoidable calculation:  how buggy is "acceptable"?

If you're writing really critical software, where people die if there's a problem-- e.g. crewed space stations, or nuclear missile launch controllers, or air traffic control-- then the answer is "virtually zero tolerance."  And so the producers of such code have to put insane levels of effort into testing and bulletproofing such code.  It ends up costing literally thousands of dollars per individual line of code, and it takes a really long time.  But they do it because "expensive and slow" is better than "people dying".  And once they get that code, they use it for decades, simply because it would be too much risk to try something new.

For a situation on the exact opposite end of the spectrum, there's a tiny indie game company like Squad.  They're operating on a relative shoestring-- they don't have billions of dollars to spend, they have only a relatively tiny handful of developers, and they have to push out code very rapidly because of the pace of game development; not just a single version of the product, but multiple new features in patch after patch, with a user community that starts screaming for blood if they have to wait longer than a couple of months for an update.

In a situation like that, it's economically impossible for Squad to ship a product that's up to nuclear-missile-launch standards.  If we-the-customers were willing to wait years between updates and spend hundreds of dollars on the product, then sure, it would be higher quality.  But we're not, so it's not possible.  I dunno about you, but I paid Squad US$27 for my copy of KSP, from which I've gotten literally thousands of hours of entertainment.  And Squad has gotten not one penny more from me.  US$27, that's it.  That's the entirety of my financial contribution to their entire development process.  That's what they have to run on.

So it's unreasonable to say that "Squad sucks because there are bugs in the product."  The only reasonable question and potential criticism would be:  given the amount of resources they have to work with, are they producing a reasonable level of quality?  You can't judge one without the other.

Of course you can come to your own conclusions about that.  However, I can say, based on my over 20 years of experience as a professional software engineer in organizations big and small, that I'm pretty happy with KSP, and with Squad's development practices.  It's a remarkably complete, high-quality product to have come from such a tiny team with such an aggressive schedule.  I've worked on considerably larger teams than Squad, full of highly intelligent and motivated people, who took longer to produce less product than Squad, for more money.

Certainly there are bad software producers out there; I've seen what "bad" can be, from personal experience; and I assert that Squad's not it.

So perhaps cut them a little slack, here?

[FancyMouse]

And even my pride of much-less-bug-than-anyone-else is destroyed since I was assigned to own a module that was written 15 years ago and original developer had left the company a long while ago.

Edited March 22, 2016 by FancyMouse

[kiwi1960]

15 hours ago, QPDO said:

Guys ... I don't know if you notice, but stating this shows that you have no idea what you are doing in your job. Maybe you should feel lucky that you are living today as I think of a sword smith that forged faulty weapons with that attitude until the relatives of the (dead) customer appear and fed him some glowing embers. He might say it was due to bad iron he got delived... or somebody distracted him while he heated the metal, but in the end its his fault he made a sword that broke. A fault he knew or at least could have known if he cared.

Guess thats the difference between a craftsman and a guy that just does his job.

Ummm... we are not the devs of the game.... we are merely players like you.... BUT... at least we know what is going on here.... so insulting....what you said will be ignored.

[Sirad]

17 hours ago, numerobis said:

Swordsmithing is a perfectly good analogy.

The blacksmith knows for sure there are imperfections in the sword -- that's just a constant in materials science. The good warrior knows for sure the sword is not exactly perfect, but knows its foibles, and lives with the fact that one day it will break.

Regardless, if it cuts off the giant rat's head, it's fit for purpose.

Someday someone comes up with a better weapon, say a musket. It too has its imperfections (like how you can't hit the broad side of a barn, or how they occasionally blow up) and yet, it better fits the needs of the day so it largely replaces the previous weapon.

You are perfectly right. since the early 90's the art or 'knowing whats going on inside the machine' just got lost in some ways.

Writing in C, C++, Pascal  or similar interpreters (this is not coding its 'interpreting') may lead to a perfectly looking sword. But as long as the 'coder' doesnt know anything about the deep mechanics inside the machine this sword may look perfect but the 'coder' may not know if it is made of Steel or Rubber.

 

[Darnok]

For about single light year or more

[rkman]

7 hours ago, Sirad said:

You are perfectly right. since the early 90's the art or 'knowing whats going on inside the machine' just got lost in some ways.

Because projects have become so large and complex that it has become humanly impossible for a single individual to be familiar with all the nuts and bolts inside the machine.

7 hours ago, Sirad said:

Writing in C, C++, Pascal  or similar interpreters (this is not coding its 'interpreting') may lead to a perfectly looking sword. But as long as the 'coder' doesnt know anything about the deep mechanics inside the machine this sword may look perfect but the 'coder' may not know if it is made of Steel or Rubber.

That's what debugging is for. Large projects outside of software to are developed that way: you don't just draw the blueprint of rocket, build it and then launch it to do its mission - instead it is a repeated cycle of prototyping, testing and improving. 

it's just that because most software is not mission critical, it tends to be released before all the bugs are ironed out.

[numerobis]

9 hours ago, Sirad said:

Writing in C, C++, Pascal  or similar interpreters (this is not coding its 'interpreting')

I thought Hopper, Backus, and friends had pretty much dealt with that argument back in the 1950s: working in a higher level language lets the programmer be a lot more productive.

[Sirad]

50 minutes ago, numerobis said:

I thought Hopper, Backus, and friends had pretty much dealt with that argument back in the 1950s: working in a higher level language lets the programmer be a lot more productive.

Right. But on the way up to that level something gets lost. Coding in a Interpreting language means you lose the knowledge upon 'code functionality and predictability'. in Semi Complex Projects this is really productive but as the Bugs pile up in a exponential manner the larger the project gets, there is a line where the productivity of more direct machine language meets the compiler. if you get over this level you are less productive than coding every module by yourself. While being a very small part in the development of OS/2 (anyone still alive who knows that OS ?) i touched that 'border' quite often and other fellows strictly passed that border quite often.....

[QPDO]

So all you (programmers) are saying is that your work is complicated. Assuming from the coding I do, I totally agree that making a game is absolutely complicated. Yet I read of bugs being known and simply ignored. Not because they are not solveable but because somebody designed something that should work, but doesn´t work the way it should and its a waste of time (in their opinion) to solve it. Excuse me, if I look at my job, where people might be in danger if I make a mistake or overlook a connection between machines, substances and peoples interaction, I have to recheck it and solve the problem. Not due to some code of honor but the simple fact that our customers pay for it. Getting a product that works is part of that deal. But with Bugs on a "Nobody cares" list this does not sound like a good deal to me at all. But maybe its different with your customers.

[cfds]

The usual bugs in the "will never be fixed" category are, to return to your sword smith analogy:

- "The blade is not made from adamantium"
- "There are no jewels in the pommel"
- "The runes on the blade do not do anything"
- "Is too unwieldy for field dress a hamster"
- "Could you temper it differentially?"
 

So either absolutely cosmetic changes, impossible changes, senseless demands or wishes that would change a whole great deal of the workflow with unforeseeable results.

 

 

[rkman]

3 hours ago, QPDO said:

Yet I read of bugs being known and simply ignored.

"Known" does not mean "easy to solve", and "not yet solved" does not mean "ignored". 

Not because they are not solveable but because somebody designed something that should work, but doesn´t work the way it should and its a waste of time (in their opinion) to solve it.

That's quite specific, but I very much doubt you can point to statements by Squad that support that assertion of yours.