According to Wikipepdia,

A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways.

Recently I've found a "bug" in StarCraft 2 which produces an unexpected result: http://eu.battle.net/sc2/en/forum/topic/2868627470

The problem is that if I keep StarCraft 2 minimized for a long time, the game does not disconnect or generate any form of timeout. It does disconnects however after first battle and sometimes also loses game data (match statistics).

Unfortunatly, according to Blizzard:

The game is not designed to be kept minimized for such a long period of time. (Blizzard) cannot consider such behaviour as erroneous as StarCraft II is not meant to be minimized for hours.

So, is my "bug" really a bug?

closed as not constructive by Doug T., user8 Oct 21 '11 at 20:39

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 31
    Sure, its a bug, but they are not going to fix it as they don't consider this situation to be a supported one (i.e. since it wasn't designed to work this way, if you try to use it that way, you are on your own). And of course, there is a simple work-around - don't do that. – Oded Oct 21 '11 at 14:09
  • 17
    For the record, the Blizzard representative handled the situation very poorly. They should have said, "Thank you for reporting this bug. We will enter it into our system and fix it as soon as our developers deem it to be a priority." The implicit assumption would be that it will never become a priority. Very poorly handled in my opinion. – riwalk Oct 21 '11 at 15:57
  • 29
    @Stargazer712 Blizzard handled this exactly right. They should not set the expectation that they will fix a bug they have no intention of fixing. – MattBelanger Oct 21 '11 at 17:10
  • 3
    To be fair to TeleShoTTgun, I think Blizzard should have at least defined what counts as "a long period of time". I might minimize the game to go to the bathroom for a couple minutes. I don't think that's a very long time but does Blizzard? I would consider > 30 minutes to be a "long period of time" in this context, but I don't know if Blizzard would agree. – FrustratedWithFormsDesigner Oct 21 '11 at 17:24
  • 3
    Old Vaudeville act - "Doctor, Doctor, it hurts when I do this" - "Don't to that!" – Cyclops Oct 21 '11 at 19:26

To a software team, a bug is a software problem that needs to be fixed. Not all software problems need to be fixed.

Updating software is expensive. Blizzard is telling you that your problem is an edge case. In other words, the edge case problem you discovered is not necessarily something they tested for or otherwise care to account for. Fixing the problem will help you, but in all likelihood it will not help many others. Yet, the cost to fix the bug could be high. Instead, they can invest their resources into new features or even finish Diablo III.

  • 3
    I think you've captured the actual, used-in-practice definition. I was going to answer that a bug is any behavior that differs from the specs as other posters have. But the reality is that if faulty behavior was within the spec definition but had a significant impact on business, a company would fix it. And like you said, even if the spec says it should work and it doesn't, if the ROI is low, the company in question wouldn't fix it. Great answer. – Matt Ryan Oct 21 '11 at 14:42
  • 2
    @MattRyan: And in the real world (that I've seen), if the specifications result in faulty behaviour that the Business Users call a "bug", the development team usually formally re-classes the solution as a "change request", not as a "bug fix". ;) – FrustratedWithFormsDesigner Oct 21 '11 at 14:45
  • 3
    In other words, a "bug" or "defect" represents a requirement that is not implemented correctly. In this case, leaving the game minimized is not a requirement. – Ray Oct 21 '11 at 18:36

This kind of reminds me of the cat in the microwave, specifically the case of Mrs. Smith in 1983.

The point is, you expect the product to work in such a way. Mostly because a number of similar products work like that, i.e. if you minimize them for hours and then open them up, they work (although the opposite is not as uncommon as you might think).

Mrs. Smith knew from her experience, that drying her cats in the oven wouldn't harm them (presuming some caution of course). More precisely from experience she had with all the ovens she tried. She then assumed it would be the same for the microwave oven she was given. This assumption was wrong. Microwaves are not designed to dry cats. Neither are conventional ovens. They just happen to not kill the cat in the process as a side effect of the physical processes they employ to generate heat.

Now as a producer of microwaves, you could place a heating coil and number of sensors into the microwave. The latter would determine, whether the current content is a cat and use the coil instead of microwaves.

In the same manner, that one could produce a microwave suitable to dry cats, Blizzard could create a version of SC2 that is suitable to stay in minimized state for extended periods of time.

Personally, I'd be willing to pay more money for a cat-drying-enabled microwave just for the fun of it (assuming there is a big cat-drying-suitability-logo in front I can proudly point at). But I wouldn't care for a game that can stay minimized for hours.

SC2 was designed to meet certain requirements. Your expectation is not part of those. You are free to measure SC2 in respect to your expectations. But whether or not Blizzard includes all of them in the scope of their requirements is ultimately their choice.

All you could really argue about is, that it's a design failure. Common sense dictates that unless a substantial fraction of the users are confused by the design or unhappy with it, it's good enough. I am sure if enough users state that they share your expectation, Blizzard would yield and include it in the design. This would render your problem an actual bug and Blizzard would fix it.

  • Nice answer, horrifying metaphor. I am SO happy that someone wasn't actually dumb enough to do that! – Drew Oct 24 '11 at 2:25

I think this is a case of software not being used as defined by the specs. They say

The game is not designed to be kept minimized for such a long period of time.

Which to means that they have some definition somewhere of what counts as a "long period of time". If you minimize the program for more than a "long period of time", it goes beyond their specifications and beyond what they tested for (assuming they formally tesed this) and they do not guarantee what will happen. Of course, it would have been nice if the manual somewhere said "we have only tested this program to be minimized for periods of time not exceeding 10 minutes. Minimize for longer than this at your own risk!".

So no, I don't think this is really a bug. In my office, this would be called a "user training issue" (which I'd say is a form of a communication problem, because in this case because no maximum period for minimize-time was communicated to the user) since the user is not using the program properly. Not that it helps much for Blizzard, unless they put it in the manual...

  • 3
    For a mission-critical system, we have a requirement that says "this system must remain operational for n hours" and we test and document externally that the system operates for n hours. We might also internally document that we did a test for m > n hours and the system still functioned. For a game, which isn't mission critical, you don't necessarily need this formally captured externally, since most people will probably never encounter this issue. – Thomas Owens Oct 21 '11 at 14:14

Not a bug. A bug is behaviour that does not comply with the specification. If the spec says that the use case is not supported behaviour then any behaviour - perceived as valid or not - in that use case is 'by design'.

In this scenario, the game working at all could be perceived as undefined behaviour.

  • This is a massive dodge. I despise it every time I hear it. Because it only comes out when "the spec" is incomplete. – Sean McMillan Oct 21 '11 at 19:55
  • 2
    @SeanMcMillan: Without things like this, feature creep would kill us all. Either way, it's not a dodge, because it is a scenario that is specifically pointed out as not supported. – Steven Evers Oct 22 '11 at 0:26
  • 1
    @SnOrfus: It has been pointed out. After the fact. Do you really believe that there is a specification stating explicitly that "Minimizing the application for longer than x minutes is not supported"? Clearly, it's a bug. – ThomasX Oct 24 '11 at 9:06
  • The problem is that there is no spec that is complete enough to describe a real piece of software. A goal of "matches the spec" doesn't produce good software, it's just an excuse that it's "not my fault" when something in the software is bad. Maybe it's not worth fixing, but "the spec" is not the reason why. – Sean McMillan Oct 24 '11 at 12:10
  • @ThomasX Considering that the project I'm on, has a 200-400 page spec, and does indeed have boundaries defined for runtime. Yes, I do. – Steven Evers Oct 24 '11 at 12:57

If I was a development team lead on that project I'd call it a bug but a minor one since it's well outside of the normal operating expectations of the software. If it was going to be worked on at all I'd probably assign it to a junior programmer or a new hire more as a learning exercise for them than anything else.

It's a good idea to have these minor bugs tracked since they can indicate potentially more far reaching problems. For example, the data save bug you encountered. It seems minor due to how it happened but there might be other cases where data is being lost. By using a bug reporting system you can find all of the cases where a similar problem came up and see if there's a common element. In a complex system, having this kind of thing documented can help you find more serious and subtle bugs.


I'm going to disagree with most people here.

As an ex-Starcraft (original) player, I can attest that this is (or was, at least) very common behavior. Users leave the game on 24/7 to hold their position in chat rooms, and join games when they are back again. I'm sure the updated Battle.net has some improvements which may lessen the need for this, but it still happens a lot.

It would make much more sense that it doesn't let you join a game without re-connecting if your session has in some way, shape or form, expired. The fact that it allows you to join games after you have expired your session is a bug to me. The disturbing thing here, and something that hasn't really been brought up yet, is that the developers need to understand their users. This may very well be an edge case, but its an edge case to the very dedicated gamers that they should be set to please.

Technically, they can argue that it's by design, and it's not something they intend on fixing. It's still a fault in my eyes, which is ultimately up to them whether or not they classify it as a bug. That doesn't mean players agree.

Anyway, I thought I'd pose a slightly different answer than what's been posted so far.

  • 1
    I actually would minimize the screen for long periods of time if I actually played Starcraft. I think the question of whether it's a bug is irrelevant, but it seems like something it should handle and it would really bug me if it didn't. – psr Oct 21 '11 at 19:49
  • Agreed - this should be classed as a bug, all be it a very low priority one. While they may say that "leaving the game minimized for long periods of time is not supported", what exactly constitutes a long period of time? How do they know the same issue will not happen if minimized for 10 minutes? At the very least a game timeout should be designed and implemented that disconnects the user if it is left minimised for more than x minutes if they do not intend to support such actions. – Gavin Coates Oct 24 '11 at 10:05

A bug could reasonably be defined as "any deviation from the intended behaviour of the software".

Clearly they (and it's their software so they get to determine how it should behave) never intended the software to handle this scenario so it doesn't meet this definition of a bug.

However what I would say is, at the very least, suboptimal is the way it's handling this condition.

Garbage in, garbage out (that is the user does something stupid or bad or unexpected and something bad happens as a result) has been considered a poor standard of behaviour. I'd say at the very least it should be more elegant in the way it handles this condition.

So not strictly a bug, but a poor handling of an edge case.

That said if I were them it's not something I'd likely consider worth fixing (to expensive for too little benefit), though I might mention it to the team for future reference that it was something they might have handled better.


The definition of a bug has nothing to do with the behavior of the software. A bug is defined based on whether the behavior of the software matches it's intent. And who is to say what the intent was? (Since I'm dealing with programmers here, I'll clarify the first sentence - there is no possible software behavior that, in and of itself, constitutes a bug).

Bear in mind that generally a bug is something software developers are supposed to fix. So the definition of a bug is based on what they want to fix. For example, "working correctly more than 50% of the time is a feature we plan to release in future versions". Anything can be defined as not being a bug by pretending the software was never intended to address that particular problem. So, in practice, what constitutes a bug is a purely political consideration.

(As an aside, this cuts both ways. To a client that doesn't have to pay for bug fixes but does have to pay for new development "it doesn't do some feature that I just thought of but which I've now decided is 100% implied by the things I did mention" is clearly a bug.)

  • Isn't it OpenBSD that declares anything not documented properly to be a bug, no matter what it is? – Canageek Oct 21 '11 at 19:33

I would not consider not disconnecting a bug. Its only a bug if it was supposed to (by design, intent) disconnect and it doesnt. I'd call what you submitted a feature request.

That said, losing data after the battle - that might be the bug. I dont know much about Starcraft, but I suspect thats not by design.

Not the answer you're looking for? Browse other questions tagged or ask your own question.