1. 26
  1.  

  2. 20

    To some degree, I feel the same about open source. The brand won big time, but not because it truly disrupted software development, but because big tech could not completely shut free software down and so they embraced a toned down version of it and, one marketing campaign at a time (eg Microsoft ❤️ Open Source), they progressively diluted it even more.

    1. 6

      This reminds me of a recent talk by Bruce Perens where he essentially says that open-source is just “you” doing free work for big corps ; but hey you get a free code-forge to share the code you wrote in your free IDE, often in your free time. /s

      1. 1

        As the other Kristof, I have to ask, was open source a poison pill “dilution” of free software, or is it that more people were more interested in licenses compatible with proprietary software and so open source was inevitably going to win out over free software in the end?

        1. 3

          License compatibly is not the difference, the licenses are the same (there is a 100% overlap between free software and open source licenses) the difference is in focus on user / kind of user. Free Software thinks “how can we empower everyday computer users” and open source thinks “how can I get more eyes in this library”, broadly speaking.

          1. 1

            there is a 100% overlap between free software and open source licenses

            I’m not sure if you understand what I’m saying. Proprietary software is compatible with open source software. Proprietary software is not compatible with free software (your software inherently becomes free, i.e. you must give customers the source code if they ask for it).

            1. 1

              your software inherently becomes free, i.e. you must give customers the source code if they ask for it

              Are you talking about copyleft? Because that’s not the same thing as Free Software. copyleft licenses are also valid open source licenses also, and non-copyleft licenses are often recommended by the Free Software Foundation for various purposes.

              1. 1

                Yes, I am talking about copyleft licenses. I’ve always interpreted “free” to mean “free as in libre”. I did not know the fsf ever recommended non copyleft except as a reluctant compromise to business realities.

                1. 1

                  Yeah, “free as in libre” is well-defined and does not mean the same thing as copyleft. Free, libre, Free Software, all defined by the FSF or the GNU community have always included copylefted works of course, but nothing about the four freedoms requires copyleft. Rather, copyleft is one of many strategies to use in our effort to bring freedom to the world.

                  The difference between Freedom and Open Source is one of philosophy and practise, not one of licensing. The OSI and the FSF publish almost identical license lists. The differences are even fading since usually half or more of the OSI board is freedom fighters these days. But in general the main thing is that a library meant for professional developer use is probably “open source” whereas an application or system that gives end users their freedom is “Free Software”. There are other ways to characterize this philosophical difference of course, but that’s one easy one.

      2. 8

        This reminds me of one of my favorite blog posts of all time: You can’t tell people anything. This is a must-read for every new project leader on my team.

        It’s just so hard to go from not knowing a thing to knowing that thing without having actually done the thing. Systemization of a process can help scale new processes a bit. But at the end of the day, organizations are made of people, and no amount of process or systems or tools will save you from people who don’t get it. Your people have to get it first, then the systems and processes come after as a way to scale the learnings of those people.

        (For the equivalent idea on the technical design side, see Programming as Theory Building.)

        1. 10

          The first point to highlight is that these were practitioners. They weren’t project managers or CTOs or VP Engs. They were developers, programmers, scientists, and engineers. (…) In some ways, Agile was a grassroots labor movement. It certainly started with the practitioners on the ground and got pushed upwards into management.

          Uh, no. All the original Agile manifesto signatories had consulting businesses. Not a single one of these people was an ‘ordinary developer’, and considering they were overwhelmingly thirty- and forty-somethings, if they ever worked as developers, it must’ve been for a short time. They were making money telling management how to run projects, and they basically got together and refined their sales pitch.

          This is the single most offensive thing about Agile, that it has been sold to management as something the workers want, thereby excusing management from listening to what their employees actually have to say.

          1. 2

            This is one of the main problems with Agile as I see it. It’s great for a small dev shop that can actually have “Product Owners” that are actually going to receive and use the product on a daily basis. For software shops that do contract work, this kind of thinking is probably a godsend, However…

            Every commercial software shop I’ve ever worked for builds a relatively large product, or suite of products, and the “Product Owner” becomes a middle-management hack that takes the requirements from management, and tries to push it through to the dev team. They don’t actually communicate the needs of the eventual users of the product, they just communicate what management wants.

            1. 2

              One of the most “Agile” projects I’ve worked on were Line of Business apps where there was almost no management involvement, and we got direct feedback from the people actually using them. A few half-hour sessions gave us more usable feedback than months of the usual discussion about UX mockups, functional requirements, etc.

              In Agile’s defense, the Chrysler C3 project, the supposed founding event of the Agile philosophy (even though the project ended up late and was cancelled) was such a line-of-business app.

          2. 5

            I’m guessing I’m one of not that many developers who has gone through the waterfall-to-agile transition multiple times, at several different companies.

            I like a lot about agile. First, emphasizing automated testing was huge. Developers have always liked writing tests, but we didn’t have a way to prove to our managers that it was important, first-tier work. Second, I loved getting rid of overly complicated project plans, and just switching to a backlog with small/medium/large tasks. The up-front project plans were never made in consultation with the people doing the work, and became increasingly divorced from reality as time went on.

            There are plenty of things I dislike, too. When a company switches to agile, they tend to end up with a whole fleet of project managers, product managers, product owners, scrum masters, consultants, etc. – all with questionable credentials and who charge a staggering amount of money. Worse, when a company switches to agile, they tend to lay off or fire all their most experienced developers, who are narrow subject matter experts and don’t fit cleanly into a team. This has almost universally disastrous results.

            I think agile played a huge role in getting traditional business-people to take software seriously, and assign adequate resource to it. But it’s also a tremendously destructive force that can destroy functioning organizations. I wouldn’t necessarily call it a failure, but it’s not a straightforward success either.

            1. 1

              When a company switches to agile, they tend to end up with a whole fleet of project managers, product managers, product owners, scrum masters, consultants, etc. – all with questionable credentials and who charge a staggering amount of money. Worse, when a company switches to agile, they tend to lay off or fire all their most experienced developers, who are narrow subject matter experts and don’t fit cleanly into a team. This has almost universally disastrous results.

              I’ve never “switched to agile” but these kinds of problems smell like exactly the kind of agile-not-agile failure mode that the article is talking about

              1. 2

                Seconding: Firing developers in order to hire more managers sounds like the exact opposite of Individuals and interactions over processes and tools and Responding to change over following a plan.

                The No True Scotsman Fallacy doesn’t apply if the “Scotsman” in question turns out to be German.

                1. 2

                  Honestly, No True Scotsman is wildly over-applied, and when a term has been co-opted it’s even stickier. Maybe “true agile” or “true OOP” are uncommon, but since they do exist and are wildly different from their pop-sci variants then either they need their own new names or something. Saying “ah, well, in practise agile doesn’t work because no one can do it” when you’re only willing to include in the analysis people who aren’t even trying or have no idea what they should be trying, is basically a fallacy the reverse of No True Scotsman.

            2. 8

              Agile is like object orientation and communism – good only if toned way down from how it is taught, and mostly a warning sign:

              • “We do that here” → GTFO
              • “We adapt it as far as it makes sense – mostly not – together with better ways to achieve the same goals” → /* fallthrough */
              • “We don’t do that here” → Be relieved
              1. 10

                Agile is like object orientation and communism, in that some people like it and some people dislike an entirely different thing.

              2. 1

                I read the full article last night, and I struggled with the author’s ability to both explain why agile failed, even saying sentences like:

                Trying to scale a methodology that focuses on individuals and interactions will inevitably lead to problems – and erode the original value of the methodology.

                And then somehow forgetting this just a few paragraphs later:

                Jeffries in the article mentioned above, says, “However, the values and principles of the Manifesto for Agile Software Development still offer the best way I know to build software, and based on my long and varied experience, I’d follow those values and principles no matter what method the larger organization used.”

                I agree.

                The vast majority of people are employed buy businesses that are larger than one team. In fact, in many cases even when the business does only have one team, they desperately need to be able to scale to two teams if they want to succeed in the market.

                If agile can’t describe how a team functioning with agile interacts with the organization they are a part of, I don’t see how “studying the founding principles” leads to anything different. Management by Objectives/OKRs have been adopted successfully because they specifically address the intersection of the organization and your customers.

                Under no circumstances would I touch scrum/agile/whatever without deep understanding of how I tell my boss, my board, my investors what the fuck I’m doing.

                1. 1

                  Having deep visibility into “what I’m doing” is a core principle of Agile and is supposed to be the carrot we use to get management (or clients, whoever owns the product vision) to buy in. The contrast is vs waterfall where you have no idea what anyone is doing but you know what you told them to do.

                  Also, while I hate OKRs with the fire of a thousand stars, they are not incompatible with agile and don’t even really cover the same management surface area. Goal setting is totally fine.

                  1. 1

                    Does visibility into “what I’m doing” relate to how you work in a team of 100+?

                    The entire article discusses this tension, but I don’t see the direction/follow up as to why inspecting the core agile values will bring clarity to managing an organization making significant software, rather than client/consultant relationships.

                    1. 1

                      If your org has teams of 100+ you may have lower hanging fruit to fix before digging into workflow. Even at some if the biggest companies in the tech industry with some of the least-agile workflows I’ve ever had to work with, I never worked with team over ~20

                      1. 1

                        Ah, I should have said “group” or “product” instead of team. I’m saying that teams of ~10 combine together to be a team of 100+ for a single product. Anything even mildly complex (say, a website for reserving hotel rooms) can end up easily with that much engineering investment.

                        I’m frustrated with agile folks like this author who say SAFe etc are inherently wrong/evil/failure, but at the same time don’t address the problem they attempt to solve - interactions between internal teams.

                        A concrete example. Team A’s Feature A requires Team B’s Feature B to be complete before they can ship. All these “scaled agile” things are meant to help communicate that plan between teams, but this author specifically says these don’t work. Ok - great, but then at the end they say we should just.. stick with agile anyways?