Dude, you rock! That's my belief, and I'm sticking to it.

I think the religion/superstition analogy is a bit misplaced. I think methodologies are more like fads - the "hot" ones are usually based on a small, vocal group of people finding something they like and spreading the word. But over time they fade in popularity because they don't work for the masses.

Let's face it: writing good software is hard, so people will always be looking/hoping for better ways to do it and, to that end, will try all kinds of ideas - some reasonable and some crazy. What works for some people won't work for others. Some people will become fanatical about the things that worked for them (whether or not the technique was the casue for their success). But in the end, none of really revolutionizes the industry. Fred Brooks realized this 20 years ago when he wrote "No Silver Bullet."

https://www-inst.eecs.berkeley.edu/~maratb/readings/NoSilverBullet.html

Its just like dieting - no fad is going to make up for the obvious solution that so few can accept: eating less and exercising more. And no methodology is going to make the large number of mediocre programmers great.

Development methodologies are a like diets

I have to be honest here.... The message I'm reading in your post here Jeff doesn't sound very different at all from what I took away from Steve's. I expected his post to be out-of-the-blue and off-the-wall like the last one, but I was surprised to find that it is much more tempered.

What I saw at the heart of Steve's post is not a "methodology atheism"... it was something like maybe a "methodology agnosticism". I.e. he's not saying there's no right answer, but rather that he doesn't pretend to know what the right answer is for _you_. The right answer for you may not be the same as the right answer for the other guy. And to lift up one methodology above all others and declaim and deride the refusers is nothing but politics.

> How exactly is "staying lightweight" different from Agile?

"Staying lightweight" is a goal and a philosophy that transcends blind rule-following and rituals. "Agile" is a marketing scheme and a brand, complete with scheister salesmen and cult followings. Does this mean that Agile is worthless, or a "bad" way of staying lightweight? Certainly not. It just means it's not the One True Path, and shouldn't be treated like it is.

> I'm not sure why Steve is so uncomfortable with the idea of software development as a religion.

First off, I don't think he's uncomfortable with it being a "soft science", or a philosophy. But "religion" comes with a whole host of burdens, traps, warts, etc. With it comes zealots, Inquisitions, Crusades, heretics, martyrs, Dark Ages, "infallible" patriarchs, posturing, politics, indulgences, and so on ad infinitum.

Second, I think what Steve is really uncomfortable with the endless cycles of "the next big thing", whereby the community gets hyped up over a supposed cure-all and any "unbelievers" who happen to work better and more comfortably under a different methodology are slowly but surely ostracized. It's ridiculous. It's a tremendous waste of time and money. And it results in tremendous pressure for people were getting by just fine, thank you very much, to bend to the will of the mob, or risk ridicule, defamation, loss of status, etc., etc. Only for it to blow over in ten years or so when the next big thing takes the community by storm and we all have to change again.

It's high school stuff. And for as much as we geeks and nerds make fun of the suits for their posturing, our community is no less guilty of it. Ours just happens under the guise of methodology.

I hasten to add that my above comment should not be construed as an attempted indictment of the "Agile" philosophy, or of methodologies that happen to be little-a-agile.

Rather, it's an attempted idictment of the church model of software development. And of the evergreen schools of "if it's not working, you're not doing it right", and "if you're intentionally not using it, you're a stupid luddite".

> zealots
plenty of those
> Inquisitions
"goto has ruined you for life!"
> Crusades
Go forth and conquer foreign shops in the name of [subroutines|OOP|C++|RUP|Agile|XML|...]
> heretics
RMS
> martyrs
RMS
> Dark Ages
We're in 'em, babay!
> "infallible" patriarchs
[Knuth|Wirth|Stroustrup|RMS|Booch|Joel|...]
> posturing, politics
Yeah, plenty of those around
> indulgences
refactoring.

Here's to taking all this religion stuff literally:

https://www.TheChurchOfGoogle.org

"How exactly is "staying lightweight" different from Agile? Isn't Agile the Church of Lightweight"

Wow, that's picking a few words in the middle of a blog, and taking them out to make the author look like a doufus.

The author is not about saying that Agile is the reverse of lightweight, and you cannot honestly say that Agile is the only way of working 'lightweight' (whatever that meant that to the author). Therefore that that 'right back at you' has no meaning. A is different from B because A is not exactly equal to B.

You know, with the post on Joel and this, I think the religious persecution starts here.

Some of us are development manager, and fully in control of the development process, and are not 'peons trapped in a sausage factory' who are forced to not use Agile. No really, we decide not to.
Everyone should read Extreme Programming Refactored https://books.slashdot.org/books/04/03/24/2118215.shtml?tid=126&tid=156&tid=188&tid=192

Shog9, in that case, most human endeavors are religions. ;)

I really hope you skimmed that to provide the synopsis, Jeff. Geez, that's enormous.

"..he's not saying there's no right answer, but rather that he doesn't pretend to know what the right answer is for _you_."

I second WaterBreath. Is belief in anything that cannot be proven 'religious'? Let's break the word down:

a) The promise of a silver bullet;
b) The organization of a church around it;
c) Dogmatic faith in it.

The red herring here is c. To hold strong beliefs without proof is part of what it means to be human, so just satisfying that property doesn't constitute religion.

Neither atheism nor Yegge's position satisfy a and b. Therefore neither is a religion. Strongly believing "X is not a path to nirvana" is very different from strongly believing that "Y is the *only* path to nirvana". The latter is closed to much more than the former.

> I think the religion/superstition analogy is a bit misplaced. I think methodologies are more like fads - the "hot" ones are usually based on a small, vocal group of people finding something they like and spreading the word. But over time they fade in popularity because they don't work for the masses.

OK, I'll bite on this. We do have our fads. But how much of Steve's criticism is based on knee-jerk anti-populism and how much of his criticism is based on actual data? He's guilty of the same thing he accuses the Agile camp of. In spades!

> And to lift up one methodology above all others and declaim and deride the refusers is nothing but politics.

Agreed. Like religions, they're all correct depending on the context. That, or else you unbelievers are going to burn in hell. I pity you all.

> Shog9, in that case, most human endeavors are religions.

Pretending that we don't have our religious, politics, etc is just plain denial. A good religion/methodology is compatible with these natural human tendencies, or they'll implode under their own weight.

> Let's face it: writing good software is hard, so people will always be looking/hoping for better ways to do it and, to that end, will try all kinds of ideas - some reasonable and some crazy. What works for some people won't work for others.

I agree, but I've personally suffered so much under Waterfall throughout my entire career that I firmly believe it is a fundamentally broken methodology. Therefore, Anything But Waterfall is a worthwhile goal in and of itself. I'm not going to dictate how people should run their projects, but I can almost guarantee that Waterfall is NEVER the right choice.

> The author is not about saying that Agile is the reverse of lightweight, and you cannot honestly say that Agile is the only way of working 'lightweight' (whatever that meant that to the author). Therefore that that 'right back at you' has no meaning. A is different from B because A is not exactly equal to B.

But agile is *A WAY* of working lightweight. It's progress towards the goal, eg, away from waterfall.

I guess Steve views big-a Agile as very dogmatic and prescriptive. I don't know what kind of Pragmatic Nazis they have at Google, but I've always seen Agile as a looser set of guidelines:

https://www.agilemanifesto.org/
--
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
--

These are totally reasonable guidelines. You'd think an "Agile" team, particularly at a place supposedly as enlightened as Google, would agree as a team what they wanted to do along those guidelines.

>> Most great software developers around the world don't use Agile.
> 2. It's true that most developers don't use agile software development. That's because they're stuck in organizations that don't allow them the luxury of "staying lightweight". They're peons trapped in a sausage factory.

I would say that "most great software developers" is not exactly the same as "most developers". And I would also say that Steve meant "succesful developers" when he said "great software developers". I would also say that peons trapped in a sausage factory are rarely succesful.

Otherwise, interesting post.

Funny, but this is a lot like arguing about religion and "the soul". How can you argue something in which nobody agrees on the definition?

Do people have souls? Well what is a soul? Is it the perception of self awareness arising from a complex interaction of neurons firing, or is it some metaphysical essence that is otherworldly and is the animating force in life?

Sometimes two people will both agree that there is a "soul" but are talking about two completely different things?

Likewise, what is agile? Is it a marketing ploy set to ensnare the poor unsuspecting developer's hard-earned money? Or is it a loose set of guidenlines embodied by a manifesto and based on experience?

Another aspect of religion is if you disagree with it, you must be a zealot for the other side.

Yeah, I'm talking to you Atwood, you big-A zealot.

Great post.

I think the real problem with our industry, is that there are way too many people trying to become an authority in it. With people spouting on about methodologies and what is the best, it kind of takes the emphasis on just writing good code. I read in a forum once somebody saying "There are no longer programming languages anymore, there are only programming methodologies", I for one was really confused by this statement. I feel most developers are now more confused than ever about what is the best approach, OOP, OA, Extreme, Agile, Procedural, these words are bandied about our industry as if they are supposed to solve problems. The buzz words like code optimisation, are flung about as if we are all in great danger! It has got to the point where the Home Hobbyist programmer, is thinking more about code optimisation than actually look at the functionality of his MP3 Library organizer application.

There is a time and place for this religion, and that place is safely tucked away in file 13. Let's not let this religion do what the catholic religion did and stop scientific advancement for 200 years.

I'm only aware of one attempt to compare directly agile and "traditional" techniques side-by-side. Unsurprisingly it was at a University, where a suitable supply of cheap guinea-pigs is always available...

This link is to the PDF of their write-up...

https://www.dcs.shef.ac.uk/~fmacias/papers/maciasXP2003.pdf#search=%22sheffield%20university%20agile%22

(or Google for "Sheffield University Agile")

I read the Sheffield University study. Its interesting. (The conclusion was that they work about the same for small and medium sized projects).

However, my experience is that the larger a project is, the more important it is to have a design done up-front. (This goes for old fashioned writing, as well as software development, btw). So I could see someone making the argument that if they had studied large projects rather than small and "medium-sized" ones, they would have found Agile doing worse.

I'm on board with you Gary.

It has always bothered me how the IT industry has latched onto this whole "religion" thing. Look, we code, we juggle and process ideas, we make products and sometimes when they are good enough (or more likely, when the consumers like them enough) we sell those products and make a living. There's no great programming god to pray to. To try to equate progamming methodologies to religious practices is ridiculous. Evangelism is just the catchterm for marketing/propoganda. There's so much information about which language is best, which OS is best, what approach to take, etc. etc. that not only can you not see the forest for the trees but you don't realize why you're looking for the forest to begin with!

Programming is work, it's what we do to put meat and taters on the table. It shouldn't be a lifestyle. Sure, programmers should certainly be passionate about what they do, what they believe in as programmers, but when you get all wrapped up in a programming ideaology to the point where you are fighting about it things have gone a bit too far. It's like when you have so many meetings that the meetings are now the focal point and the reason for having the meetings to begin with has been lost in the shuffle.

> Let's not let this religion do what the catholic religion did and stop scientific advancement for 200 years.

On the other hand, there are a lot of benefits in (some) religions. And since software development is far more of an art than a science, religion is often the only thing we got!

Should we throw all of it out because of a few nuts?

Also, I clarified the wording on point 2 since there were objections, and I wasn't clear on what I meant:

--
It's true that most developers don't use agile software development. But it's not by choice. They weren't /given/ a choice. They're usually stuck in organizations that don't allow them the luxury of "staying lightweight". They're peons trapped in a sausage factory.
--

> Evangelism is just the catchterm for marketing/propoganda.

I disagree. Or at least, that's not how I've been using the term....

Marketing is a necessary evil with capitalism. And it _can_ be done honestly, by people who both truly understand and believe in what they are advocating for.

Propaganda is intentionally misdirective, even deceptive. It's intentionally divisive, creating good guys ("us") and bad guys ("them"), obscuring the middle, and trumping up false dilemmas. But it is done with a purpose in mind that need not necessarily be about power or greed. (Consider pro-Nazi propaganda vs. anti-Nazi propaganda during WWII.)

But when I call something a "religion", it is because it not only includes aspects of both marketing and propaganda, but it supercedes them. And yes, I am intentionally connoting all the negative aspects of religion, disregarding for a moment that they not all be qualities of a "real" religion. By these I mean rules from on high, mindless obeisance, inexplicable rituals, a refusal to even address opposing viewpoints other than to decry them.

A "methodology" becomes a religion when sales people are pitching it as an instant cure for your business ails (salvation). And when consultants are promoting themselves as the only safe doorway by which you can enter the world of that methodology (clergy). And when conferences are arranged that disseminate all the success stories without addressing real problems people have run into (healing and worship services). And when my coworkers start "witnessing" to me about how I should be doing X and Y on _every_ project, without considering that every project is different, and maybe X works but Y doesn't this time (born-agains).

That last paragraph does not represent Agile as originally conceived nor, I'm sure, as its founders continue to promote it. But it does represent a whole lot of other people in and around the industry. People that should stop and think about what they are trying to achieve, and decide if a given aspect of a given approach is feasible and applicable. Rather than just taking on blind faith that some practice is universally beneficial.

I think the big disconnect here is that you have a relatively broad statement (dare I say vision statement) of beliefs (e.g. the agile manifesto) and some well defined practices (e.g. pair programming, aggressive refactoring, etc.) which are both referred to by the same name. Some people disagree with the manifesto itself, either totally or in part. Others agree with the tenets of the manifesto, but don't see how the well defined practices associated with them achieve the manifesto's goals. And still others agree wholeheartedly with the manifesto and do as many of the "best practices" as are suggested by leaders of the movement.
I think one of Steve's points was that the lumping of practice+belief is a dangerous thing, and I would tend to agree. I'm more inclined to agree with the manifesto, but that's because it's broad and general enough to allow many different actual behaviors/practices/processes underneath it. I think the marrying of the agile manifesto and mandatory agile practices is that they contradict the first line of the manifesto itself: Individuals and interactions over processes and tools -- and it's this combination of practice+belief which gets alot of people bent out of shape (on both sides).
Ultimately, there's only one simple guideline: Do What Works. Whether that means agile, Agile, scrum, RUP, foo, bar, or even *gasp* waterfall, the point is at the end of the day, we're writing software and anything that gets in the way of that is bad news no matter what it's called, or where it came from. You would be foolish to ignore the lessons of previous (and other people's experience) but at the same time be foolish to assume that the context of their experience is the same as yours. Perhaps it's fitting that we developers like to framework our processes as much as our software, but that's another discussion for another time...

Jeff Atwood wrote "On the other hand, there are a lot of benefits in (some) religions."

Is there some reason to think those benefits could not have been gained without the religion? Do the benefits outweigh the costs?

Jeff Atwood wrote "And since software development is far more of an art than a science, religion is often the only thing we got!"

Software development is neither science nor art - we might sensibly ask whether it's engineering or craft.

Framing this as a discussion of religion is needlessly emotive - we're talking about dogma.

We can do better than dogma. We can instrument our development processes, and continually re-evaluate what we do based on knowledge rather than supposition.

It's interesting to watch some of the "leaders" (in the sense that they went first) of movements change over time. One gets the feeling that they find something they like and evangalize it until they find something better. In that way, software development doesn't look like religion. Kent Beck wrote about XP. XP went off the deep end and he thought about TDD separately. Dave Astels started with TDD and has moved into BDD. The thought leaders(as it were) aren't settling for finding a niche and propogating at the top of their lungs, that's for all the people that come along 5 years later and take a few truths and ideas and run them up the flagpole as righteous dogma. Like Jeff, don't settle for waterfall when there's something better out there. Don't settle for Agile (whatever that means) if you can get Google. Don't settle for Google if you can move forward.

At least each of these things are promoting some good practices with the bad. For example, some customers are becoming more aware of the crap that's been pushed off before and finally want to take responsibility for defining acceptance tests. Fantastic. This is a dream of mine: verifiable, black-and-white requirements. Sure it's painful now, but we're making progress...I think. Let's improve this until we can actually get to where we really want to be. Whether bullpens, stand-ups, cards or whatever get us there, I'm easy.

Don't forget the tools that come along with these movements. My IDE writes out method stubs for me now! It will move stuff around so it reads better and make sure I don't screw it up! If religious zealotry will get me an IDE that helps me go faster and smarterer, sign me up.

I think at the end of the day a programmer needs to produce code to do his/her job. Whether or not they go to church is another thing altogether, but I do think you need to have some sort of process/methodology to produce better code. Part of the process/methodology could include code reviews, peer reviews, small cycles of work, etc. If you have no methodology and have a bunch of programmers go off and produce something 6 months later, chances are, your project will fail. Agile and Waterfall are 2 methodologies that can be implemented and I am sure they have produced both good and bad results. I am also sure that in the coming years there will be other highly touted methodologies as well.

David wrote-
"And no methodology is going to make the large number of mediocre programmers great."

This is true, but no methodology turns mediocre programmers into a bunch sloppy hacks, and I have seen the unholy works that they have manifested. Methodology helps makes mediocre programmers better. Not everyone is a superstar, and if there is a bell curve for progammers, I bet the masses could probably use some sort of methodolgy.

My Definition of Agile (capital A) is pretty much Scrum + XP + TDD. agile (lowercase a) is lightweight among other things. I think Steve is responding to the Agile (captial A) people saying "Do Scrum + XP + TDD or you suck and your projects will fail" and yet there are clearly 1000s of projects that appear to be doing just fine without Scrum or XP or TDD.

I think it was Noel Llopis (https://www.gamesfromwithin.com) who has been promoting Agile (capital A) like crazy and yet admits compared to their non-Agile project their measured progress is 40% slower than it was with non-Agile.

He seems to believe that there's still a net win down the road because of more confidence in the codebase through TDD, better design through both TDD and XP as well as less chance of major problems if a programmer quits since XP means more than one programmer is familiar with each piece of code.

If they are 40% slower though it's certainly not guarenteed it's going to be win for them in the end. They are taking it on faith and there in lies the bad side of "religion". That the believers will convince people to do things that don't actually help and actually waste time.

I'm not saying who is right or wrong. XP sounds interesting to me having never done it. My gut feeling is, at least for *great programmers* it couldn't possibly be faster but if given the chance I'd love to try it.

TDD sounds great too, especially for libraries with lots of users. At the same time having shipped 18 commerical projects without TDD and having never had more than 4-8 weeks of bug fixes I'm not convinced the extra effort of TDD would have actually saved time in the end, at least for the specific projects I worked on.

So, again, it comes back to religion. If there was some proof that Scrum, XP and TDD worked it would be great but all we have are anecdotes, feeling and beliefs and no proof.

religion is the substitution of the rational by the supernatural. the last major one was the Dark Ages. there have been lots of mini medieval periods in Western society since the Enlightenment; the birth of eschatology (early 19th century) is among my faves.

since systems development is thought by most, even practioners, to be mostly magic; well can religion be far behind?

WaterBreath's missive was far too insightful for just message boarding; my goodness.

> In order for programmers to be effective, they have to believe in what they're doing.

This is the best sentence I have ever read in your blog.

Faith based on eg. experience is good, if there is no other scientific proof. Anyway, if there were scientific proof, then that would be just better. It is clear, that if you write self explaining code, it is easier to maintain than complex and mysterious looking code. This easier maintenancy can be measured scientifically with these two kinds of codes being maintained. And, of course, also pure intelligence can reason, that self explaining code is easier to read - hence easier to maintain, too.

Now, people trust things more, if they get some arguments for the things. Programmers may use some methods just because the methods are fun and cool. But professional programmers usually search for methods, that have good arguments for being better methods than some other ones.

I would not like agility or xp just because people believe in them. What is agility for one, may not be agility to an other. Of course you may be very "productive", if you can roam the code free and agile and do things here and there as you wish. But that is not good as such. We need agility, but we need also something that engineering needs. If we want to build agile software, we may not achieve it with plain agile programming, but we need also plans, coherency, blueprints, architecture, and so on.

An excerpt from the upcoming book, "The Bastard's Guide To XP":

The three main principles of Bastard Agile were first formulated by George Orwell in his novel '1984'.

WAR IS PEACE

Your mission as an Agile Bastard is to ensure that the iteration cycle is quick enough that no-one else ever gets their grubby little hands on the part of the product *you* broke. Therefore, keep iteration cycles short, in order to maintain enough fear and panic among your colleagues so that no-one dares question your "wisdom". It worked for Adolf Hitler and George W. Bush, and it can work for YOU too! See Chapter 4, "Tactical Refactoring: I Didn't Break It", for some valuable tips to make iterations traumatic enough so you never lose control.

FREEDOM IS SLAVERY

Bastard Agile requires the illusion of progress. Therefore, you must ensure that your methodology is omnipresent in the daily lives of your victims. See Chapter 3, "A Full Inbox Is A Happy Inbox", and Chapter 5, "Public Humiliation Is Your Best Entertainment Value", for tips on using the reams of data produced by nightly builds and unit testing suites to keep your co-workers demoralized and submissive.

IGNORANCE IS STRENGTH

Test Driven Development is supposed to help ferret out bugs early on, so it's in your best interest to learn techniques to hide your code's flaws. Chapter 6, "Obfuscating Tautologies", will help you learn to use language features to produce "tests" that do the most important thing of all -- make you look good!

I like Tim Lister's comparison of learning software development methods to learning how to swim at the olympic competitor level.

If you just throw someone into the water who has never swam before, they will either drown or dog-paddle. They will struggle to keep their whole head above water, and their legs will be far from the surface. But teach someone to swim well, and they will learn how to do the counter-intuitive things: keeping your head and legs near the surface of the water, "sipping" the air at regular intervals, and so on.

A lot of programmers think they just "naturally" know how to develop software, but they're really just dog-paddling. After I learned and practiced "counterintuitive" Agile practices like pair programming, time-boxes, and test-driven development, I found that those practices did indeed help me get software done (from feature requests to shipping shrink-wrapped boxes, not just "coding") faster and with higher quality.

I don't consider the butterfly stroke to be religious, nor do I consider practices currently labeled as "agile" to be religious, unless you count religion as being something that helps you have a productive and enjoyable life, which I suppose many people do.

> nor do I consider practices currently labeled as "agile" to be religious

Most of us, I think, are not saying that "agile" is religious. What we _are_ saying is that many people are "religious" about "Agile" (note the capitalization), sometimes fanatically so. And that _these_ people are doing neither the movement, nor the rest of the community, any favors.

Great posts.

The one thing I haven't seen you address is the question of why we even care. Why argue over which methods work best? I work in a DBUF company developing solutions with my own brand of Agile. I get away with it because the business area writes my check, not the IT area. Frankly, I hope the BDUF guys never change. They're the reason business loves me. They can complain all they want but the results speak for themselves.

I think the actual number of people "religious about Agile" is smaller than the number of people who are "religiously Anti-Agile".

We hear from the Anti-Agile people about how many "Agile Zealots" there are, but their numbers are overstated.

Most of the people that the Anti-Agile label as zealots are reasonable people just saying that Agile works for them... not being religious and not being "superstitious".

The people who have tried Agile have tried multiple development methods, but the Anti-Agile generally have not.

Everything can be overhyped (think of Java, for example, or "Object Oriented", the hype comes a few corporations, not from a lot of individuals.

There was a point lurking in my (admittedly) silly post -- Agile methodologies in the hands of the incompetent and/or malicious can do a *lot* of damage.

I do not reject Agile out of hand; I have found adopting certain Agile techniques *has* made me a better programmer. Test-driven development and the "always keep it working" mindset help me, personally, produce code that converges quickly to the desired level of functionality.

Unfortunately, what works for the individual can be harmful in an organization. It worries me that Agile proponents do not see the potential for abuse, because it happens fairly often in the real world.

Fairly twisted and uninitiated understanding of religion...

Agile is similar to religion in that once you've had a personal experience of it that unwinds your skepticism, you don't really bother looking for objective proofs of what you have become aware of through experience.

Like religion, agile practitioners constantly and rigorously test the basis of their beliefs against new experience and new learning.

That said agile is no more a superstition than religion is. Although to the uninitiated - closed heart and closed mind - religion can appear to be superstition.

Dalai Lama constantly reminds us to keep testing the teachings against experience and to receive dogma as something to be proven out through rigorous experimentation and experience. He talks about "subjective proof" as a central experience of contemplative life. Christianity calls Christians to the same, as does Islam, and a host of other contemplative traditions.

It's the fundamentalistic spinoffs of contemplative traditions that bring down the crap and lead to resistance to rational and experiential investigation - both of actual religion and actual agile development.

Self-imposed ignorance in response to fundamentalism is just more fundamentalism.

"From that perspective, the ?scientific method? of Software Engineering, at least as it is practiced at the coal-face of development, is as follows:

1. Gather anecdotal evidence from your experience, and the experience of people whose opinions are like yours.
2. Come up with a mental model that accounts for around 80% of your anecdotal evidence.
3. Come up with plausable reasons to ignore the remaining 20%.
4. Extrapolate your mental model until it applies generally. You will find carefully-chosen metaphors especially useful at this point."

-- https://fishbowl.pastiche.org/2004/01/13/the_art_of_programming