* Posts by alfmel

7 publicly visible posts • joined 5 Jun 2024

Rust for Linux maintainer steps down in frustration with 'nontechnical nonsense'

alfmel

I agree with with many of the things that have been said here, especially about the added burden of maintaining data structures in multiple languages. I also see two human behaviors (as opposed to technical hurdles) that muddy the discussion.

The first is language preclusion: when a developer refuses to work in languages other than his/her preferred language. I can understand a developer becoming incredibly proficient in one language. Unfortunately superb understanding of a language is often accompanied by elitism and snobbery. Ted Tso's comment about "forc[ing] all of us to learn Rust" strikes me as a bit elitist, taking credibility away from the technical argument of increased maintenance burdens.

The second is attachment to our work. When you pour your heart and soul into producing something, it is natural to feel proud and protective of that work. Early in my career I would become so protective I impeded progress and damaged my reputation with other developers and management. I eventually learned to let go and lead, rather than mandate how things should be. I have unfortunately seen many cases both in my work and in my Open Source contributions where maintainers become overprotective and impede progress. I'm not suggesting Rust is the right direction the kernel should take. I am merely restating that being over-protective is one of the reasons disruptive innovation often comes from the outside.

Fragile Agile development model is a symptom, not a source, of project failure

alfmel

Well said!

Study finds 268% higher failure rates for Agile software projects

alfmel

YES! And that having all the all the requirements (like the exact colors we want to use) doesn't have to happen to start coding. And I think that's the real problem: everyone hears what they want to hear when they hear the word agile: "I can write bad code that I'll fix later." "I don't have to write tests." "I don't have to figure out what we are doing now, I can do it later." "I don't need to document anything." "I am guaranteed success even though I don't know anything about the project I am managing."

alfmel

Re: Next Week

> Never in their list of principles do they explain in detail how to do any of the things they suggest

Because Agile is a set of principles (what/why) not a methodology (how). One of its core principles is that those doing the work determine HOW they will do it most efficiently. Watch or read Martin Fowler's (one of the authors of the Agile Manifesto) view on the Agile Industrial Complex and why they purposefully avoided the issue of HOW.

alfmel

Your comment shows you don't really know what Agile is, and that people have stuck an "agile" label on your projects without knowing what it was either. Agile is a set of principles, not a "rinse and repeat" process. It's not even a project management methodology! One of its principles is working software. If it doesn't work because you did it really fast and only half-tested it, then you are not Agile; you are an undisciplined and unprofessional developer.

alfmel

Re: Next Week

If you're read The Mythical Man Month you can see what the Agile authors meant by "comprehensive documentation." And also, they final assertion in the Manifesto is that there is more value on the things on the LEFT but it doesn't mean there is no value on the things on the RIGHT. If good documentation is necessary for success in your project, why would you let a misunderstood "methodology" kill a requirement? (And Agile is principles, not a project management methodology.)

alfmel

The comments prove Agile is misunderstood

Queue Martin Fowler's State of Agile Software in 2018 talk right now! All these comments prove to me Agile is highly misunderstood.

TL;DR: Maybe instead of blaming your failure on all the principles you violated, you should blame your incompetence! If your "agile" project fails, you were not Agile.

Agile is a set of principles, NOT a project management process or methodology. Scrum is NOT Agile. Kanban is NOT Agile. Agile is 12 simple principles. Apply those principles well, you'll be successful.

For example, one is having self-organizing teams, meaning the teams decide the best process to get the work done. If your "agile" project is failing, then you didn't organize well, did you? And if you noticed you were failing and didn't adjust your processes, you violated the self-reflection/tuning principle too.

Something else that doesn't align in my head is the methodology for choosing what constitutes a "failure" or a "late" delivery. Interestingly enough, the Agile principles NEVER discuss estimating, timelines, etc. And since the primary measure of progress in Agile is working software, how do you manage to never have anything working along the way and expect on-time and successful delivery?

As to testing, Agile focuses on working software. How do you know it's working if you don't test it in one way or another? Attributing any excuse for poor testing to Agile is simply an excuse for unprofessional work. Bad testing practices are an organizational problem, not an Agile problem.

Finally, I have seen many organizations hire contractors that don't care about what they are building and only do what's on the task to collect a pay check. As such they don't ask questions, they don't see the Big Picture and they don't care about quality. How do organizations expect a good ROI from these hiring decisions? This violates the "motivated individuals" Agile principle.

So, you thought Agile was something it wasn't, you stuck the agile label on your project without knowing what the meant, things failed and you blame the principles you didn't follow? Seriously?

And yes, I have seen great successes throughout my software development career from a proper application of Agile principles. I wouldn't do it any other way. All failures I've seen come from several violations to the Agile principles.