Ah, I see how my wording was confusing. I mean planning in the sense of “How will we complete the work that we already committed to?” and “What will we do today to achieve our Sprint goal?”

I arrived at the word planning because Scrum is sometimes described as a planning-planning-feedback-feedback cycle. You plan the Sprint, you plan daily (Daily Scrums), you get feedback on your work (Sprint Review), and you get feedback on your process (Sprint Retrospective).

lol I hope your standups are not actually like this! The purpose is to, as a team, plan what the team will do today to achieve the Sprint goal

On mobile atm but there’s the Princeton books on Computer Science

I agree with you: the FSF can seem unwavering in their stance, even in the face of practicality. I’m really sorry for this incredibly nit-picky detail, but I think practicality is ideological too. For better or for worse, we can’t escape ideas or be free from them, so we have to choose which we value. For example, while I tend to choose software freedom over practicality, I also have, at times, chosen practicality over freedom.

Agile is indeed more of a mindset than a rigid system. In my recent experience helping a tabletop game team, we applied Agile principles to great effect. Rather than trying to perfect every aspect of the game at once, we focused on rapidly iterating the core mechanics based on player feedback. This allowed us to validate the fundamental concept quickly before investing time in peripheral elements like the looks of the game.

This approach embodies the Agile value of ‘working product over comprehensive documentation’ - or in our case, ‘playable game over polished components’. By prioritizing what matters most to players right now, we’re able to learn and adapt much more efficiently.

Agile thinking helps us stay flexible and responsive, whether we’re developing software or board games. It’s about delivering value incrementally and being ready to pivot based on real-world feedback.

I appreciate your candor about not wanting to speak on topics outside your expertise. That’s commendable. I wonder if we can still talk with the understanding that we may not know it all. I truly believe curiosity is able to sidestep many of the problems related with ignorance.

You’re right to be cautious about appeals to authority. My intention wasn’t to suggest NASA’s use of Agile validates it universally, but rather to counter the OP comic’s implication that Agile is inherently incapable of achieving significant goals like space exploration.

Regarding Agile-like practices in earlier NASA projects, you’re correct that concrete evidence is limited. However, we can analyze their approaches through the lens of Agile principles. Scrum, for instance, aims to foster characteristics found in high-performing teams: clear goals, information saturation, rapid feedback loops, adaptability to changing requirements, and effective collaboration. These elements aren’t exclusive to Scrum or even to modern Agile methodologies. The key is recognizing that effective project management often naturally gravitates towards these principles, whether formally adopting Agile or not.

It’s an interesting area for further research: have complex engineering projects historically incorporated elements we now associate with Agile? If so, how?

Your skepticism is valuable in pushing for a more nuanced understanding of project management across different domains.

I can see you’re frustrated by the downvotes and pushback you’ve received. It’s understandable to feel defensive when your viewpoint isn’t well-received. I appreciate you sharing your perspective, even if it goes against the majority opinion here.

Your points about the space shuttle program’s challenges are valid and worth discussing. It’s important to note the timeframes involved though. The shuttle was developed in the 1970s, well before agile methodologies emerged in the 1990s and 2000s.

Interestingly, one could argue that NASA may have used agile-like practices in the space shuttle program, even if they weren’t labeled as such at the time. However, I did a quick search and couldn’t find much concrete evidence to support this idea. It’s an intriguing area that might merit further research.

Regarding modern agile approaches, while no method is perfect, many organizations have found them helpful for improving flexibility and delivering value incrementally. NASA’s recent use of agile for certain projects shows they’re open to evolving their methods.

I’m curious to hear more about your thoughts on software development approaches for complex engineering projects. What do you see as the pros and cons of different methodologies? Your insights could add a lot to this discussion.

Edgy meme: agile bad

NASA: “Yep, we use agile” https://ntrs.nasa.gov/api/citations/20160006387/downloads/20160006387.pdf?attachment=true

Your comparison is interesting, but let’s consider some historical facts. The Apollo program, which successfully put humans on the moon, actually employed many principles we now associate with Agile methodologies.

Contrary to popular belief, it wasn’t a straightforward Waterfall process. NASA used frequent feedback (akin to daily Scrums), self-organizing teams, stable interfaces so that teams are an independent path to production, and iterative development cycles - core Agile practices. In fact, Mariana Mazzucato’s book Mission Economy provides fascinating insights into how the moon landing project incorporated elements remarkably similar to modern Agile approaches. Furthermore, here’s a NASA article detailing how Agile practices are used to send a rover to the moon: https://ntrs.nasa.gov/api/citations/20160006387/downloads/20160006387.pdf?attachment=true

While it’s true that building rockets isn’t identical to software development, the underlying principles of flexibility, collaboration, and rapid iteration proved crucial to the missions’ success. Programs like the Apollo program adapted constantly to new challenges, much like Agile teams do today.

Regarding Kanban and Scrum, you’re right that they fall under the Agile umbrella. However, each offers unique tools that can be valuable in different contexts, even outside of software.

Perhaps instead of dismissing Agile outright for hardware projects, we could explore how its principles might be adapted to improve complex engineering endeavors. After all, if it helped us reach the moon and, decades later, send rovers to it, it might have more applications than we initially assume.

The article’s “valuing your time” argument is problematic in certain contexts. My brother has had so much trouble with his dual-boot (Windows and Linux). Yes, he could learn how to solve something in Linux every time a problem arises, but he also has to deliver his projects on time. Because of that, he mostly spends time on his Windows dual boot. Yeah, it sucks ethically and has its own pragmatic issues, but he has never had issues resolving dependencies or hunting down the most recent version that can actually be run in NixOS.

I don’t doubt these will become issues that will not be as problematic in the future, but right now my brother cannot use Linux reliably for his assignments.

Edit: My brother has tried what I use: Fedora and NixOS. He has also tried PopOS.

In Fedora, he found some of his software didn’t exist as .deb, and struggled to make .tar files work smoothly for him.

He tried NixOS afterward. He really liked the whole immutability thing, as well as the idea that apps would have their own dependencies.

His dependency problem happened in PopOS. If I remember correctly, it was a code editor that required a version of something that was different to what a package he used in his software was.

I think the order he tried was Fedora -> NixOS -> PopOS -> NixOS -> ? (Haven’t talked to him about it recently)

I agree. And that’s exactly my point 😅

Frame challenge: to avoid mass surveillance, a good FLOSS E2EE app ✌️😎

Ah. This makes sense! Thanks!

I’m not sure adblockers change the OS they report. Other tools I know for a fact do it.

Edit: However, as @aebletrae@hexbear.net mentions, adblockers don’t have to change what OS is reported to change the overall statistics. They explain how in a comment below.

Veloren is written in Rust and is inspired by Zelda Breath of The Wild. Both of those are relatively recent.

“Elections”, " representative", and “federal” could exclude many non-American and non-Canadian countries.

Edit: Oh, silly me. I misread. I thought you wanted to exclude American stuff, not “political” stuff. Well that’s another conversation. Is there something that is not political? Is there something that doesn’t comment on the distributions of political goods such as significance, relevance, resource allocations (including time and attention), or value judgments?

I know encapsulation is desirable in part because of security. I figured something similar could happen by removing the ability to import anything from another program. However, I struggled to think about other situations in which no imports were desirable, and so I wondered…

Just in case OP doesn’t know, this whole text comes from someone else. Some people prefer using words other than GNU/Linux.

I see how majority judgement could be seen as a subset of range or score voting.

A crucial difference between range/score voting and majority judgement is that one uses numbers and the others judgements. A majority judgement ballot could list all the possible candidates or options, and for each of them, there’d be a list of possible judgements. You can say that you consider a candidate “terrible”, “bad”, “meh”, “good”, “amazing”.

The idea is that humans tend to think in terms of judgements more readily than with numbers. A good ballot would find what words evoke useful judgements for candidates, as each group of voters has its own social language.

For example, with my partner we have a list of movies that we vote on. We have judgements that include “I’ll leave the house if you play that sh*t”, or “Omg yes!”. It’s great to add a movie to the list and find that one of the judgements in our made up ballot matches our personal judgements so well!

This is something I think majority judgement can do better than range/score voting: it can reflect human judgements better than with scores. In that way, it is more intuitive than range/score voting.

One benefit of majority judgement is that leaders chosen through it would know the judgement that they came into power with. If someone is elected into a powerful role knowing that half of the voters think they’re “ideal” for the job, that’s quite different than knowing that they were elected with half the voters thinking they were “inadequate”. This means, ideally, that the legitimacy of incompetent leaders can be reduced.

Note that the amount of possible judgements in a ballot can vary. To make things quick and easy, I’ve had silly elections with three judgements, such as “nope”, “ok”, “omg yes”. I’ve also had elections with nine judgements.

If you want to reduce the probability of having multiple winners, more judgements are a good idea. In general, the amount of judgements should depend on what the stakes are (higher stakes should go beyond just a couple of judgements), how many options there are (few options require few judgements), and the amount of voters there are (few voters require many judgements).

I think the reason for using the median is so that a judgement can be chosen as representative of each candidate. In the “nope”, “ok”, “omg yes” example above, if the median of the winning candidate is 3, you can tell the candidate that the score that they were chosen with was “omg yes”. If the average of the winning candidate is 2.4, you can’t really translate that as succintly, given that 2.4 is between “ok” and “omg yes”.

I hope it’s clearer why I love this voting method!

Do you know about majority judgement? If you know about it or check it out, what do you think about it? What do you wonder about it? Do you want to challenge something about it? What would you want to explore about it?