Hacker News Reader

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. :)

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.

I was always told that if you can define the difference you're probably both.

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...

When I hear "geek" all I think of now is Geek Squad, i.e. IT.

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.

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.

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.

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.

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.

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.

> 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".

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.)

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.

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.

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.

"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.

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

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.

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.

> 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.

> 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.

> 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.

the problem is that several different methodologies "worked multiple times" in practice, over the time, often in the same company, and every time the managers of the era sold it as "a great innovation" and abandoned it for the new trendy fad few years later or because the new manager had different ideas and brought a different "culture" (scrum masters that charged thousands euro/day COUGH COUGH).

See many Google engineers that considered agile nonsense (for Google), no more than 3-4 years ago.

So basically it doesn't matter which one you chose.