Soon after humans started using language, they started arguing. Not every argument since that time has been beneficial; many have been of very dubious advantage to the proponents. Nevertheless, throughout history, well-intentioned people have used argument and debate to validate ideas—often improving them while doing so.
Team members argue over their ideas and proposals all the time. They use argument as a way to explore their ideas and to arrive at a consensus on what to do. If the arguments for an idea are unconvincing, then the idea is unlikely to be adopted. However, should skeptics become convinced during the argument, they almost certainly will become enthusiastic advocates for the idea. If, during the course of the argument, flaws appear in the idea, given time, teammates usually turn to repairing them. While an idea is being debated, the cut and thrust of the argument is almost guaranteed to generate new ones.
The point of arguing is to convince others, and while we are doing so, to convince ourselves. If you want to convince someone else, then of necessity, your ideas must be well formed and articulated. In other words, you have to think about them a little more and consider whether the idea will withstand the spirited—and public—scrutiny it is about to receive. We would all like to come across as knowledgeable whilst arguing, and so take more care to ensure we are presenting a rational, well-crafted idea.
The eponymous hero of this pattern won his court case through clever argument. His presentation of the case and his arguments against those of the prosecution were enough to convince the jury. Similarly, beneficial arguing in projects is not the usual bickering and disputes that go on in most offices—whose football team is the best, Mac versus Windows, and so on. It’s the meaty discussion that advances the system being built. Which design best fits the requirements? What level of security provides the best safety for stored information, yet allows the degree of needed access? And, should preventing accidental misuse by authorized users have a higher priority than preventing intrusion from outside agents since the former is more common? These, like many issues that confront a project team, are multifaceted and need to be aired and argued over if the best end-result is to emerge.
Some arguments are on a grand scale—the proponents are determining the overall look and feel of the product. The marketing people argue for a cool, uncluttered appearance; the usability expert argues for enough visible controls to make common tasks simple to do; the developers argue for pet features and against anything they think will result in an inelegant implementation.
Some arguments are about smaller-scale, but nevertheless important, issues. I sat spellbound through an argument about the best way of reducing the number of instructions in a disk access routine. Bizarrely, the proponents of this argument chose to sit on their desks and talk over the partitions of their adjoining cubicles. —JSR
Team members who argue in their search for better solutions respect each other—it is often safe to say they like each other. Otherwise, they cannot have productive argument. When an argument is flowing, team members know that the discussion and dissection of their idea is not an attack on them; it’s merely an attempt to deliver the best product in an efficient manner. But this kind of safety does not come from benevolent management or well-meaning team leaders. It comes from within: The team members know that argument is not personal, that it is not to establish a pecking order or to showcase a tiresome display of personal knowledge. It comes from knowing that other guy is your cousin Vinny. He is testing your ideas and attempting to advance them—by arguing with you.
Film still from Jonathan Lynn’s 1992 movie, My Cousin Vinny: On the stand, Mona Lisa Vito argues with lawyer Vincent Gambini. From elsewhere in the movie: “Stan, listen to me. You have to see the Gambinis in action. I mean, these people, they love to argue. I mean, they live to argue.”
Tom DeMarco gives the keynote at the OOP Konferenz 2015 in Munich, January 29, 2015.
Read Tom DeMarco's article from the July/August edition of IEEE Software: Sigil, BlueGriffon, and the Evolving Software Market.
"This war isn't going to blow anything up, only turn everything off."
Announcing the publication of the third edition of Tom DeMarco and Tim Lister's iconic text, Peopleware: Productive Projects and Teams. The book is available now from Amazon or directly from Addison Wesley. See press release on Business Wire.
Read Tom DeMarco's essay from the July/August issue of Software Magazine. It's entitled, Bells, Whistles, Power, and the Requirements Process.
The preparation course for the IREB "Certified Professional for Requirements Engineering" is now available as video training. Learn at home or any other place. Including questionnaires to prepare you for the multiple choice test.
A Sci-Fi novel from Tom DeMarco: Andronescu’s Paradox. Could this be the Apocalypse we’ve all been dreading? Or has the nineteenth century just returned for an encore? Click to find out.