
Software Methodology: Why One Size Fits No One - bobm_kite9
https://github.com/risk-first/website/wiki/One-Size-Fits-No-One
======
olooney
Here is a (tongue-in-cheek) model I've developed. It's based on the
observation that teams who were basically competent and had an overabundance
of hard technical skills reliably delivered, while teams where hard skills
were rather thin on the ground could not deliver. To avoid this degenerating
into the tautology "only teams that can develop software can development
software" let's develop the idea a little bit:

Definition: A team member is "garage competent" if, when locked in a garage
with a computer and an internet connection (but without help or advice from
other team members,) he or she could deliver some working version of the
product single handed, given sufficient time. The model's prediction is just
this: if the number of garage competent team members is greater than the
number of other team members, then the project will be delivered. Otherwise,
the project will fail.

(In this simple version of the model described above, simple majority serves
as a proxy for control of the project. A more nuanced but harder to define
model would define "control of a project" as a weighted sum over team members
taking into account the leverage of different assigned role such as PM or
architect.)

I posit this is not just a highly predictive model, but in fact the causal
mechanism project failure: Once people who are not "garage competent" are in
control, they make reliably make decisions that will ultimately doom the
project. Try it out yourself: think of a historical project where you know the
outcomes and can estimate garage competence for each team member and see if it
makes the correct prediction.

~~~
pjc50
Deliver _what_ , though?

If you provided each garage programmer with a full waterfall aerospace grade
up front specification, you'd have a lot more success than if you just gave
them some vague post it notes. It would also ensure they produced almost
identical results.

But the upfront spec is expensive, and in itself hard to produce - the premise
of most methodologies is that iteration with real software and real customers
is actually the most effective way of producing a viable spec.

I don't think I've worked with more than one or two people who would fail to
deliver with a clear spec.

~~~
mLuby
You're getting at intuiting requirements, which I think of as a mid-level or
senior dev skill. Super important for orgs without massive product/design
resources, but it's different from this garage test.

I can certainly believe a good number of programmers couldn't, for example,
figure out how to build a database on their own, or a 3D game, work with
cryptocurrencies, or reverse-engineer an API. There's a reason FizzBuzz is
still a valuable gating test.

------
choonway
Methodologies are just like Martial Arts Types - you have so many varieties to
choose from Boxing, TKD, Judo, Muay Thai

But in a real fight, you hit with whatever you can grab onto :)

~~~
TheAceOfHearts
AFAIK, when they were all made to compete against each other in MMA it quickly
became obvious that Brazilian jiu-jitsu was top dog. Although modern MMA
definitely takes in the best techniques from each martial arts style.

Is agile the Brazilian jiu-jitsu of software development?

~~~
sifoobar
The best techniques for MMA, it's still a sport; more realistic than
traditional boxing, but then that's a pretty low bar. I've been training
martial arts for 25 years and I wouldn't put myself in there for all the money
in the world. It's brutally violent, and the most successful fighters are very
well trained and don't seem to give a shit about messing their opponents up
for life; but it still has nothing to do with martial arts.

Wrapping your legs around your opponent's waist and rolling around on the
ground for minutes ceases to be a good idea the second you leave the ring.
While breaking fingers, ribs, poking eyes, punching throats and kicking knees
and groins suddenly become viable options. In most cases; the sooner you can
get the hell out of there the better, because the risk of getting into trouble
increases fast in a street fight.

~~~
zarkov99
I am sorry but this eye poke, throat punch nonsense has been debunked over and
over again: a) those things are not nearly as devastating as they sound and b)
in a fight both people can do it, more so the person who has positional
control. Browsing youtube searching for street fights where BJJ is used is
pretty illuminating as to exactly how effective it is. Short of MMA there
isn't anything else quite as useful, though you are right that getting the
hell out is the best option if possible.

~~~
sifoobar
No it hasn't, because it works. Otherwise they wouldn't be forbidden in the
ring, would they?

There's plenty of Bullshit Do out there, no doubt. But there is also plenty of
useful knowledge and experienced teachers that you miss if you assume that
everyone who came before you was a complete idiot.

Many martial arts were honed into more or less perfection over hundreds of
years by people just as intelligent as you and me, but with generations of
experience from actual mortal combat. Living another day is a pretty good
motivation for training and evolving.

Much of that is still around, but it's not being marketed. Because it's not
what most people are looking for, it's too real and ego-killing. Because it's
barely allowed; you can't spar out in the open with real knives or swords for
example, you'll end up in a cell before you know what happened. And because
it's been Disneyfied, by people like Jack Mace and Master Wong.

Once you've spent tens of years really training martial arts, as opposed to
sports or pretending in silly uniforms; there's not going to be much to prove
any more. If there is, you're doing it wrong. I prefer not fighting, people
get hurt best case. So I can't really show you anything that looks like MMA,
because that's just not how we train. And we don't do competitions; because
there are no winners; just two banged up idiots, one happy and one sad. But
for whatever it's worth this is me with a private student 3 years ago:

[https://www.youtube.com/watch?v=wh509WKVk2M](https://www.youtube.com/watch?v=wh509WKVk2M)

~~~
zarkov99
Your point that martial arts originally came from real, life and death
experience is well taken. But wouldn't you agree that when that component is
taken out, without the hard sparing needed to keep things honest, any art will
tend to degenerate and fall prey to hucksters? See TKD in America for example.

~~~
sifoobar
I don't buy the idea that we have to pound the crap out of each other in a
ring to prove that everyone is honest about their skills.

If you want to learn anything, you definitely need to spar; but sparring is
not a competition, no one is actually trying to hurt anyone. The more
experienced your partner is, the harder you can go without risking injury.

TKD suffers from the same sports virus as MMA if you ask me; just a different,
less violent and more exotic flavor.

------
commandlinefan
Regardless of intent or documentation, I’ve never come across a methodology
that didn’t devolve into the same practice as every other methodology. The
root problem is that the people who are looking for a methodology/silver
bullet are convinced — and no amount of reality will ever convince them
otherwise — that software development can be done with 100% predictability,
just like, say, adding a garage to a house. So even XP, that explicitly states
up front that this is not possible in software, gets morphed into “agile”
which is actually a great way to manage predictable development tasks, but a
horrible way to manage software.

~~~
karmakaze
There is a move away from the capital 'A'gile processes in use with agile as
an adjective to describe how you approach problems and the development process
itself should be fluid.

~~~
ChrisSD
Which is what agile started as and was in fact the whole point. It's like
we're forever going in methodology circles:

One size doesn't fit all so we should make the development process more fluid.

Hey what a great idea! Here are some fluid methodologies I just came up with.

Woah this methodology is awesome; everybody should use it!

One size doesn't fit all so...

~~~
karmakaze
So the answer seems to be use agile to find a fit, or if that doesn't fit
other organizational requirements/abilities, then choose the least poorly
fitting process.

------
bobm_kite9
Hi,

Author here. This is a single page from the larger "Risk-First" project, about
risk in software projects.

I put the front page up a week or so ago and it was fairly well-received.
Hopefully people will enjoy a festive second-helping.

Feel free to ask anything.

~~~
zenogais
Initial thought.

This reads largely like a recapitulation of Boehm's 2003 book "Balance Agility
and Discipline" [1]. Have you read this and did this provide any inspiration
for the article?

[1]: [https://www.amazon.com/Balancing-Agility-Discipline-Guide-
Pe...](https://www.amazon.com/Balancing-Agility-Discipline-Guide-
Perplexed/dp/0321186125)

~~~
bobm_kite9
I haven’t read it but I’ll put it on my reading list, thanks.

------
lordnacho
IMO the problem with software methodologies is leaky abstraction.

There just isn't a general framework that tells you how to categorize and deal
with every issue that you come up with.

The main thing I get from the various methodologies is general philosophies.
Things like "try to get feedback incorporated quickly". Or "Identify in
advance the things that are expensive to change".

~~~
pytester
I kind of wish we applied "micro-methodologies" rather than methodologies. I
think we should be doing "import retrospectives" rather than "import scrum"
and sharing and experimenting with a diversity of approaches (e.g. various
different ways to do retros).

We're essentially treating "methodologies" as software that runs teams.
Furthermore, if we _are_ doing software we should follow the UNIX philosophy
and the bazaar rather than the cathedral.

Edit : I kind of want to make this a reality now. I've registered
[http://micromethodology.com](http://micromethodology.com) and will make it so
micromethodology.com/standup can be a place to share "how we do [x variant]
standups" via pull requests on
[https://github.com/hitchdev/micromethodology.com](https://github.com/hitchdev/micromethodology.com)

------
mml
XP wasn't a set of practices, or methodology, it was a set of principles.
"Value working software" etc. The "methodology" flows from there: only do the
things that help support the principles, get rid of everything else you can
(up to and including many of the scrum rituals/meetings).

------
pmb
"Characterizing People as First-Order, Non-Linear Components in Software
Development" knew why in 1999.

------
peterwwillis
This whole risk-world-view thing is depressing. Yes, technically the entirety
of life on this planet is managing risk. I eat food and breathe air to manage
the risk of dying from not doing so. The quality and amount of the food and
the air determine the risk factor. Am I really going to choose the food I eat
and the air I breathe based solely on risk? Or maybe, I dunno, eat the food
that tastes good and breathe air that smells clean?

Really, all of this is bullshit, because the reason we sometimes fail to
deliver software projects is humans really suck ass at dealing with
complexity. We can deal with one complex thing at a time, but once multiples
of them are all being considered at once, we just screw up constantly.

I think the way to pick any methodology is really deceptively simple: 1) look
around and see if most of you are experienced at a given methodology, and then
2) use it.

I think it's that second part that people screw up on.

~~~
bobm_kite9
I agree, maybe it does _sound_ depressing. But the food you eat and air you
breathe _are_ based on risk! Our bodies try to warn us about the bad air and
food by making it smell/taste bad. You can go ahead and eat it if you want!

I agree with you that it's nice that our bodies make things _nice_ to eat as
well as recognising nasty stuff. I wonder if there is an evolutionary reason
for that too...

Sadly, there are still some things that _don't_ taste bad but will kill you...
hidden risks of eating I guess.

I talk about Complexity Risk here: [https://github.com/risk-
first/website/wiki/Complexity-Risk](https://github.com/risk-
first/website/wiki/Complexity-Risk)

Often, Complexity is fine, but then something bites you in the ass
unexpectedly. Sounds like risk to me.

------
karmakaze
> Following a software methodology is therefore an act of trust

That's the key point from my reading. After working with the same people on
multiple products at a startup, I came to trust the product research and
design steps preceding development and the marketing and customer success.
Even if not wholly believing, I at least came to the conclusion that it was
closer to an efficient process than I could come up with.

------
Anka33
PDD is the best methodology.

(Panic Driven Development/Design)

------
ll918
Seems like bigger risk is people not following methodologies properly in the
first place.

At least that’s my experience

~~~
GuB-42
Mine too.

It can take the form of useless meetings. ex: Oh, stand up meetings sound
good, but what are we going to talk about?

Only keeping the cheap aspects. Ex: not doing formal test campaigns based on
previously defined requirements but forgetting about things like pair
programming in XP, up to date automated unit tests, etc...

~~~
chaosite
That problem is called cargo-culting. You copy the outwards appearances, not
understanding the underlying motives, yet expect the same results.

------
jmull
> ... But Replace Judgement

Well, that's not true.

A software development methodology doesn't replace judgement. If you try to
make one do so, you're probably going to end up with a mess regardless.

------
vertline3
I like just programming.

~~~
the_arun
+1

------
oldpond
"Software methodologies are all about handling risk." Not even close.
Methodologies should about creating working software with a short feedback
loop between customer and engineer. That old blue cool-aid about risk doesn't
fly anymore.

------
samirm
gross misuse of the term "methodology"

