How long do bugs generally go unfixed for?

[numerobis]

On March 24, 2016 at 5:33 AM, QPDO said:

Getting a product that works is part of that deal.

Are you saying KSP doesn't work? Literally millions of people are learning rocket science. A dozen or so people have good paying jobs bringing joy to millions. Smashing success!

In your case, I guarantee your CFO sees it as a bug that you need to spend so much of your time on the clock getting paid just to make sure nobody dies, rather than actually moving your company forward. Your safety director sees it as a bug that you could screw up and get people killed. They haven't fixed the bug (and made you redundant). Are they bad managers? Maybe, but more likely they've made the determination that it's not worth worrying about right now; they've only got limited resources.

Fixing all the bugs is not a requirement.

[Snark]

On 3/24/2016 at 2:33 AM, QPDO said:

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.

Yes, it's complicated.  To the point that it's simply impossible to ship with zero bugs.  Cannot be done.

 

On 3/24/2016 at 2:33 AM, QPDO said:

Yet I read of bugs being known and simply ignored.

"Ignored" just means "not fixed yet"; they're not the same thing.

It is an unavoidable mathematical and economic fact of life in software engineering that not only there will always be bugs, but also there will always be MORE bugs (as people discover new ones).  More to the point, there will always be more bugs than there is time available to fix them.

New bugs are discovered all the time, and it's simply not possible to address everything.  The software is in a state of flux.

Producing a piece of software is not like setting up a display case in a museum, where you put the thing in, and then if there's anything wrong with it (a bit out of place here, a stray bit of dust there) you tweak it and adjust it until it's perfect.  Rather, it's more like driving a commercial bus on a cross-country route:  things are going to go wrong all the time, but you have to keep driving the bus because you're not allowed to stop.  So yeah, if the engine starts making funny noises and black smoke starts pouring out the exhaust, you stop the bus in a hurry and pour a lot of effort into fixing it right away.  But if there are a few dirty windows, you may have to wait a while until there's time to stop and wash them off, because the bus has to stick to the route schedule.

In short:  it's not possible to do everything at once.  Software producers have to triage relentlessly, continuously, all the time.  There will always be more bugs than you have time available to fix, so you have to prioritize, which means the less important stuff has to go to the back of the line and may go a long time without being addressed.

When you see a bug "sit around" a long time:  they're not ignoring it, they're busy fixing other more important stuff, or developing more important features.

So it's a legitimate complaint if you think they're triaging wrong (i.e. "They fixed A before B, but I think they should have addressed B first.")  However, it simply makes no sense to complain about a long-unfixed bug in isolation, because that's meaningless without taking into account what they were doing instead.

Do you have a specific example of a bug that you think should have been fixed sooner than some other bug fix or feature implementation?  If so, which bug?  And what other bugfix or new feature would you propose that Squad should have cut in order to allow fixing the one you want?

 

On 3/24/2016 at 2:33 AM, QPDO said:

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.

Can you give a specific example?

I can't think of a single thing in KSP that simply flat-out doesn't work at all.  Some bits work flawlessly; others have what seem like more than their fair share of issues (I'm lookin' at you, Klaw).  But overall, their stuff works, because they are skilled programmers with a lot of passion for what they're doing and they pour a lot of effort into what they do.

Yes, there are going to be bugs.  That's mathematically unavoidable.

And, because the software is a moving target, which means that new bugs are coming in all the time, there will be bugs that are unaddressed for a really long time.  This is also mathematically unavoidable.

So all that a software organization can do is to choose which bugs are addressed first, and which get shoved to the back of the line.  Prioritizing.

Are you saying that Squad should prioritize differently?  Can you give a specific example where you feel that they were incompetent at choosing which task to do first?  (There ought to be plenty of examples available for you to use, since they have a public bug database which lets you see much of the stuff they have to contend with, along with notes such as "when was this discovered" and "why are we deferring this".)

On 3/24/2016 at 2:33 AM, QPDO said:

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.

Exactly!  In other words:  You have to do your job.

I don't know exactly what your job is, but from what you've written, I gather that you're in some sort of maintenance / technical-support role where your job is to keep some system functioning.

It may not be software per se, but the software world has a very similar type of function:  it's called operations.  It's a very different job from development.  It sounds like what you have is an operations job, not a development job.

In the software world, operations and development (or "ops" and "dev", as we tend to call them) are completely different animals.  In my 20+ years as a software engineer, I've had a lot of experience at both roles.   They involve completely different skill sets and priorities.  They're both very important, but they address different areas and have different rules.

Development is what the folks at Squad are doing when they're producing KSP.  It involves creating software.  Making new stuff, finding and fixing bugs in it, dealing with new features, etc.

Operations involves keeping a system running.  Companies that have servers and websites-- the Amazons and Netflixes and Twitters and Facebooks of the world-- need to keep those servers up and running all the time, happy and responsive to new requests.  If they go down, they start hemorrhaging money, and fast.  A total outage at a major e-commerce site, for example, can cost millions of dollars per hour.

So they have "ops people" whose job it is to keep those systems running, and they have to deal with operational mistakes such as overlooking a connection between machines, or interactions among services.

Those people have to deal with issues, too, but it's a very different type of scenario from development, so it operates under very different rules.  Typically, there are two really big important differences between operations and development:

• Ops generally is dealing with a (somewhat) stable system.  The system is set up for some purpose, and once it's set up, the job is to leave it alone in the "good" state as much as possible.  It's not changing out from under you every day.  It's like keeping an engine running:  "Don't Fix It If It Ain't Broke."  If something goes wrong, sure, you pop the hood.  But you don't go tinkering in there and swapping out major parts of the engine just for the hell of it on an average day.  You leave it alone.
• Ops has a very low tolerance for Things Being Wrong, and can't leave a problem sitting unaddressed for a long period.  If you have a car that starts making a funny noise, you want to stop it and investigate as soon as possible, because it could be a really serious problem..

Those two things go together.  You can't have one without the other.  Ops will address and fix problems rapidly, yes.  But they can only do that because they're working with a fairly stable system.  And that's no accident:  the system is stable because they choose to make it stable, precisely in order to make it possible to address things quickly.

Development can't do that.  Development, by definition, is working on a very unstable system that is rapidly changing.  Therefore it's simply not possible to address everything right away.

Operations and development are completely different tasks because "keep it running" is a completely different problem from "make new stuff."

If your personal experience is in an "operations" type of role (even if it's not software), I can understand your perspective: it seems sloppy to you to leave stuff lying around.  However, you can't judge Squad by those same rules, because they're not doing operations.  They're doing development, which is a different thing with different constraints.

 

On 3/24/2016 at 2:33 AM, QPDO said:

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.

Exactly.  Customers should get what they pay for.

If your customer paid, say, $10,000 for a customized solution with a contract that includes specialists that come out and fix problems right away whenever they pop up, then they have a right to expect that.  I have no idea who your customers are, or what they're buying, or how much they pay for it.

But we can certainly look at Squad.  What they produce is a computer game, which they sell for a relative pittance (I paid US$27 for my copy).  And the game, is, in fact, a product that works.  It's exactly what it claims to be:  a fun and engaging spaceflight simulator that will give many hours of entertainment for a small price.  It "works".  It does its job great.  How many hours have you played it?  A lot, yes?  You keep playing it for a reason, yes?  If it didn't work, you'd get bored and go do something else?

Hundreds of thousands of devoted KSP players spend insane amounts of time on this game precisely because it "works".  Not just "works", but does so amazingly well.  They're getting exactly what they paid for, and I don't think it's reasonably possible for anyone to argue with that.  If I paid $27 for entertainment, it only "doesn't work" if I failed to get $27 worth of entertainment out of it.  I dunno about you, but I've gotten great value out of KSP for my entertainment dollar.

KSP players did not pay for "perfection" or a billion-dollar QA-and-support contract.  So they don't get that.

 

On 3/24/2016 at 2:33 AM, QPDO said:

But with Bugs on a "Nobody cares" list this does not sound like a good deal to me at all.

It's not "nobody cares"-- I assure you, developers care a lot about bugs in what we write.  We take pride in our work.

It's just that there are more things to do than there is time available to do them, so we have to prioritize.  If a bug's not getting addressed, it's because some other, more important bug needed fixing instead, or some vital new feature needed to be added to the product.