• 0 Posts
  • 37 Comments
Joined 1 year ago
cake
Cake day: August 18th, 2023

help-circle


  • I was a reddit Sync user and was super bummed when (large scale) API access was shut off, so I jumped on the chance to use Sync for Lemmy. It defaulted to world for signups, presumably for ease of use for migrating reddit users. Knowing that Sync already had a loyal audience that was willing to put in a little effort to migrate, it seems the dev opted to make everything as similar to the reddit UX as possible, including registration.

    Now that I’m more familiar with the fediverse, I’ve been considering migrating to a more specialized instance that matches my interests. Truthfully, though, it seems unlikely that much of anything would change if I did since I’m going to keep using the same app, so I’ve been slow to move.

    To compare this with my experience with Mastodon, I was absolutely overwhelmed by the idea of instances and really had no idea which to join, nor did I have a familiar app to work with. I figured it out eventually, but a lot of the artists I follow didn’t or didn’t have time to, so overall I haven’t spent much time on it. I’ve spent way too much time on Lemmy so far.








  • I definitely agree, but that’s true of any system. The particulars of the pitfalls may vary, but a good system can’t overpower bad management. We mitigate the stakeholder issue by having BAs that act as the liason between devs and stakeholders, knowing just enough about the dev side to manage expectations while helping to prioritize the things stakeholders want most. Our stakes are also, mercifully, pretty aware that they don’t always know what will be complex and what will be trivial, so they accept the effort we assign to items.


  • Honestly a little confused by the hatred of agile. As anything that is heavily maligned or exalted in tech, it’s a tool that may or may not work for your team and project. Personally I like agile, or at least the version of it that I’ve been exposed to. No days or weeks of design meetings, just “hey we want this feature” and it’s in an item and ready to go. I also find effort points to be one of the more fair ways to gauge dev performance.

    Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed.

    I’m not really sure how this relates to agile. A good team listens to the concerns of its members regardless of what strategy they use.

    A neverending stream of patches indicates that quality might not be what it once was, and code turning up in an unfinished or ill-considered state have all been attributed to Agile practices.

    Again, not sure how shipping with bugs is an agile issue. My understanding of “fail fast” is “try out individual features to quickly see if they work instead of including them in a large update”, not “release features as fast as possible even if they’re poorly tested and full of bugs.” Our team got itself into a “quality crisis” while using agile, but we got back out of it with the same system. It was way more about improving QA practices than the strategy itself.

    The article kinda hand waves the fact that the study was not only commissioned by Engprax, but published by the author of the book “Impact Engineering,” conveniently available on Engprax’s site. Not to say this necessarily invalidates the study, or that agile hasn’t had its fair share of cash grabs, but it makes me doubt the objectivity of the research. Granted, Ali seems like he’s no hack when it comes to engineering.