21

As a software developer, I often see the term "broken" being thrown around regarding a bug or issue with a program. I don't think this is accurate, considering that often a program will continue to work perfectly well, with the exception of some feature that doesn't perform exactly as expected. Googling the definition of "broken" I get:

having been fractured or damaged and no longer in one piece or in working order

I'm hoping someone could recommend a term for "broken" that is more accurate for the situation. Perhaps "bugged"? Any other ideas would be welcome and appreciated.

Edit: I would like to thank everybody for their time and effort. I did not expect to get such a large response around this question. I accepted the answer that I think is the most accurate for the situation, but there are many other answers that were also strong candidates and would work well under specific circumstances.

Improve this question
19
  • 10
    Are you trying the describe the feature that "doesn't perform exactly as expected", or the program itself?
    – michael.hor257k
    May 5, 2017 at 15:46
  • 11
    Broken implies a sort of ad-hoc priority. I use it quite a lot when I want people to understand they should discontinue using something until it has been fixed, ie. a car with no brakes is broken. It sounds like you want a term for things of lesser priority. Can you add some context about priority.
    – Phil Sweet
    May 5, 2017 at 15:47
  • 3
    "slightly broken"
    – Greg Lee
    May 5, 2017 at 15:58
  • 3
    "Missing feature". "Unsupported function". This gap may well have been known about at creation, and this was accepted. But now it has become an "issue" which needs to be resolved.
    – Nigel Touch
    May 5, 2017 at 16:20
  • 8
    It seems as if the problem here isn't so much the term as the metonymy: the whole being called broken for just one part. "Broken" is well understood hacker jargon; just don't use that with cutomers and end-users. :)
    – Kaz
    May 5, 2017 at 16:51

15 Answers 15

Reset to default
56

Known issue.

As an example of fairly standard usage in the software and technology sectors, a program or system will be described as having a number of known issues. These will typically by prioritised and addressed in a planned way. However, areas of a product that are not affected, can continue to be used without any issue.

Examples of common usage abound, e.g.: https://success.salesforce.com/issues_about

Improve this answer
5
  • 8
    I think the asker is looking for an adjective to describe code containing bugs, not a synonym for bug. So the answer here is really "has known issues", this should probably be emphasized more.
    – talrnu
    May 5, 2017 at 18:32
  • 5
    Known issue implies that the developer knows about the issue and is ignoring it or prioritizing it lower than other work. There's nothing in the question to indicate that this is the case.
    – James
    May 5, 2017 at 20:19
  • 2
    To be fair, if it's an issue so significant that you might call the software "broken" then it's a good bet the developer knows about it. Of course, you know about it, so in that strict sense it really is a "known" issue ;)
    – talrnu
    May 5, 2017 at 20:40
  • 1
    @talrnu "adjective to describe code containing bugs" To be technical, all code contains bugs, it's just a matter of whether they are known or not.
    – user77261
    May 6, 2017 at 10:34
  • 2
    Issue is a well known euphemism for defect in software. Bug is similarly euphemistic. However, the OP is asking for a word for broken. Issue isn't that word.
    – Fuhrmanator
    May 7, 2017 at 15:20
20

I'd describe that software as buggy. As a software developer, we often encounter buggy code/software/etc. It usually works just fine except for a few use cases. In my experience this is common parlance among developers.

The website works great, but for some reason you can't login if your e-mail address has more than 20 characters. It's a little buggy.

Of course buggy could also mean the application is hopelessly broken, so adding an adjective to clarify the level of bugginess might be worthwhile.

You might call this a euphemism, but I demo "buggy" software to managers and stakeholders all the time ("please don't click that button!"). I would never demo "broken" software... even if parts of the software would be considered broken. That appears to get at the heart of what the original question is asking.

Improve this answer
5
  • 1
    If someone told me a mobile application was buggy, I would take that to understand a general lag, taps not registering, multiple features not working.
    – Pranab
    May 6, 2017 at 17:04
  • 1
    "Has (a) bug(s)" sounds more hopeful to me than "buggy". The latter brings to mind programs that weren't a joy to use because they crashed a lot, say.
    – Mathieu K.
    May 7, 2017 at 0:43
  • I hear this used as a general description, something like "Our tool is buggy. We have to figure out, which part of the code is broken." So again using broken for the code itself, but buggy for the effects that show because some part is broken.
    – skymningen
    May 8, 2017 at 11:17
  • 1
    @skymningen I'd say that code can be buggy without being broken (although in that case the logic is definitely wrong/broken). The original question seems to be about the whole system itself where I think buggy works much better than "known issue" or the other alternatives.
    – Mordred
    May 8, 2017 at 17:04
  • @Mordred It goes both ways. It could be buggy without something in the code being really broken. But code can also be very broken, with the software still not behaving buggy.
    – skymningen
    May 9, 2017 at 6:15
16

Sub-optimal may be appropriate, if you want to emphasize that everything works, just not quite the way you want it to:

below the highest level or standard, or not done in the best way possible
from Cambridge Dictionary

Improve this answer
13

A glitch is a typically minor failure in an otherwise healthy system. A glitchy system is one that exhibits glitches. Normally it suggests a system that has numerous glitches, but it can also describe a system that only has one significant glitch. e.g. "The controls for this game are too glitchy, the jump button only works half of the time."

Improve this answer
7
  • 3
    I wouldn't say glitch is neutral - it's slightly negative.
    – niico
    May 5, 2017 at 21:30
  • 4
    @niico It's about as neutral as it gets for a word that describes failure, which is what the asker is looking for.
    – talrnu
    May 5, 2017 at 23:00
  • 2
    Again I disagree. "Issue" is completely neutral - and more common (speaking as a developer myself).
    – niico
    May 5, 2017 at 23:12
  • 6
    Glitches are transient and inexplicable, rather than attributable to a known cause
    – Josh
    May 6, 2017 at 5:11
  • 2
    @talrnu I do have issues - but this is another, er, issue ;) Issue is a neutral word which in certain contexts can be seen as negative - but is still broadly neutral. Glitch is always negative - the fact they may be transient or inexplicable (I don't agree there) - doesn't change their negativity.
    – niico
    May 6, 2017 at 11:24
10

What to call it

"Broken" is fine for when the spec says "this is how it should work", and it doesn't work that way. This is called an "un-met specification".

"Broken" also is ideal for something which used to work and stopped working. That's called a "regression".

When something is found which isn't contrary to a given particular specification, but is nevertheless not the way something should work, this is a "defect" which needs to be fixed by specifying the desired behavior and patching the system to work that way.

So there are three terms you can use to zero in on what someone means when they say "broken". Un-met specification, regression, and unspecified defect.

Priority

Keep in mind, too, that the entire subject of priority is totally separate from the nature/origin of the bug. The term "broken" should not convey any sense of urgency. People need to be trained to use different words entirely to have that part of the conversation. Typical terms are critical, major, minor, and trivial.

Timing

To speak in terms of timing of when the fix is needed, now, soon, later, and never are useful and (in some shops) common expressions of priority.

Authority

This is a subject I want to talk about if we're talking about accuracy in discussing software defects:

People love to try to make their issue the top-priority one for engineers. However, sometimes one of those people doesn't get to say what the priority level is or by-when the fix is required. I point that out to people who make this kind of noise, and I put them in touch with a product manager or other authority-bearing decision-maker and get them and their noise out of my face so I can work on the things which really are of-priority.

The person with the authority is the one who can provide the most accuracy on a given defect's impact and risk.

Improve this answer
1
  • 2
    Some people use defect for all of these cases, as well as the one where the program worked perfectly to spec but did not solve the customer's problem, in which case a new requirement is added.
    – David K
    May 6, 2017 at 14:25
7

If a feature works, but is not performing how it was originally supposed to work, I would call it "out of spec" (short for specification).

Improve this answer
5
  • cosmetic flaws; cosmetic issues: "Minor priority is most often used for cosmetic issues that do not inhibit the functionality or main purpose of the project." -- "Drupal: Priority levels of issues"

Some issues people have with software can be described more accurately as one or more of:

  • snag
  • hiccup
  • quirky ("has quirks")
  • awkward
  • imperfect
  • incomplete
  • minor issue
  • unintuitive
  • non-blocking: "... use the following procedure to identify release blocking issues ... It is everyone's responsibility to move non blocking issues out of the v1.6 milestone." -- "kubernetes: release notes"
  • non-data-loss
  • not user-friendly
  • unimplemented feature ("feature request")
  • requires a few work-arounds
  • partially implemented feature
  • features that work as-designed, but are counter-intuitive to many people

Related: "Slashdot: Standards for Bug Severities?"

Improve this answer
4
  • 6
    Unfortunately I believe none of these actually answers the question. Perhaps the closest is "cosmetic flaws" because it contains the word "flaw", which is currently not presented in any other answers. This answer would be much better if it simply offered the word "flawed" with definition and example.
    – talrnu
    May 5, 2017 at 18:37
  • 1
    Non-blocking? In a software context, that means that an operation will continue in the background, instead of waiting until it's done before executing the next bit of code. How is that relevant?
    – anon
    May 7, 2017 at 5:52
  • 1
    @QPaysTaxes yes non-blocking by itself refers to a threading scheme and is wrong for this question. But when it is used to describe a bug such as "non-blocking bug" that's sort of correct. A non-blocking bug is a bug that's not bad enough to stop a release. As opposed to a blocking bug which is so bad it must be fixed before the software is released.
    – Buge
    May 8, 2017 at 6:40
  • @Buge I've literally never heard "non-blocking bug", probably because of the confusion with the a/synchronous execution term. I'd use "noncritical bug" myself for the general case; it's there, but it doesn't impact the release so significantly that it has to be fixed.
    – anon
    May 8, 2017 at 13:15
4

We could say that the program's functionality is degraded.

There is nothing wrong with the word broken, per se, it's just that it's being misapplied: the whole program is being called broken for a regression in one feature that doesn't affect all use cases.

The degraded term is used in storage. If you have a RAID1 disk array (pair of mirrored drives) and one of them dies, things are working fine for now, but the array is now just one failure away from being gone. It is called a "degraded array".

Improve this answer
5
  • 1
    Interesting... this works, though I've never heard it used in the context of code specifically. It also implies an element of time is involved, due to its close relation to "decomposed".
    – talrnu
    May 5, 2017 at 18:34
  • 2
    @James Not a constructive comment. Some feature in software can stop working because that software was modified, or its dependencies were modified (other software, or the platform) or something environmental. Say, have you never had a program whose functionality became reduced after a trial period expired? The question is about language. If it can "break", it can "degrade"; "degrade" better expresses that not all of it completely broke.
    – Kaz
    May 7, 2017 at 3:54
  • 1
    I agree with Kaz. Software totally does degrade. Software is more than just the image file - it's the environment it works in, and the platform it runs on. These change underneath you with suprising speed. It becomes unmaintainable, as well, when it's dependent libraries go away.
    – GreenAsJade
    May 7, 2017 at 7:06
  • @kaz everything you're talking about is a break
    – James
    May 7, 2017 at 9:15
  • +1 - code, once run, becomes a service. "Buggy code" may or may not have anything to do whether the running service is down/unusable or simply degraded. Degraded is common service manangement terminology for "condition yellow" - still usable but not behaving correctly in production.
    – mxyzplk
    May 7, 2017 at 12:58
2

I would call it an 'unexpected output'. It is neutral in the sense that an unexpected output is simply something that is not in line with the expected output. It can mean that the output is better than what you expected, or generally worse than what is expected, but it doesn't imply one or the other.

Improve this answer
4
  • 1
    I've only ever heard this used as a humorous euphemism for 'completely broken'
    – peterG
    May 6, 2017 at 10:57
  • @peterG I assume that something completely broken would even provide any output?
    – Michael Lai
    May 6, 2017 at 12:18
  • 1
    @MichaelLai sometimes no output is information enough
    – James
    May 6, 2017 at 21:40
  • 1
    @James Can't argue with that :D
    – Michael Lai
    May 6, 2017 at 21:58
1

How about "compromised"? It implies a limited degree of reduced function or performance.

Improve this answer
2
  • 18
    Compromised for software IMHO is too well-associated with security. People would naturally assume you mean that the security of the app has been compromised.
    – Muzer
    May 5, 2017 at 16:41
  • 1
    Agree that "compromise" has this problem.
    – expos4ever
    May 5, 2017 at 17:00
1

wanting (adj.):

  • lacking or absent: a motor with some of the parts wanting.

  • deficient in some part, thing, or respect: to be wanting in courtesy.

Might be used as:

The software works, but is wanting of some improvements in the UX.

Improve this answer
1

Since you are looking for a word that means that only a small part of a (software) system is not functioning as it should, you could say that the system has undesired behavior or has an imperfection. Both these can be either something that has always been there, or something that was introduced partway through the life of the system.

Improve this answer
1

Inconsistent as in Exhibiting inconsistent behavior Your colleagues' broken software might just be exhibiting inconsistent behavior, which is a term general (neutral) enough to encompass a broken feature (a spell checker that catches every other misspelled word) or a misunderstood requirement (a spell checker that checks all words against all installed dictionaries, rather than a specific one the user intended).

Improve this answer
0

Outdated. Out-of-date. Needs an update. Not up-to-date.
Program is not up-to-date and sometimes or some parts are defective.

Improve this answer
0

It is perhaps not the absolute best choice for your stated situation, but if there is an actual bug in some feature, particularly one that has only mild effects, that is sometimes colloquially (especially between developers) referred to as an undocumented feature.

Note: I strongly advice against using this term in any kind of formal report.

The implication of the term is that the software's observed behavior doesn't conform to the relevant documentation (which may be user documentation, a specification document, a user story, or something else), thus the behavior is undocumented. However, someone did after all write the code that produces the observed behavior. Because we typically write code to implement features in software, the observed behavior is a feature of the software; it may be an accidental or undesirable feature, but it's still a feature.

Hence "undocumented feature".

Improve this answer
1
  • "Note: I strongly advice against using this term in any kind of formal report." Well, yeah. Doing so would immediately make it false, because once it goes in the report it's a documented undocumented feature! 😉
    – FeRD
    Apr 16, 2022 at 4:10

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