[coldtea]

>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.

[gobdovan]

Grandparent is onto something. You can't define correctness without a spec. And since most business-oriented software, which most of us work with, isn't made against a comprehensive spec, you can argue that anything falling outside it is either a bug or a feature. 'If your disk backup software corrupts backups' has behind it a clean definition that's (pretty) unambiguous and you don't care about, since it's already outsourced to some cloud solution. But 'User finds it easy to buy more stuff' does not.

Also, mandatory Sussman reference [0], where he talks about correctness not being that important and gives Google as example, that just needs to be close enough and not disastrously incorrect + interesting stuff around engineers confusing brittleness with correctness.

[0] https://www.youtube.com/watch?v=HB5TrK7A4pI

[coldtea]

>Grandparent is onto something. You can't define correctness without a spec.

Sure you can. Correctness doesn't mean "follows a spec", it means "It does what the developer intended it to do without problems".

I mean that casually and within reason, it's not supposed to be a formal statement checkable by proof checker. z

I don't need a spec to know that e.g. my email client has a bug if it crashes when I try to make something bold. The presense of the "Bold" formatting button means it should support it, spec or no spec.

[gobdovan]

I did not mention 'formal statement checkable by proof checker' anywhere. Correctness requires some criterion external to the implementation. Write it down and it's a spec. If you do not write it down and the behaviour is not one of the already-standard failure classes like crashing, corrupting data, losing work, then there is no principled way to classify it as a bug rather than an intended feature or tradeoff.

[appplication]

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]

>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]

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”.

[generic92034]

Claims from maintenance contracts in B2B depend on classifications like this. So, it is absolutely worth categorizing, for certain businesses.

[Levitz]

>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?

I appreciate the exercise of taking a step back and looking at the abstractions built, really I do, sometimes people take a liking to certain bugs, sometimes people despise features as if they were bugs, but this feels a bit of a Loki's wager situation: https://en.wikipedia.org/wiki/Loki's_wager

At the very end of things, bugs and features are just things the software "does", but I reckon it's worth it to sit back and think about the intentional and non-intentional result of the application of a design.

[AnimalMuppet]

When you're trying to prioritize work, bugs and features are the same - they're both demands for developer time. I don't think they were saying anything more than that.

You want to say that they're not the same kind of work? True. And yet, when you're allocating work, that doesn't particularly matter.

[coldtea]

>I don't think they were saying anything more than that.

Well, they did claim something more though though: "the lack of a feature is the same as the presence of a bug then "fixing all bugs" also means "adding all the features".

Well, no. Take TeX as an example. It does what it does. Bug are bugs, and they can fix them. Lack of features are not bugs. They can absolutely close to fixing all bugs. And some small programs can be 100% bug free (or close), without considering any rando's future request (which can expand to the thousands unrelated asks you never planned it do) as "a bug".

[AnimalMuppet]

Fair enough.

[guilhas]

Is email lack of encryption a feature or a careless bug due to lack of understanding it and it's potencial impact?