6 ms·

> It doesn’t matter that the language you use is memory-safe, if you didn’t design for correctness or have no process that will eventually lead you to fixing al

> It doesn’t matter that the language you use is memory-safe, if you didn’t design for correctness or have no process that will eventually lead you to fixing all bugs. After many years in the business I have come to a more pragmatic view. There is no meaningful way of distinguishing features from bugs. It doesn't matter that work tracking software usually does. Once you realize that the lack of a feature is the same as the presence of a bug then "fixing all bugs" also means "adding all the features", then you also accept that you will never be done. If you have a bug to fix to weigh against a feature to add, which do you pick? The only correct answer is "The one that provides most value". And again we see that it's very possible - even likely - that fixing the last bug will _never_ be as important as adding more features. I know this is probably not what the author meant. First of all "having a process" doesn't mean completing the process. Second of all, you can categorize bugs as being of a specific kind (The linked article under [fixing all bugs] actually only talks about failing asserts).

0815beck 4mo ago
what do you mean "there is no way to distinguish a feature from a bug"? of course there is
- jihadjihad 4mo ago
  I read it as an argument from the end user’s perspective. Kind of like this: - trying to do X, getting software error: bug - wishing the software did Y, even though it’s not implemented: bug Indeed there are people who think like that, but usually they are people like my grandparents, whose level of software understanding boils down to “the Desktop is where I play Solitaire” and “Internet Explorer is the literal internet”.
  - alkonaut 4mo ago
    That's the simple version of it yes. I outlined a more complex version of it in a parallel answer. In short: lacking a complete specification of what to do, it's often impossible even within software teams to tell whether something is a bug. And you never have a complete specification of what to do.
  - coldtea 4mo ago
    >an argument from the end user’s perspective Well, the end user's perspective is buggy. And a developer doesn't have to give the same semantics as the user, anymore than a medical equipment manufactured needs to consider its products based on what each random patient wants and what misconceptions or urban legends they believe.
- alkonaut 4mo ago
  Some times there is, and in many cases there is not. Distinguishing a feature from a bug requires having some kind of spec. In some cases you can have obvious sign the behaviour is unintended/not desired, but in other cases it's not so easy. For example a customer reports a bug, your program can't print. Oh, you say, we never even had that feature! Please post again, as a feature request. Customer mumbles and requests the same thing as a feature request, not a bug report. They never understood what the difference was though. They couldn't print. Program bad. Now you implement the printing feature. There is an infinity of things to handle there. You add the 99.9% case which is basically regular printers, perhaps normal paper sizes. You however don't throw in things like document splitting (sending different pages to different devices based on capability). You have to stop somewhere. None of this is specified, however. None of the limitations are communicated to users. But you added the feature - in some sense. Then a customer with a 1970's pen plotter files a bug report that your new feature doesn't work on his device. Will you fix his bug? He's the only one on the planet with the problem. Is it a bug or a new feature? To him it's _clearly_ a bug. To you it would _clearly_ be a new feature to support pen plotting. You could argue the semantics of whether this is a bug or a feature until the sun goes down and it doesn't really matter. Either the fixed bug/added feature has enough value to be done, or it doesn't. A key takeaway here: this isn't merely something that appears in the perspective of the user vs the developer. The argument about whether you actually have a "Bug" because you stopped short of implementing every kind of printing known to man is one you could have with your PM too. He likely didn't even consider that. But does that make it not a bug?
  - tikhonj 4mo ago
    There is a pretty clear and important difference between a program that does something wrong, and a program that just doesn't do something somebody wants. "You don't support printing", "pressing the print button doesn't print", "pressing the print button crashes the computer" and "pressing the print button lets an attacker get root access to the system" are all different and it makes sense to distinguish them. (The first is a missing feature, the second and third are different kinds of bugs, the last is a special kind of bug we call a security vulnerability.) That distinction might not be useful to end-users, but it's useful for the people building the system! If you want to care about quality, committing to a strategy like "we will not add features before we fix known bugs" is totally clear, reasonable and effective. There might be some frontier of issues where it's hard to make a distinction, but that just means there are subtle edge-cases, not that the whole concept is undefined. A lot of perfectly cromulent concepts have edge-cases! You can just decide those on a case-by-case basis; if it's actually so close as to be legitimately confusing—it's not just feigned ignorance or political posturing—which side you choose probably doesn't have much of an effect. This does depend on having a reasonably clear idea of what you're building, but that "reasonably clear idea" does not have to be anywhere near the detail of a "full spec", much less anything formalized. To me, that seems like a baseline you'd need to build quality software at all, and hardly an unreasonable thing to expect. And if most teams can't manage, well, it's just another explanation for why most software is crap.
- onion2k 4mo ago
  A bug is a feature that does what the code says it should do, not what the requirements say it should do (or shouldn't in the case of most bugs). When you understand that there's no difference between a bug and a feature in the code. They're both just code. It's a correct statement, but when you're talking about memory safe languages it's true that memory safety helps you avoid writing code that doesn't do what you were expecting, so I'd still suggest memory safety matters for reducing the number of bugs.
  - witx 4mo ago
    > A bug is a feature that does what the code says it should do, not what the requirements say it should do (or shouldn't in the case of most bugs). When you understand that there's no difference between a bug and a feature in the code. They're both just code. You're twisting very hard the definitions here. A bug is a behaviour different than the one intended, it is not tied to code whatsoever. You can have bugs "in the code" that happen because of faulty hardware, or a solar flare. Unless you work in an industry where solar flares should be taken into consideration, the code and requirement can match and you still have the (protential) bug
thrance 4mo ago
By "The one that provides most value", do you mean in the short or long term? Very often, in my experience, prioritizing so-called "quick wins" only quickly wins the codebase more tech debt, that puts the project on a sure path to development hell.
- alkonaut 4mo ago
  > do you mean in the short or long term? The answer to that is sadly "yes". > prioritizing so-called "quick wins" only quickly wins the codebase more tech debt, that puts the project on a sure path to development hell. That's why we pay senior developers lots of money. Their gut feeling (or past scars) about what actually gives value across different horizons.
  - jeremyjh 4mo ago
    Very few of them have worked on a single system for more than four or five years, and have no idea what their decisions cost after they left. Many have joined a project after four or five years and suffered from those decisions, but they don't actually know why the decisions were made - how things looked at the time those decisions were made - and so they can make the same mistakes in their next greenfield project. Of course, some systems have to ship at all costs or there won't be a second or third year, so judgement is still required. But a lot of experienced people still underweight the costs of having lots of "low impact" defects.
dxdm 4mo ago
When a program clearly deviates from its spec, would you be okay with calling that a "bug"? There's always a gray area of what's intended by the spec, but a program can absolutely and blatantly deviate from the letter of the spec, and they often do. This distinction seems worthwhile to me, because it means that something someone already relies on does not work (anymore), even though reasonable people would agree that, according to the spec, it should.
- alkonaut 4mo ago
  Absolutely would. But if we can categorize 1/3 of defects as ”bugs” 1/3 as ”missing or incomplete functionality” then there is 1/3 in the middle which we can’t decide. So the dichotomy is kind of weird, and making ”rules” and processes about this categorization is probably not worthwhile.
  - dxdm 4mo ago
    At least not worthwile for the purpose you have in mind. Okay, now I understand better what you mean, something like: for some purposes, there's not much to be gained by distinguishing between "bug" and "feature", one major reason being that there is no clear boundary between the two. I first read your original comment in a much more absolute way (there is no distinction at all, and it never makes any sense anyway), which is quite easy to disagree with.
OtomotO 4mo ago
The lack of a feature is not the same as a bug. A bug means that there is a feature, but it's not behaving as was specified. (Or expected, or as it used to ... but clearly a difference to something, not to nothing) It doesn't matter whether to the end user that's indistinguishable. It is for us, the professionals. It's the same as with any other profession and domain-knowledge. If my heater doesn't work but it used to work, that's a bug, a regression. If it doesn't integrate with my smart home, that's not a bug. It was never a feature to begin with. > If you have a bug to fix to weigh against a feature to add, which do you pick? The only correct answer is "The one that provides most value". I agree. > And again we see that it's very possible - even likely - that fixing the last bug will _never_ be as important as adding more features. Depends entirely on the project and the revenue stream. I've open sourced code which I consider done. It does what it should do and I won't any more features to it. I will however fix bugs within the existing functionalities.
coldtea 4mo ago
>Once you realize that the lack of a feature is the same as the presence of a bug then "fixing all bugs" also means "adding all the features", then you also accept that you will never be done. This doesn't make sense at all. Your email software mangles my email. Or your media player randomly skips. That's a bug. No big philosophy needs to be hidden behind it. That your media player doesn't have the shuffle feature is not a bug. It's just an item on a wishlist. >If you have a bug to fix to weigh against a feature to add, which do you pick? Depends on the seriousness of the bug. If your disk backup software corrupts backups, I'd fix that, I wouldn't go add schedulled backups or encryption first. If what you meant to say is that bugs and features are both items to prioritize when deciding work, sure. But they're not the same thing and are not hard to tell apart, so the metaphor doesn't work.
- appplication 4mo ago
  My read was they were not saying they’re actually, literally, the same, but for the purposes of prioritization there’s no point in differentiating feature from bug when you use the same “how does this impact my products value to users” as the deciding factor for what gets scoped. It’s an interesting insight but I’m also not sure it’s valuable in practice. Sort of like “we’re just bags of chemicals that tricked rocks into thinking”.
  - coldtea 4mo ago
    >but for the purposes of prioritization there’s no point in differentiating feature from bug when you use the same “how does this impact my products value to users” as the deciding factor for what gets scoped. Then they could just say that, not that in general "a feature is the same as a bug" without qualification.
- alkonaut 4mo ago
  There are things that are clearly bugs and clearly features. And a lot of things that are somewhere in between. It’s not black or white and as such perhaps not worth categorizing? Especially with dramatic processes like ”always fix all bugs before implementing any feature”.
giancarlostoro 4mo ago
> There is no meaningful way of distinguishing features from bugs. Especially when you implement it exactly as directed by a project manager. Everyone forgets why it was done the way it was done, and then the same project manager asks for it to be "fixed" despite it being the way they wanted it in your original ticket.
demorro 4mo ago
Perhaps you have framed this overly strongly, but I think I get what you mean. I have worked in companies where "X is not complete" would be logged as a bug. Even beyond that, non-completeness often leads to behaviors, especially as users bed in around non-complete interfaces, that are obviously bugs, crashes and the like. If software represents a theory, any expansion in that theory (new features) will tend to lead to non-completeness, which will tend to lead to bugs. This is almost a mathematical certainty. Engineering around this implies restating your theory, and thus performing partial or total rewrites of your software, quite regularly. It's not as crazy an idea as it sounds, I'm sure there are architectural patterns that make this manageable.
somat 4mo ago
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." -- C. A. R. Hoare
BiraIgnacio 4mo ago
> I have worked in companies where "X is not complete" would be logged as a bug I've come to realize it's all about perspective. Something from the engineering stand point may not be a bug because there's nothing to fix. But the user might be having a bad experience because of that so it must be a bug. In the end, the user's perspective might be the less-wrong one.
BariumBlue 4mo ago
>There is no meaningful way of distinguishing features from bugs. From a user perspective, a bug is when behavior deviates from reasonable expected behavior. From a dev perspective, a bug is when the code actions mismatches the mental model (aka spec if it exists, else a reasonable mental model of the system). A bug becomes a feature when it becomes expected behavior.

0815beck 4mo ago

what do you mean "there is no way to distinguish a feature from a bug"? of course there is

jihadjihad 4mo ago
I read it as an argument from the end user’s perspective. Kind of like this: - trying to do X, getting software error: bug - wishing the software did Y, even though it’s not implemented: bug Indeed there are people who think like that, but usually they are people like my grandparents, whose level of software understanding boils down to “the Desktop is where I play Solitaire” and “Internet Explorer is the literal internet”.
- alkonaut 4mo ago
  That's the simple version of it yes. I outlined a more complex version of it in a parallel answer. In short: lacking a complete specification of what to do, it's often impossible even within software teams to tell whether something is a bug. And you never have a complete specification of what to do.
- coldtea 4mo ago
  >an argument from the end user’s perspective Well, the end user's perspective is buggy. And a developer doesn't have to give the same semantics as the user, anymore than a medical equipment manufactured needs to consider its products based on what each random patient wants and what misconceptions or urban legends they believe.
alkonaut 4mo ago
Some times there is, and in many cases there is not. Distinguishing a feature from a bug requires having some kind of spec. In some cases you can have obvious sign the behaviour is unintended/not desired, but in other cases it's not so easy. For example a customer reports a bug, your program can't print. Oh, you say, we never even had that feature! Please post again, as a feature request. Customer mumbles and requests the same thing as a feature request, not a bug report. They never understood what the difference was though. They couldn't print. Program bad. Now you implement the printing feature. There is an infinity of things to handle there. You add the 99.9% case which is basically regular printers, perhaps normal paper sizes. You however don't throw in things like document splitting (sending different pages to different devices based on capability). You have to stop somewhere. None of this is specified, however. None of the limitations are communicated to users. But you added the feature - in some sense. Then a customer with a 1970's pen plotter files a bug report that your new feature doesn't work on his device. Will you fix his bug? He's the only one on the planet with the problem. Is it a bug or a new feature? To him it's _clearly_ a bug. To you it would _clearly_ be a new feature to support pen plotting. You could argue the semantics of whether this is a bug or a feature until the sun goes down and it doesn't really matter. Either the fixed bug/added feature has enough value to be done, or it doesn't. A key takeaway here: this isn't merely something that appears in the perspective of the user vs the developer. The argument about whether you actually have a "Bug" because you stopped short of implementing every kind of printing known to man is one you could have with your PM too. He likely didn't even consider that. But does that make it not a bug?
- tikhonj 4mo ago
  There is a pretty clear and important difference between a program that does something wrong, and a program that just doesn't do something somebody wants. "You don't support printing", "pressing the print button doesn't print", "pressing the print button crashes the computer" and "pressing the print button lets an attacker get root access to the system" are all different and it makes sense to distinguish them. (The first is a missing feature, the second and third are different kinds of bugs, the last is a special kind of bug we call a security vulnerability.) That distinction might not be useful to end-users, but it's useful for the people building the system! If you want to care about quality, committing to a strategy like "we will not add features before we fix known bugs" is totally clear, reasonable and effective. There might be some frontier of issues where it's hard to make a distinction, but that just means there are subtle edge-cases, not that the whole concept is undefined. A lot of perfectly cromulent concepts have edge-cases! You can just decide those on a case-by-case basis; if it's actually so close as to be legitimately confusing—it's not just feigned ignorance or political posturing—which side you choose probably doesn't have much of an effect. This does depend on having a reasonably clear idea of what you're building, but that "reasonably clear idea" does not have to be anywhere near the detail of a "full spec", much less anything formalized. To me, that seems like a baseline you'd need to build quality software at all, and hardly an unreasonable thing to expect. And if most teams can't manage, well, it's just another explanation for why most software is crap.
onion2k 4mo ago
A bug is a feature that does what the code says it should do, not what the requirements say it should do (or shouldn't in the case of most bugs). When you understand that there's no difference between a bug and a feature in the code. They're both just code. It's a correct statement, but when you're talking about memory safe languages it's true that memory safety helps you avoid writing code that doesn't do what you were expecting, so I'd still suggest memory safety matters for reducing the number of bugs.
- witx 4mo ago
  > A bug is a feature that does what the code says it should do, not what the requirements say it should do (or shouldn't in the case of most bugs). When you understand that there's no difference between a bug and a feature in the code. They're both just code. You're twisting very hard the definitions here. A bug is a behaviour different than the one intended, it is not tied to code whatsoever. You can have bugs "in the code" that happen because of faulty hardware, or a solar flare. Unless you work in an industry where solar flares should be taken into consideration, the code and requirement can match and you still have the (protential) bug

thrance 4mo ago

By "The one that provides most value", do you mean in the short or long term? Very often, in my experience, prioritizing so-called "quick wins" only quickly wins the codebase more tech debt, that puts the project on a sure path to development hell.

alkonaut 4mo ago
> do you mean in the short or long term? The answer to that is sadly "yes". > prioritizing so-called "quick wins" only quickly wins the codebase more tech debt, that puts the project on a sure path to development hell. That's why we pay senior developers lots of money. Their gut feeling (or past scars) about what actually gives value across different horizons.
- jeremyjh 4mo ago
  Very few of them have worked on a single system for more than four or five years, and have no idea what their decisions cost after they left. Many have joined a project after four or five years and suffered from those decisions, but they don't actually know why the decisions were made - how things looked at the time those decisions were made - and so they can make the same mistakes in their next greenfield project. Of course, some systems have to ship at all costs or there won't be a second or third year, so judgement is still required. But a lot of experienced people still underweight the costs of having lots of "low impact" defects.

dxdm 4mo ago

When a program clearly deviates from its spec, would you be okay with calling that a "bug"? There's always a gray area of what's intended by the spec, but a program can absolutely and blatantly deviate from the letter of the spec, and they often do. This distinction seems worthwhile to me, because it means that something someone already relies on does not work (anymore), even though reasonable people would agree that, according to the spec, it should.

alkonaut 4mo ago
Absolutely would. But if we can categorize 1/3 of defects as ”bugs” 1/3 as ”missing or incomplete functionality” then there is 1/3 in the middle which we can’t decide. So the dichotomy is kind of weird, and making ”rules” and processes about this categorization is probably not worthwhile.
- dxdm 4mo ago
  At least not worthwile for the purpose you have in mind. Okay, now I understand better what you mean, something like: for some purposes, there's not much to be gained by distinguishing between "bug" and "feature", one major reason being that there is no clear boundary between the two. I first read your original comment in a much more absolute way (there is no distinction at all, and it never makes any sense anyway), which is quite easy to disagree with.

OtomotO 4mo ago

The lack of a feature is not the same as a bug. A bug means that there is a feature, but it's not behaving as was specified. (Or expected, or as it used to ... but clearly a difference to something, not to nothing) It doesn't matter whether to the end user that's indistinguishable. It is for us, the professionals. It's the same as with any other profession and domain-knowledge. If my heater doesn't work but it used to work, that's a bug, a regression. If it doesn't integrate with my smart home, that's not a bug. It was never a feature to begin with. > If you have a bug to fix to weigh against a feature to add, which do you pick? The only correct answer is "The one that provides most value". I agree. > And again we see that it's very possible - even likely - that fixing the last bug will _never_ be as important as adding more features. Depends entirely on the project and the revenue stream. I've open sourced code which I consider done. It does what it should do and I won't any more features to it. I will however fix bugs within the existing functionalities.

coldtea 4mo ago

>Once you realize that the lack of a feature is the same as the presence of a bug then "fixing all bugs" also means "adding all the features", then you also accept that you will never be done. This doesn't make sense at all. Your email software mangles my email. Or your media player randomly skips. That's a bug. No big philosophy needs to be hidden behind it. That your media player doesn't have the shuffle feature is not a bug. It's just an item on a wishlist. >If you have a bug to fix to weigh against a feature to add, which do you pick? Depends on the seriousness of the bug. If your disk backup software corrupts backups, I'd fix that, I wouldn't go add schedulled backups or encryption first. If what you meant to say is that bugs and features are both items to prioritize when deciding work, sure. But they're not the same thing and are not hard to tell apart, so the metaphor doesn't work.

appplication 4mo ago
My read was they were not saying they’re actually, literally, the same, but for the purposes of prioritization there’s no point in differentiating feature from bug when you use the same “how does this impact my products value to users” as the deciding factor for what gets scoped. It’s an interesting insight but I’m also not sure it’s valuable in practice. Sort of like “we’re just bags of chemicals that tricked rocks into thinking”.
- coldtea 4mo ago
  >but for the purposes of prioritization there’s no point in differentiating feature from bug when you use the same “how does this impact my products value to users” as the deciding factor for what gets scoped. Then they could just say that, not that in general "a feature is the same as a bug" without qualification.
alkonaut 4mo ago
There are things that are clearly bugs and clearly features. And a lot of things that are somewhere in between. It’s not black or white and as such perhaps not worth categorizing? Especially with dramatic processes like ”always fix all bugs before implementing any feature”.

giancarlostoro 4mo ago

> There is no meaningful way of distinguishing features from bugs. Especially when you implement it exactly as directed by a project manager. Everyone forgets why it was done the way it was done, and then the same project manager asks for it to be "fixed" despite it being the way they wanted it in your original ticket.

demorro 4mo ago

Perhaps you have framed this overly strongly, but I think I get what you mean. I have worked in companies where "X is not complete" would be logged as a bug. Even beyond that, non-completeness often leads to behaviors, especially as users bed in around non-complete interfaces, that are obviously bugs, crashes and the like. If software represents a theory, any expansion in that theory (new features) will tend to lead to non-completeness, which will tend to lead to bugs. This is almost a mathematical certainty. Engineering around this implies restating your theory, and thus performing partial or total rewrites of your software, quite regularly. It's not as crazy an idea as it sounds, I'm sure there are architectural patterns that make this manageable.

somat 4mo ago

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." -- C. A. R. Hoare

BiraIgnacio 4mo ago

> I have worked in companies where "X is not complete" would be logged as a bug I've come to realize it's all about perspective. Something from the engineering stand point may not be a bug because there's nothing to fix. But the user might be having a bad experience because of that so it must be a bug. In the end, the user's perspective might be the less-wrong one.

BariumBlue 4mo ago

>There is no meaningful way of distinguishing features from bugs. From a user perspective, a bug is when behavior deviates from reasonable expected behavior. From a dev perspective, a bug is when the code actions mismatches the mental model (aka spec if it exists, else a reasonable mental model of the system). A bug becomes a feature when it becomes expected behavior.