8 ms·

I am so conflicted on this! On the one hand, I fucking love it. Who hasn't experienced a backlog grooming session where you know it's impossible to reach the en

I am so conflicted on this! On the one hand, I fucking love it. Who hasn't experienced a backlog grooming session where you know it's impossible to reach the end of the backlog and you just sort of go along with the process of scraping from the top. There's definitely something miserable about that feeling. On the other hand, it's not like the issues are gone, they're just tagged differently, and if everything is just tags and organization then why not go with the flow rather than exerting control in an attempt to achieve this pseudo-perfect empty issue list. There's gotta be benefit in keeping those notes around and visible, right? Sort of feels like deciding to throw something out of your house while deep in a cleaning spree even though your subconscious is (reasonably) nagging at you to hold onto it because you might need it in the future. On the whole I think I'm for it, though, if anything just for the cathartic release and presumed re-invigoration towards new issues.

etler 3y ago
For a bit more context, the creator is doing a full rewrite. I think it would probably have been cleaner to release the rewrite first, then close all the old issues as deprecated. You could isolate the rewrite branch issues with a version tag. Closing then while the new version isn't done may lead to contributers opening new issues on the old version without realizing that it is no longer supported. But he's not just ignoring the issues and leaving problems in the code base, the entire project is getting a refresh. https://twitter.com/jdalton/status/1571863497969119238 https://twitter.com/jdalton/status/1571863497969119238
- brailsafe 3y ago
  I like it, it's the "put everything in a giant mailbag, label it, and dump it in a storage locker" approach. If the issues are still relevant, they can be resurfaced.
  - ImPostingOnHN 3y ago
    "...and when resurfaced, they will be stuffed into the 4th mailbag for further 'resurfacing'"
    - cronix 3y ago
      Return To Sender. Oh, wait...
- sneak 3y ago
  What percentage of the now closed bugs still extant in the current version will be reimplemented in the rewrite?
  - HardlyCurious 3y ago
    Requirements are hard, but ... you don't need bug reports to implement bug free requirements. So the only value the bugs would have is if they are for behaviors that should be documented as requirements.
  - irrational 3y ago
    63.19%
  - dragonwriter 3y ago
    Given the history of rewrites, I would estimate between 150-225%.
  - deleted 3y ago
    [deleted]
- scatters 3y ago
  The CADT model continues to demonstrate its relevance.
- genter 3y ago
  https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html
  - sph 3y ago
    Jamie ranted about GNOME devs because he was a few decades too early for the clown show that is frontend Javascript development. Once upon a time the noobs started with PHP and gave it a bad name with their insecure spaghetti code, now they start with React and build lovecraftian towers of abstraction that need to be rewritten from scratch every 6 months. Most of the JS frontend ecosystem is held together by people with 2 years of programming experience. EDIT: wow, the testicle-in-an-eggcup has gone. Even jwz mellows down with age...
    - erik_seaberg 3y ago
      Probably not. HN began using rel="nofollow noreferrer" in links.
    - 59nadir 3y ago
      I think it's important to highlight how the myriad of bad ideas in JS and newbies implementing them really is no fault of the newbies. It should be obvious, but I wonder whether people reading posts like these interpret them as hostile towards the newbies. It's the technically challenged pseudo-leadership out there that is to blame for most of it. The running head-first into "DX" while still consistently having some of the worst developer experience known to man as a whole and not seeing this, this is a by-product of a largely inexperienced but overvalued senior layer in the tech world that find big voices either via Twitter or more directly via pseudo-lifestyle dev channels on YouTube. Some of them flaunt credentials that would fall apart immediately in real conversations but they are the ones that host the conversation so it can't really come up. Not all dev YouTubers are like that, of course, but I'm sure a few come to mind as people are reading this. On top of the above I think people aren't considering that software is often a reflection of values[0] and that people disguising theirs as "best practices" does not make them more valid than others. It's perfectly fine to not prematurely pessimize your solutions and that often requires making choices that some people will see as wrong because they have different values, for example. This is not only fine as a personal value but many businesses reach a point fairly fast where an ever-growing part of their work is performance oriented, despite what a lot of people tend to think. Solutions that see no real use or have no plurals tend to reach this point much slower or never than solutions that do. The above is also interesting to think about; a lot of people don't value reasonably fast software because they've largely never experienced it. It's not an uncommon reaction to marvel at simple solutions that have no real optimization put into them but simply aren't written completely wastefully from the beginning, because they're so much faster than what people are used to. [0] Bryan Cantrill - Platform as a Reflection of Values: https://vimeo.com/230142234 https://vimeo.com/230142234
- digbybk 3y ago
  > No FP wrappers. That fad is over. RIP your co-workers if you introduced that headache into your codebase. Definitely not team or human friendly. Can someone comment on this from the linked tweet? I haven’t been a js dev in a long time. Is functional style dead?
  - mostlylurks 3y ago
    > Is functional style dead? No, the javascript ecosystem is just full of people who have taken some pattern that occurs frequently in functional programming, such as currying, to itself be functional programming, and thus write wrappers and overly complicated libraries to implement that feature and call it a functional wrapper or the functional version of the API, despite those features having very little to do with functional programming. Idiomatic javascript and typescript are full of functional programming, far more so than other major programming languages. Avoiding functional constructs would, in fact, make your code unidiomatic. So the functional style is about as far from dead as it could possibly be. Additionally, not only has the ecosystem been adopting a more functional style as time passes (especially due to features that have been added such as destructuring and spreading, which heavily encourage a more functional style), some of the core APIs in the standard library that used to make (pure) functional programming a bit more awkward by mutating their arguments now have pure equivalents [0][1] as well. [0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toReversed https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toSorted https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
    - recursive 3y ago
      reduce() abuse is a peeve of mine.
      - earthboundkid 3y ago
        I used to always use .forEach but now I use “of” as much as possible.
- x86x87 3y ago
  Oh yeah. This is going to turn out just fine /s No second system syndrome and whatnot. Here is an idea: write the damn thing under a new name and abandon /offer a path to migrate.
  - nine_k 3y ago
    The old version is not going anywhere. I suppose the rewritten version will be a drop-in replacement with an identical / 100% compatible interface. (Else it's not a rewrite.)
    - alexvitkov 3y ago
      Lodash was 0 value to begin with, now it's going to the realm of negative value. Can't wait to debug compatibility issues of a convenience/utility library 5 layers deep into the dependency chain.
    - adrianmsmith 3y ago
      > The old version is not going anywhere. The same can't be said about the tickets and PRs for the old version though!
    - x86x87 3y ago
      Just guessing here: I don't think it's going to be 100%. Sometimes it's not 100% even between versions of the same lib (breaking changes, major versions). If it's good enough people will start using it and the old version will just fail into obsolescence.
  - ricardobeat 3y ago
    Lodash itself started as a 'better' version of underscore.js, and ended up bloated and over-engineering exactly as the prophecy says. If anything, this 3rd system will hit the right balance :)
    - tacitusarc 3y ago
      Lodash started because underscore violated semver by releasing breaking changes as a minor version update.
layer8 3y ago
As a user, I find such a “cleanup” problematic if it means closing the issue. If the issue still exists in the product, it should remain open, for documentation, and so that users running into it can easily find it and add to it. I find it more honest if a project acknowledges that the issue exists by leaving it open. As a developer, I’d rather use a filter to hide older non-critical issues, if I’m bothered about seeing the amount of issues.
- eikenberry 3y ago
  Closed doesn't have to mean resolved and the tickets would still be available either way. Closed is IMO ideal for these tickets as ultimately it means that they aren't being looked at.
  - eternityforest 3y ago
    But they should be looked at. They aren't because we don't have infinite time every day to look at issues. If those issues are still a problem nobody will find them, they'll make new issues and lose all the previous history, unless the UI is designed to support automatically suggesting reopening an old issue instead.
    - jrmg 3y ago
      It's not necessarily true that they 'should' be looked at. Most old projects that follow the 'never close without verification' philosophy end up, eventually, with a majority of open issues not actually reflecting the current state of the project. A middle-ground might be to leave open the issues with recent activity, with the idea being that at least the ones that are affecting people the most are not swept under the rug.
      - joepie91_ 3y ago
        > Most old projects that follow the 'never close without verification' philosophy end up, eventually, with a majority of open issues not actually reflecting the current state of the project. There's a crucial question here that I find not enough people ask themselves: does that actually matter? And if yes, why? What, specifically, is the material problem caused by this situation? It often feels like people are just chasing 'inbox zero', under the assumption that "0 open issues == good", without any actual material problem being solved in the process. (Github probably isn't helping here, with their undeservedly prominent placement of the open issue count driving this sort of behaviour...)
prokopton 3y ago
Yeah, it’s why Basecamp doesn’t keep a backlog. Anything important will come up again.
- erik_seaberg 3y ago
  Only until users notice, and decide that reporting bugs isn’t a good use of time.
mattpallissard 3y ago
I'm also conflicted. On one hand I reach for it every time I'm back in JavaScript land. On the other I think that slightly less than half of this library should be in the standard library for Christ's sake.
lgrebe 3y ago
Isn't this a task that Large Language models should excell at? summarizing tickets.

etler 3y ago

For a bit more context, the creator is doing a full rewrite. I think it would probably have been cleaner to release the rewrite first, then close all the old issues as deprecated. You could isolate the rewrite branch issues with a version tag. Closing then while the new version isn't done may lead to contributers opening new issues on the old version without realizing that it is no longer supported. But he's not just ignoring the issues and leaving problems in the code base, the entire project is getting a refresh. https://twitter.com/jdalton/status/1571863497969119238 https://twitter.com/jdalton/status/1571863497969119238

brailsafe 3y ago
I like it, it's the "put everything in a giant mailbag, label it, and dump it in a storage locker" approach. If the issues are still relevant, they can be resurfaced.
- ImPostingOnHN 3y ago
  "...and when resurfaced, they will be stuffed into the 4th mailbag for further 'resurfacing'"
  - cronix 3y ago
    Return To Sender. Oh, wait...
sneak 3y ago
What percentage of the now closed bugs still extant in the current version will be reimplemented in the rewrite?
- HardlyCurious 3y ago
  Requirements are hard, but ... you don't need bug reports to implement bug free requirements. So the only value the bugs would have is if they are for behaviors that should be documented as requirements.
- irrational 3y ago
  63.19%
- dragonwriter 3y ago
  Given the history of rewrites, I would estimate between 150-225%.
- deleted 3y ago
  [deleted]
scatters 3y ago
The CADT model continues to demonstrate its relevance.
genter 3y ago
https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html
- sph 3y ago
  Jamie ranted about GNOME devs because he was a few decades too early for the clown show that is frontend Javascript development. Once upon a time the noobs started with PHP and gave it a bad name with their insecure spaghetti code, now they start with React and build lovecraftian towers of abstraction that need to be rewritten from scratch every 6 months. Most of the JS frontend ecosystem is held together by people with 2 years of programming experience. EDIT: wow, the testicle-in-an-eggcup has gone. Even jwz mellows down with age...
  - erik_seaberg 3y ago
    Probably not. HN began using rel="nofollow noreferrer" in links.
  - 59nadir 3y ago
    I think it's important to highlight how the myriad of bad ideas in JS and newbies implementing them really is no fault of the newbies. It should be obvious, but I wonder whether people reading posts like these interpret them as hostile towards the newbies. It's the technically challenged pseudo-leadership out there that is to blame for most of it. The running head-first into "DX" while still consistently having some of the worst developer experience known to man as a whole and not seeing this, this is a by-product of a largely inexperienced but overvalued senior layer in the tech world that find big voices either via Twitter or more directly via pseudo-lifestyle dev channels on YouTube. Some of them flaunt credentials that would fall apart immediately in real conversations but they are the ones that host the conversation so it can't really come up. Not all dev YouTubers are like that, of course, but I'm sure a few come to mind as people are reading this. On top of the above I think people aren't considering that software is often a reflection of values[0] and that people disguising theirs as "best practices" does not make them more valid than others. It's perfectly fine to not prematurely pessimize your solutions and that often requires making choices that some people will see as wrong because they have different values, for example. This is not only fine as a personal value but many businesses reach a point fairly fast where an ever-growing part of their work is performance oriented, despite what a lot of people tend to think. Solutions that see no real use or have no plurals tend to reach this point much slower or never than solutions that do. The above is also interesting to think about; a lot of people don't value reasonably fast software because they've largely never experienced it. It's not an uncommon reaction to marvel at simple solutions that have no real optimization put into them but simply aren't written completely wastefully from the beginning, because they're so much faster than what people are used to. [0] Bryan Cantrill - Platform as a Reflection of Values: https://vimeo.com/230142234 https://vimeo.com/230142234
digbybk 3y ago
> No FP wrappers. That fad is over. RIP your co-workers if you introduced that headache into your codebase. Definitely not team or human friendly. Can someone comment on this from the linked tweet? I haven’t been a js dev in a long time. Is functional style dead?
- mostlylurks 3y ago
  > Is functional style dead? No, the javascript ecosystem is just full of people who have taken some pattern that occurs frequently in functional programming, such as currying, to itself be functional programming, and thus write wrappers and overly complicated libraries to implement that feature and call it a functional wrapper or the functional version of the API, despite those features having very little to do with functional programming. Idiomatic javascript and typescript are full of functional programming, far more so than other major programming languages. Avoiding functional constructs would, in fact, make your code unidiomatic. So the functional style is about as far from dead as it could possibly be. Additionally, not only has the ecosystem been adopting a more functional style as time passes (especially due to features that have been added such as destructuring and spreading, which heavily encourage a more functional style), some of the core APIs in the standard library that used to make (pure) functional programming a bit more awkward by mutating their arguments now have pure equivalents [0][1] as well. [0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toReversed https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toSorted https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - recursive 3y ago
    reduce() abuse is a peeve of mine.
    - earthboundkid 3y ago
      I used to always use .forEach but now I use “of” as much as possible.
x86x87 3y ago
Oh yeah. This is going to turn out just fine /s No second system syndrome and whatnot. Here is an idea: write the damn thing under a new name and abandon /offer a path to migrate.
- nine_k 3y ago
  The old version is not going anywhere. I suppose the rewritten version will be a drop-in replacement with an identical / 100% compatible interface. (Else it's not a rewrite.)
  - alexvitkov 3y ago
    Lodash was 0 value to begin with, now it's going to the realm of negative value. Can't wait to debug compatibility issues of a convenience/utility library 5 layers deep into the dependency chain.
  - adrianmsmith 3y ago
    > The old version is not going anywhere. The same can't be said about the tickets and PRs for the old version though!
  - x86x87 3y ago
    Just guessing here: I don't think it's going to be 100%. Sometimes it's not 100% even between versions of the same lib (breaking changes, major versions). If it's good enough people will start using it and the old version will just fail into obsolescence.
- ricardobeat 3y ago
  Lodash itself started as a 'better' version of underscore.js, and ended up bloated and over-engineering exactly as the prophecy says. If anything, this 3rd system will hit the right balance :)
  - tacitusarc 3y ago
    Lodash started because underscore violated semver by releasing breaking changes as a minor version update.

layer8 3y ago

As a user, I find such a “cleanup” problematic if it means closing the issue. If the issue still exists in the product, it should remain open, for documentation, and so that users running into it can easily find it and add to it. I find it more honest if a project acknowledges that the issue exists by leaving it open. As a developer, I’d rather use a filter to hide older non-critical issues, if I’m bothered about seeing the amount of issues.

eikenberry 3y ago
Closed doesn't have to mean resolved and the tickets would still be available either way. Closed is IMO ideal for these tickets as ultimately it means that they aren't being looked at.
- eternityforest 3y ago
  But they should be looked at. They aren't because we don't have infinite time every day to look at issues. If those issues are still a problem nobody will find them, they'll make new issues and lose all the previous history, unless the UI is designed to support automatically suggesting reopening an old issue instead.
  - jrmg 3y ago
    It's not necessarily true that they 'should' be looked at. Most old projects that follow the 'never close without verification' philosophy end up, eventually, with a majority of open issues not actually reflecting the current state of the project. A middle-ground might be to leave open the issues with recent activity, with the idea being that at least the ones that are affecting people the most are not swept under the rug.
    - joepie91_ 3y ago
      > Most old projects that follow the 'never close without verification' philosophy end up, eventually, with a majority of open issues not actually reflecting the current state of the project. There's a crucial question here that I find not enough people ask themselves: does that actually matter? And if yes, why? What, specifically, is the material problem caused by this situation? It often feels like people are just chasing 'inbox zero', under the assumption that "0 open issues == good", without any actual material problem being solved in the process. (Github probably isn't helping here, with their undeservedly prominent placement of the open issue count driving this sort of behaviour...)

prokopton 3y ago

Yeah, it’s why Basecamp doesn’t keep a backlog. Anything important will come up again.

erik_seaberg 3y ago
Only until users notice, and decide that reporting bugs isn’t a good use of time.

mattpallissard 3y ago

I'm also conflicted. On one hand I reach for it every time I'm back in JavaScript land. On the other I think that slightly less than half of this library should be in the standard library for Christ's sake.

lgrebe 3y ago

Isn't this a task that Large Language models should excell at? summarizing tickets.