4 ms·

They don't work because they're pseudoscience. Just because a methodology appears to work for one or even multiple organizations doesn't mean it's going to wor

They don't work because they're pseudoscience. Just because a methodology appears to work for one or even multiple organizations doesn't mean it's going to work in every case. No one actually knows that FrAgile, SCUM, or TeeDeeDee are universally better than just having a bunch of programmers self-organize. There's no well controlled studies that show anything other than a weak association between hip methodologies and measures like productivity or profit, and no one has demonstrated actual cause and effect. That probably won't happen because these are purely human systems, and good luck controlling for that. It's fine to consider methodologies, but there's no reason to believe that the people who invented or tout said methodologies should be blindly trusted. They discovered something that they believe worked for them, and that's it. They're not smarter than you. Only use aspects of methodologies that you would use or that you have seen work, and don't do anything that seems stupid or that you would dread.

daveslash 4y ago
That's right. Plenty of great software has been developed by the "lock a smart, creative, determined nerd who's _obsessed_ with his/her product in a garage for a month" methodology. Folks who have bought into the vision of the project and are motivated to "do it right, make it good" have a much higher chance of a successful product than a team who are attending the religious ceremonies and cargo-culting. These methodologies are like painted-lines and highway-signs; they can be great guidelines, but ultimately the driver has to want to avoid getting into an accident and aware enough to realize blindly following the lines/signs won't achieve that on its own. Edit: *I use "nerd" here as a term of affection, not derogatorily. I proudly call myself a nerd. :)
- ROTMetro 4y ago
  I gotta gatekeep this. When did nerd and geek switch places? Since the 90s, geeks and nerds are two totally different things. Geek: a person who is knowledgeable about and obsessively interested in a particular subject, especially one that is technical or of specialist or niche interest. "a computer geek" I'm a proud geek, but after bullying as a kid calling me a nerd is fighting words. A geek nowadays socially ranks above the people that tried to stand above others by calling them nerds, turning labels into strength.
  - detaro 4y ago
    I was always told that if you can define the difference you're probably both.
  - daveslash 4y ago
    Looks like maybe you got some downvotes - but not from me. Geek & Nerd can be sensitive labels for the likes of folk who hang out here on HN. I wasn't trying to start a flame-war. But I'm happy to discuss it further. Speaking for myself (and myself only), I'm proud of both labels and more-or-less treat them as interchangeable in regards to usage by the general public. Though, I have my-own thoughts on the differences. I take neither as an insult or fighting-word unless, of course, it's obviously being hurled as one, in which case it's not the word, per-se, it's the antagonist as a whole...
  - userbinator 4y ago
    When I hear "geek" all I think of now is Geek Squad, i.e. IT.
- Raidion 4y ago
  Plenty of software that doesn't actually solve the goal and ends up being unmaintainable also comes out of locking a bunch of smart people in a room. You make it too complicated, no one can modify it without tons of domain knowledge, you make it too abstract and flexible and the abstraction leaks and the flexibility means a ton of extra time spent. You can really only lock devs in a room if you have very very clear product expectations and a longer term vision that allows people to add flexibility where it's needed for future projects. This simply won't happen with most companies because that's HARD.
- stickfigure 4y ago
  If your development methodology requires smart, creative, determined geniuses who are obsessed with your product... you will not be able to scale your organization beyond the founding team.
_a_a_a_ 4y ago
> Just because a methodology appears to work for one or even multiple organizations doesn't mean it's going to work in every case the only justification for a thing is if it works. If they regularly do, as you just acknowledged they do multiple times, they're of value. > and no one has demonstrated actual cause and effect If repeated success S correlates with repeated use of methodology M, that's a damn strong sign of causation, and if it isn't, I'd still use it. Actually your whole post is so relentlessly negative and petty (SCUM? FrAgile?) I won't give it credence. I personally use for my own projects TDD and plenty of comments in my code and it works (or correlates if you prefer...) very well with good results.
- ravenstine 4y ago
  > Actually your whole post is so relentlessly negative and petty (SCUM? FrAgile?) I won't give it credence. Have a sense of humor. If TDD works for you, continue using it. I've done TDD before and sometimes still do. Sometimes people are negative for a reason. I've seen enough iterations of these methodologies that I don't think they have any special value. Should a cattle ranch be more "agile?" Maybe, but honestly, I doubt that would end well. That's an extreme example, but even different software products may not necessitate the same workflows that these methodologies are intended to create. The point is there isn't necessarily anything in particular about any of these loosely related methodologies that makes them special or effective for everything. In fact, they fail to live up to their promise quite often because they're treated as if they've been proven to be more effective than hypothetical alternatives, which simply isn't true. > the only justification for a thing is if it works. If they regularly do, as you just acknowledged they do multiple times, they're of value. Yes. However, I've personally never been with an organization that actually attempted to measure whether a methodology was working or not. My guess is, the vast majority of the time, methodologies are a magic talisman to ward off the bad C-level spirits and bring good fortune to middle management, and sometimes make it look like more work is being done than is actually. I'm sure those organizations exist, but if they are actually willing to do such honest self assessment, they're probably capable of arriving at the same place without needing a pre-built methodology to start with.
- peoplefromibiza 4y ago
thescriptkiddie 4y ago
I would go as far as to say that management methodologies in general are pseudoscience. Nobody knows how to do it, but some powerful people get paid a lot of money to pretend that they do.
Thaxll 4y ago
"better than just having a bunch of programmers self-organize" The problem is right there, most people are not organized. To do coding for sure, to scope things, evaluate, prioritize etc ... not so sure.
- no_wizard 4y ago
  Inevitably in any group someone will emerge as the central organizer. I think the idea is that it should allow to happen naturally. If truly no one is able to get a team organized I’d say treat it as an exception rather than a rule and figure out what is hold the team back from being more organized
  - siva7 4y ago
    Sure, someone will emerge. I've seen that scenario happen over and over. Will the result be good? No, not in a single case i observed because managing a software product is a distinct art which too many software developers believe goes naturally hand-in-hand with their coding skills.
    - no_wizard 4y ago
      Note I mean organize, not manage a product. Team organization isn't the same thing as managing a product. Self organization is about teams having autonomy to organize and plan units of work and drive the teams forward. This isn't some magical vacuum where the business has no input on what those things are, and you very likely should have some distinct product management that engineers aren't in charge of.
thegrimmest 4y ago
Seems as though this is rephrasing the old adage from small-a-agile "Individuals and interactions over processes and tools". Until we normalize asking "who is problem?" rather than "what's wrong with our process?" we're doomed to miss the mark. Excising counterproductive individuals will make any process work well. Discussing methodologies in isolation from individuals is a waste of time.
- AnimalMuppet 4y ago
  Interesting, but I'm not sure I agree. Your approach could easily degenerate into hunting for the scapegoat-for-this-reporting-cycle. But I will say that agile (real agile, not agile-in-name-only) demands quite a bit of discipline and maturity from your people. If you don't have the people for it, it won't work.
  - HardlyCurious 4y ago
    Any methodology that requires discipline to work is a bad methodology. Trying hard ALWAYS works. That is how work got done before agile existed. The goal is to find a methodology that brings ease. So you can stop putting effort into the organization and meta work and instead put more effort into the work that actually brings value.
  - thegrimmest 4y ago
    I think the costs of avoiding individual-oriented conversations are higher. Asking "which process is the problem" is rarely the issue. I can think of two sane guardrails that are usually applied for large-scale collaboration: 1) your team's code must have a clear, sane, documented interface/API 2) all teams should have a homogenous intake process for requests for change Everything else becomes a matter of either priority or performance. These areas are where changes have real impact, so it's better to focus the conversation there. > agile demands quite a bit of discipline I'd say small-a-agile requires more discipline from managers rather than staff/line employees. Namely, discipline to refrain from imposing significant process overhead on their teams so they have a better feeling of control and predictability. Manager-driven, observability-oriented process changes seldom give managers more actual control. Instead, managers should embrace the uncertainty that comes with software development, demand only to see real progress on working code in short intervals (no milestones, delivery dates, etc.), and set ambitious goals for their teams only in these intervals.
randomdata 4y ago
> No one actually knows that FrAgile ... are universally better than just having a bunch of programmers self-organize. Huh? The entire Agile Manifesto is about how programmers should just self-organize as they see fit and highlights some key areas that developers need to be consider in the absence of a manager who would traditionally coordinate things, such as "talk to the business people".
- dragonwriter 4y ago
  The problem is that “Agile” can mean: * Applying the principles of the Agile Manifesto, or * Top-down semi-ritualistic application of a canned methodology, usually some variant of either SAFe or Scrum (but rarely, in the latter case, much like the version in The Scrum Guide, but instead something that played telephone through many layers of consultants, distant managers, and the direct manager of the team, is poorly documented, and changes arbitrarily via management fiat based on outside influences without team input.)
- mcguire 4y ago
  An entertainment for a rainy afternoon: track down the signatories of the Agile Manifesto and count how many of them were most recently selling tools, processes, and/or consulting for agile software development methodologies.
  - randomdata 4y ago
    In fairness, the signatories and even the Agile Manifesto itself admits that it takes a special kind of person to thrive in an environment free of management. It is abundantly clear that you are making a mistake if you venture into Agile if your team is not comprised of those special people. It makes sense that something else will be needed for 90%+ of the remaining organizations happy to have been able to hire anyone for the job. And, well, make hay when the sun is shining, as they say.

daveslash 4y ago

That's right. Plenty of great software has been developed by the "lock a smart, creative, determined nerd who's _obsessed_ with his/her product in a garage for a month" methodology. Folks who have bought into the vision of the project and are motivated to "do it right, make it good" have a much higher chance of a successful product than a team who are attending the religious ceremonies and cargo-culting. These methodologies are like painted-lines and highway-signs; they can be great guidelines, but ultimately the driver has to want to avoid getting into an accident and aware enough to realize blindly following the lines/signs won't achieve that on its own. Edit: *I use "nerd" here as a term of affection, not derogatorily. I proudly call myself a nerd. :)

ROTMetro 4y ago
I gotta gatekeep this. When did nerd and geek switch places? Since the 90s, geeks and nerds are two totally different things. Geek: a person who is knowledgeable about and obsessively interested in a particular subject, especially one that is technical or of specialist or niche interest. "a computer geek" I'm a proud geek, but after bullying as a kid calling me a nerd is fighting words. A geek nowadays socially ranks above the people that tried to stand above others by calling them nerds, turning labels into strength.
- detaro 4y ago
  I was always told that if you can define the difference you're probably both.
- daveslash 4y ago
  Looks like maybe you got some downvotes - but not from me. Geek & Nerd can be sensitive labels for the likes of folk who hang out here on HN. I wasn't trying to start a flame-war. But I'm happy to discuss it further. Speaking for myself (and myself only), I'm proud of both labels and more-or-less treat them as interchangeable in regards to usage by the general public. Though, I have my-own thoughts on the differences. I take neither as an insult or fighting-word unless, of course, it's obviously being hurled as one, in which case it's not the word, per-se, it's the antagonist as a whole...
- userbinator 4y ago
  When I hear "geek" all I think of now is Geek Squad, i.e. IT.
Raidion 4y ago
Plenty of software that doesn't actually solve the goal and ends up being unmaintainable also comes out of locking a bunch of smart people in a room. You make it too complicated, no one can modify it without tons of domain knowledge, you make it too abstract and flexible and the abstraction leaks and the flexibility means a ton of extra time spent. You can really only lock devs in a room if you have very very clear product expectations and a longer term vision that allows people to add flexibility where it's needed for future projects. This simply won't happen with most companies because that's HARD.
stickfigure 4y ago
If your development methodology requires smart, creative, determined geniuses who are obsessed with your product... you will not be able to scale your organization beyond the founding team.

_a_a_a_ 4y ago

> Just because a methodology appears to work for one or even multiple organizations doesn't mean it's going to work in every case the only justification for a thing is if it works. If they regularly do, as you just acknowledged they do multiple times, they're of value. > and no one has demonstrated actual cause and effect If repeated success S correlates with repeated use of methodology M, that's a damn strong sign of causation, and if it isn't, I'd still use it. Actually your whole post is so relentlessly negative and petty (SCUM? FrAgile?) I won't give it credence. I personally use for my own projects TDD and plenty of comments in my code and it works (or correlates if you prefer...) very well with good results.

ravenstine 4y ago
> Actually your whole post is so relentlessly negative and petty (SCUM? FrAgile?) I won't give it credence. Have a sense of humor. If TDD works for you, continue using it. I've done TDD before and sometimes still do. Sometimes people are negative for a reason. I've seen enough iterations of these methodologies that I don't think they have any special value. Should a cattle ranch be more "agile?" Maybe, but honestly, I doubt that would end well. That's an extreme example, but even different software products may not necessitate the same workflows that these methodologies are intended to create. The point is there isn't necessarily anything in particular about any of these loosely related methodologies that makes them special or effective for everything. In fact, they fail to live up to their promise quite often because they're treated as if they've been proven to be more effective than hypothetical alternatives, which simply isn't true. > the only justification for a thing is if it works. If they regularly do, as you just acknowledged they do multiple times, they're of value. Yes. However, I've personally never been with an organization that actually attempted to measure whether a methodology was working or not. My guess is, the vast majority of the time, methodologies are a magic talisman to ward off the bad C-level spirits and bring good fortune to middle management, and sometimes make it look like more work is being done than is actually. I'm sure those organizations exist, but if they are actually willing to do such honest self assessment, they're probably capable of arriving at the same place without needing a pre-built methodology to start with.
peoplefromibiza 4y ago

thescriptkiddie 4y ago

I would go as far as to say that management methodologies in general are pseudoscience. Nobody knows how to do it, but some powerful people get paid a lot of money to pretend that they do.

Thaxll 4y ago

"better than just having a bunch of programmers self-organize" The problem is right there, most people are not organized. To do coding for sure, to scope things, evaluate, prioritize etc ... not so sure.

no_wizard 4y ago
Inevitably in any group someone will emerge as the central organizer. I think the idea is that it should allow to happen naturally. If truly no one is able to get a team organized I’d say treat it as an exception rather than a rule and figure out what is hold the team back from being more organized
- siva7 4y ago
  Sure, someone will emerge. I've seen that scenario happen over and over. Will the result be good? No, not in a single case i observed because managing a software product is a distinct art which too many software developers believe goes naturally hand-in-hand with their coding skills.
  - no_wizard 4y ago
    Note I mean organize, not manage a product. Team organization isn't the same thing as managing a product. Self organization is about teams having autonomy to organize and plan units of work and drive the teams forward. This isn't some magical vacuum where the business has no input on what those things are, and you very likely should have some distinct product management that engineers aren't in charge of.

thegrimmest 4y ago

Seems as though this is rephrasing the old adage from small-a-agile "Individuals and interactions over processes and tools". Until we normalize asking "who is problem?" rather than "what's wrong with our process?" we're doomed to miss the mark. Excising counterproductive individuals will make any process work well. Discussing methodologies in isolation from individuals is a waste of time.

AnimalMuppet 4y ago
Interesting, but I'm not sure I agree. Your approach could easily degenerate into hunting for the scapegoat-for-this-reporting-cycle. But I will say that agile (real agile, not agile-in-name-only) demands quite a bit of discipline and maturity from your people. If you don't have the people for it, it won't work.
- HardlyCurious 4y ago
  Any methodology that requires discipline to work is a bad methodology. Trying hard ALWAYS works. That is how work got done before agile existed. The goal is to find a methodology that brings ease. So you can stop putting effort into the organization and meta work and instead put more effort into the work that actually brings value.
- thegrimmest 4y ago
  I think the costs of avoiding individual-oriented conversations are higher. Asking "which process is the problem" is rarely the issue. I can think of two sane guardrails that are usually applied for large-scale collaboration: 1) your team's code must have a clear, sane, documented interface/API 2) all teams should have a homogenous intake process for requests for change Everything else becomes a matter of either priority or performance. These areas are where changes have real impact, so it's better to focus the conversation there. > agile demands quite a bit of discipline I'd say small-a-agile requires more discipline from managers rather than staff/line employees. Namely, discipline to refrain from imposing significant process overhead on their teams so they have a better feeling of control and predictability. Manager-driven, observability-oriented process changes seldom give managers more actual control. Instead, managers should embrace the uncertainty that comes with software development, demand only to see real progress on working code in short intervals (no milestones, delivery dates, etc.), and set ambitious goals for their teams only in these intervals.

randomdata 4y ago

> No one actually knows that FrAgile ... are universally better than just having a bunch of programmers self-organize. Huh? The entire Agile Manifesto is about how programmers should just self-organize as they see fit and highlights some key areas that developers need to be consider in the absence of a manager who would traditionally coordinate things, such as "talk to the business people".

dragonwriter 4y ago
The problem is that “Agile” can mean: * Applying the principles of the Agile Manifesto, or * Top-down semi-ritualistic application of a canned methodology, usually some variant of either SAFe or Scrum (but rarely, in the latter case, much like the version in The Scrum Guide, but instead something that played telephone through many layers of consultants, distant managers, and the direct manager of the team, is poorly documented, and changes arbitrarily via management fiat based on outside influences without team input.)
mcguire 4y ago
An entertainment for a rainy afternoon: track down the signatories of the Agile Manifesto and count how many of them were most recently selling tools, processes, and/or consulting for agile software development methodologies.
- randomdata 4y ago
  In fairness, the signatories and even the Agile Manifesto itself admits that it takes a special kind of person to thrive in an environment free of management. It is abundantly clear that you are making a mistake if you venture into Agile if your team is not comprised of those special people. It makes sense that something else will be needed for 90%+ of the remaining organizations happy to have been able to hire anyone for the job. And, well, make hay when the sun is shining, as they say.