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.

There’s a fair bit of bias in the terms “restrictive” and “permissive”, which make MIT seem like a ‘better’ choice than a give-and-take license like GPL.

The truth is, MIT is risky for developers. Using just one line from an MIT-licensed project will automatically allow others to exploit your work without giving back. I’d prefer to advocate for balanced licenses that protect both user and developer interests.

We are at risk

of losing many developers who would otherwise choose a license like the GPL. Fortunately, I’m glad to be surrounded by people, just like you, who care about licenses like GPL. By uploading this type of content and engaging with it, be show our commitment to it. I wish to suggest how we can deal with this threat.

We will lose developers who choose GPL if we use words that suggest GPL is “restrictive”. Sure, the word “restrictive” was avoided in this meme by using the word “copyleft”, but the cognitive jump from “permissive” to “restrictive” is minimal: just add an “opposite” and you’ve got “permissive is the opposite to restrictive”. It really is that simple. That’s how brain works (check out Relational Frame Theory to see how that works).

So what can we do about it?

Well, we can approach this with science. There is a historical global trend towards people being more meta-cognitive. That means that people are becoming more aware of how our thoughts interpret everyday reality and how to be intentional with our relationship with our thoughts so that we live better lives. We know this trend is happening to virtually everyone everywhere because of the work of brilliant sociologists like Anthony Giddens and Christian Welzel. Heck, even the history of psychology —going from noticing and changing behaviors (behaviorism) to noticing and changing behaviors and thoughts (cognitive-behaviorism), to noticing and changing the context and function of behaviors, thoughts, and emotions (functional contextualism)— reflects this trend.

We can use meta-cognition in our favor; we can use the meta-cognitive tool of framing to change how we think about GPL and MIT licenses. Effective communicators like influencers, political campaign experts, and influential activists use framing all the time. For example, instead of using the dangerous framing that suggests GPL is ‘restrictive’, we can use another one that truly displays the virtues of the license.

What would this other frame look like? I may not have a perfect answer, but here are some

ways of framing (thinking about) the relationship between licenses like GPL and MIT:

(ironically!!!, these were ‘suggested’ by an LLM; I wonder if these frames already existed)

• “Investment-Protecting Licenses” vs. “Investment-Risking Licenses” (as in developers invest by working on projects that they could (not) lose the ability to contribute to)
• “Community-Resource-Guarding Licenses” vs. “Exploitation-Vulnerable Licenses”
• “Give-and-Take Licenses” vs. “Take-and-Keep Licenses” ⭐
• “Freedom-Ensuring Licenses” vs. “Freedom-Risking Licenses” ⭐
• “Contribution-Rewarding Licenses” vs. “Contribution-Exploiting Licenses”
• “Open-Source-Preserving Licenses” vs. “Closed-Source-Enabling Licenses”

I’d be happy to hear what you think, including suggestions!

You could check out NixOS :)

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?

This is what I did, from NixOS to Debian. I managed to end up with a dependency conflict in less than a day, precisely the problem that NixOS attempts to solve. I came back to NixOS and accepted my fate: asking for help from the NixOS community.