What is this logical fallacy?

Factual Questions
1

I work in software development at a large company. They’ve recently gone all “Waterfall” in processes, and almost every other day we get a directive to add some new process or procedure - “we need you to verify all the tasks are set to complete”, “we need to make sure all tasks are associated with a release, even if they’re not scheduled”, “we need you to keep track of what percentage of builds fail”.

For each of these minor process additions, the rationale is always something like, “It’s only a 5 minute job…why would that be a problem?!”

The trouble is, that due to the amount and frequency of these requests, the engineering organization is now at a point where literally hardly any software actually gets created: we measure, we plan, we design, we document, but no actual code gets written.

Anyway…back to the logical fallacy. Is there one that describes the situation where each minor element is “no big deal” but the person asserting that fails to take into account the cumulative effect? In the situation I describe, those requesting all this paperwork apparently don’t understand that there’s a cumulative affect, or have some other agenda.

Here are some I came up with, but none quite seems to capture the essence of what I described:

http://www.nizkor.org/features/fallacies/division.html - “fallacy of division”. This sort of comes close, but in reverse. You could make a fallacious argument like, “None of these individual requests is a big deal. Therefore, the overall effect isn’t a big deal.”

I’m usually pretty good at spotting logical fallacies, but this one eludes me. Of course, it could be that it isn’t a logical fallacy and I’m just pissed off with my job :slight_smile:

Or maybe even this one: http://www.nizkor.org/features/fallacies/composition.html But still, not quite spot on; the person requesting that we complete one more minor ritual isn’t saying anything about the sum of all these rituals, because they’re not even considering it. They’re just saying what they’re asking isn’t a big deal. It’s almost a corporate version of Zeno’s paradox of motion - “these requests are all so tiny, there’s no way they can add up to anything significant.”

2

My first instinct is the fallacy of composition. They are assuming that, since one small thing takes only a short amount of time, that a bunch of them still take only a small amount of time. The whole of what they are trying to do does not have the same characteristics as the parts.

3

It’s basically bad arithmetic. It could qualify as the fallacy of quantification, similar to Zeno’s paradox. They seem to be saying that you could do an infinite number of very small tasks in finite time. It probably includes a flat-out falsehood, because I doubt the tasks actually take only 5 minutes. It does illustrate one of the problems of Waterfall Development though, that the initial phase is too complex to complete in a reasonable amount of time, and the second phase can never be started, or the flow can’t remain unidirectional. It’s the typical kind of thing where ignorant management doesn’t understand that every idea is not feasible, and some small changes in design can require large changes in implementation. I kind of though this concept was totally abandoned in software development, but then thinking about your post, I realize I can point to several companies practicing this method, and how stressed their employees are. Of course management frequently has to break their own development model when the project inevitably becomes overdue, and far too late in the process to actually recover the lost time. In a way, it is the antithesis of bottom up implementation based on resolving the most critical issues of implementation first in the process of development. I used to spend a lot of time explaining to companies the difference between what they want, and what they need. But I got tired of it, and could make more money letting them screw things up first, increasing the value of providing what they need.

4

Fallacy of the Beard, isn’t it? One hair doesn’t make a beard, if you don’t currently have a beard one more won’t make it one, therefore it’s impossible to have a beard. Similarly, one five-minute task won’t overburden you; you are (presumably) never at any point where you are currently not overburdened but will be as a result of one more five-minute task; therefore you cannot be overburdened by any number of five-minute tasks.

5

I don’t know if these are “classical” fallacies, but the “Propaganda” game (from the Wff’n’Proof publishers) had “Drawing the Line” and “Not Drawing the Line.”

The fallacy in the OP sounds like “Not Drawing the Line.” (Which is pretty much the same as Malacandra’s Fallacy of the Beard."

The fallacy of “Drawing the Line” is something like bureaucratic pedantry. “There is a word misspelled on your application to emigrate, so we are not letting you leave the country.”

Having too much resilience…and having too little…are both operational fallacies, even if they aren’t formal “rhetorical” fallacies.

Trinopus

6

I agree with Malacandra. It’s also known as the fallacy of the heap or the continuum fallacy that you put in your OP. But I also want to point out the longshot-favorite bias. It’s a little backward in that people prefer to take long odds, but in your case, your bosses are rounding down. They’re saying that 5 minutes = 0 minutes. It’s the same as when people are playing, say, Fallout and they miss a shot that has a 98% success rate and go “How could that miss?! It’s a guaranteed hit!”

7

Wow…quit posting what’s in my head! This really nails it. This is worthy of a new thread in MPSIMS, if you’d like to discuss further. We are currently in the middle of a release that has been in planning for a year, and is supposed to be released four months from now. Yep, not a single line of code written, but a mountain of documentation. We are still having a half dozen status meetings a week (where the same items are discussed redundantly – different “stakeholders” each want status, and refuse to get it from each other), and people are expected to provide the same information in written status reports on the wiki. It’s like a hellish combination of Office Space, Dilbert, Brazil and Kafka. Yes, I am polishing my resume :slight_smile:

8

Programmer here.

Let me say this so it is clear.

Waterfall doesn’t work. Development is cyclical in real life (requirements, design, implement, test, bugs, design, implement, test, new requirements, design, implement…) and a quarter to a half or more of the requirements are going to change (or be discovered to have been different all along) by the time you are half implemented.

And please tell me you aren’t filling out forms for the sake of filling out forms (CMMI anyone?). I’ve seen too many instances where people were filling out process forms (e.g. role matrices) that are full of information that is obvious, useless, or both, and then the form gets disregarded during actual development.

9

And what, pray tell, is going to be DONE with these metrics? File them? Or does management have a quantitative improvement plan in store, or <shudder> are these going to be used for performance evaluations?

I was in a development environment where we kept metrics on estimation versus actual time. Actual time was significantly over estimates. We just kept the metrics in a database and did nothing but talk about how we need to improve. Nothing terribly constructive.

10

Pretty much this. The metrics are gathered (obsessively – heaven help you if you’re late or incomplete), summarized, dumbed-down for PowerPoint presentations to the execs…then, more or less nothing. Occasionally a Decree will come back down the chain that we should “review why build x has been broken 60% of the time”. It usually turns out to be a problem with the CI system, or a known issue.

We also have to report time hourly, officially for two reasons: the Finance group requires it, and so that our effort can be compared with the offshore team for similar tasks. The latter never happens – the data gets filed away, as you described, never to be reviewed again. Worse, I work with a lot of really smart people, and they tend to bristle at being told to account for every hour of their day; the result is that people tend to put anything that will fit in their timesheets, just to get management off their backs. So the metrics are meaningless anyway.

The kicker is that I have a management position, so I’m forced to be an “enforcer”. I have to constantly nag people to collect these meaningless, unread, useless metrics, to fill out their timesheets and count how many minutes they spend in the bathroom. (The last one is a bit of an exaggeration…for now.) I’ve had many discussions with my boss about how I don’t think this is the best way to produce quality, working software on time and within budget, but he seems to have drunk the Kool Aid and started hinting that there are plenty of other jobs out there, so nowadays I bite my tongue.

The latest thing is the whole “Six Sigma” compliance program. Out of the blue, Big Cheese Exec decreed that everyone shall be “green belt” certified in Six Sigma. One of the worst two hours of my life - I got something like 10% on the final “test”, and was told I was a “green belt” anyway. At the beginning of the class the instructor said that he and Big Cheese Exec had worked at the same company for years. BCE had called him up and asked him if he wanted a job instituting Six Sigma at our present company, and he took it. Everyone hates it, and feels it is common sense, bottled up and sold. (“The first thing is to listen to the customer”, “never do any work that isn’t worth it” - yes, literally.) Before the class, I googled for information on Six Sigma and several of the hits in the first couple of pages were for Dilbert strips - not a good sign.

Ack…sorry to get off on a rant. As you can probably tell, I’m passionate about what I do, and this stuff really rubs me the wrong way.

Thanks to those who responded to the OP. I agree that it’s somewhere between Continuum Fallacy and Composition Fallacy. I wasn’t aware of the “longshot-favorite” bias but it makes perfect sense. I’m sure when my boss asks me to verify why the burndown chart isn’t a perfect 45° slope, he’s assuming it will be closer to zero than to five minutes of effort.

It’s cathartic just discussing this stuff with you guys. It helps remind me that there are others out there who don’t revel in pointless paperwork and reports.

11

I think the posh, technical name for it is the sorites paradox.

The example given in Wikipedia is about removing grains of sand from a heap. But a similar example concerned with adding grains - one grain is not a heap, adding one more grain will not create a heap, so no matter how many grains you add you never get a heap of sand - is logically equivalent, and more obviously analogous to what you are talking about.

12

I like “sorites paradox”. I call it the breakdown of mathematical induction.

Dilbert has this happening all the time.

13

At a psychological rather than logical level this could also be viewed as a problem of egocentrism: I have given you a five minute task, what’s the problem? The fact that you have a heap of other five minute tasks from a heap of other people is not something I bother to take into account.

14

This is spot on. My boss refuses to acknowledge that I have a dozen or more other people asking for “5 minute tasks”. It’s actually worse: he doesn’t even “sum over his own requests”, as if it was a different person who asked me to do A,B, and C last week, when in fact it was him.