The Sonny Corleone School of Argument

February 22, 2011 — Posted by Scott Bain

Are you afraid of being proven wrong? I'll bet you are. Or, if not afraid, at least you are not keen on demonstrating your lack of knowledge about something, especially anything having to do with your job. Who can blame you?

Software development is among other things an intellectual business. Most people who do it are pretty smart and, more to the point are paid to be smart. As a result, most of them hate to lose an argument because this, in their thinking, points out a potential lack in their smarts and therefore represents a pretty dangerous challenge to their value… and perhaps their job security.

This probably has a lot to do with why most arguments between or among developers about certain design decisions, whether or not to try a new approach, technique, or technology, the relative value of different implementation options, etc… can get very intense and seem to have no end or resolution.

This also probably has a lot to do with why developers neither like to ask questions nor attempt to answer instructor questions in the classroom. To ask a question is to reveal a lack of knowledge; to attempt to answer the instructor's question is to risk getting the answer wrong. This has sometimes made things very challenging for me when I am teaching; what can I do to get technical folks to participate in the course, and therefore to get the most out of it?

To resolve this requires a rethinking and reframing (refactoring?) of what a question is, and who wins an argument when it is over. I call this the "Sonny Corleone School of Argument."

I trust most people reading this have seen "The Godfather", but whether you have or not, I will describe a well-known scene from the film:

Vito Corleone is The Godfather, a well-established mafia don, and Sonny is his eldest son. They are in a meeting with an up-and-coming mobster named Sollotzzo who is trying to convince Vito to come in with him in an illegal narcotics venture. Vito resists this idea as being far too risky, and Sollotzzo ensures him that another mob boss will guarantee the investment should anything go wrong. Sonny immediately challenges the credibility of this, and Vito cuts him off sharply in mid-sentence. He then apologizes to Sollotzzo saying "I have a sentimental weakness for my children, and I spoil them as you can see; they talk when they should listen."

When the meeting has concluded and Vito and Sonny are alone, Vito rebukes Sonny saying "never tell anyone outside the family what you're thinking again." The point Vito is making is that the winner in a verbal conflict is the one who gains information.

So, let's say that you and I are having a technical argument. I say that C# constrained generics are exactly like templates in C++. You say this is not true. As the argument progresses it becomes clear that you are indeed correct. Generics and templates are not exactly the same, and in fact have some significant differences. So, you were right and I was wrong.

Who "won" the argument?

If winning is gaining information, then I say the winner is me. I lacked the distinctions between generics and templates but now I no longer lack them. You, on the other hand, know exactly what you knew when we started the argument. You have not gained anything.

Of course most people would say you won the argument, because you showed me up, displayed your superiority, something like that. But I claim this is a purely empty and rather petty victory, whereas my victory has real substance, and actually contributes to my value in the context of my job. I'll take that all day long.

So, when we disagree, we should always look for the information to be gained. As The Godfather taught Sonny; what you know makes you powerful, and any gain in knowledge is a gain in power. (BTW: I'm not saying everything in Sonny's life is to be recommended. Things don't turn out so well for him at the end of the day…)

Finally, if you are attending a course (and perhaps paying for the privilege of doing so) please consider that the value of the time you are committing to the course is extremely valuable, and thus you should want value from the training that is at least commensurate with the value of your time. Finding out the gaps in your knowledge or discovering a useful approach that you had not previously considered is exactly what you want to happen. If you already knew everything the instructor has to tell you, then clearly you'd be better off spending your time in another way.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Scott Bain

Scott Bain is an consultant, trainer, and author who specializes in Test-Driven Development, Design Patterns, and Emergent Design.


That's cute and all, but the whole winning vs. loosing thing when applied to argumentation and debate actually has nothing to do with being right or wrong. If winning an argument doesn't make you right, then turning that on its head (as this blog explains) doesn't give you new information.

It's a pretty important distinction to make in my opinion. Just because someone can convince others, doesn't mean what they're saying is true or accurate. A correlation to that is of course that just because you can't convince others doesn't mean that what you're saying is NOT true.

What if we continued arguing about the C++ vs. C# templates/generics things and I decided that I was wrong. Then in this case you've not learned anything, in fact you've become more convinced of your error, and I now know less than I did before. If I where to conclude that the "winner" of the argument is the person who comes out with more information then of course everyone lost. The problem here is, I think, more about the misperception that winning an argument means you're right.

If we enter into argument not equating winning/losing with truth then we aren't as likely to fall prey to that problem. If I lose the argument then either I am wrong, or I need to be more familiar with my position.

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban