The Parkinson’s Law of Triviality is a real thing (more on this later). And for Computer Science researchers, it is part of everyday life. As we know, research is a very time-consuming activity. There are uncertain tasks that typically take a lot of time to complete. This state of things often fuels procrastination and slows progress down to the minimum, making the research harder to complete. Certainty, researcher are always busy working hard, doing tasks, having meetings, creating reports, and looking at deadlines. But being busy with the wrong activities is harmful, and the Law of Triviality turns the focus away from priorities. In this post, I will cover the repercussion of Parkinson’s Law for researchers and share my experience gained after many years of dealing with it.

Statements

Parkinson’s Law (also known as bikeshedding)¹ states that work expands to fill the time allowed for it. The term was coined as a metaphor by Cyril Northcote Parkinson’s and stated in 1957. Parkinson’s argues that people within an organization typically give disproportionate weight to trivial issues. For example, while it can be fun and engaging to discuss what the title of a paper should be (everyone has an opinion), this is a form of procrastination. Let me said again, our job as researchers is to produce research artifacts, not to generate never-ending discussion. As Marc Andreessen wrote: “we will be judged by what we (and our code) have done, not the meta-discussion that went on around it.” So the next time you feel yourself getting drawn into a protracted “what name should it be” discussion, consider stop it, and see if you can produce some research artifact instead.

“Work expands to fill the time available for its completion.” – Parkinson’s Law

The Parkinson’s book, written in the 50s, originates the principle, and it is an excellent satire on the ineffectiveness of bureaucracy. The book describes how “an elderly lady of leisure can spend the entire day writing and dispatching a postcard to her niece.” In contrast, if all she has is five minutes to write a postcard, she would take just five minutes to do so. At a higher level, this idea applies to many situations. For example, people’s belongings expand to fill the house’s space, and consumption level grows to drain their whole income. In the Computer Science world: the demand for computing power (from software) expands to fill the hardware capabilities available.

“The time spent on any item of the agenda will be in inverse proportion to the sum (of money) involved.” – Corollary from Parkinson’s Law

Parkinson explains how committees spend their time when discussing budget matters. He points out an example in which a group of decision takers discusses the budget for a nuclear reactor. None of those committees knows much about nuclear reactors. Therefore, there’s not much to discuss regarding a $10 million proposal for the new reactor. Consequently, the proposal is approved within minutes. On the other hand, most of the committee members know about bicycle sheds. Thus, they can have a lively debate on how to cut costs on a proposed bicycle shed for employees. Similarly, everyone knows about coffee. So naturally, they’ll have the most prolonged, best-informed debate on whether to get a new coffee machine. Penny-wise but pound-foolish.

The law is fulfilled by disinterested observation of any organization. The book goes far beyond its famous theorem, though. The author explains how to meet the most important people at a social gathering and why, as a matter of mathematical certainty, the time spent debating an issue is inversely proportional to its objective importance. Justly famous for over forty years, Parkinson’s Law is a bracingly cynical primer on the reality of human organizations and an inoculation against the wilful optimism that we as humans become prone to.

“Politicians and taxpayers have assumed (with occasional phases of doubt) that a rising total in the number of civil servants must reflect a growing volume of work to be done. The fact is that the number of officials and the quantity of the work are not related to each other at all. The rise in the total of those employed is governed by Parkinson’s Law and would be much the same whether the volume of the work were to increase, diminish, or even disappear.” – Parkinson’s book

In the Computer Science research arena, the fantasy of having infinite time for producing research artifacts (e.g., experimental data or a written research paper) is unrealistic, to say the least. The experimental protocol and software development will take the time allocated to it if it’s realistic or be late if it’s optimistic. Parkinson’sParkinson’s law also operates with the cost in terms of human/hours of development. It usually ends up draining all the budget available.

I have often lost the focus of my research by wasting precious time on activities that can be measured but are not priorities. Like a magician using misdirection, my projects get busy with the trivial and lose sight. The Law of Triviality explains why I focus on trivial activities on purpose, skimming over complex problems I don’t want to work in. The plan fails every time I don’t progress with the deliverables on the critical path. As usual, a project is delivered when the slowest part of it is delivered.

For researchers, the problem is spending disproportionate amounts of time discussing trivial parts of a research problem instead of focusing on more important aspects. Everyone who has spent some time in academia has seen this behavior in one form or another. Serious decisions require in-depth conversations and thorough discussions. But often, we pick a minor or controversial topic detail and dive into it instead.

If a researcher falls victim to this, she may spend massive amounts of time discussing small implementation details that may not impact the research output. The amount of discussion a subject receives is inversely proportional to its importance. This issue is rife in the software industry (and, of course, every other industry), and agonizing hours have been wasted debating or worrying about matters that ultimately have little relevance.

Examples

Postponing the Writing

Let’s say that you have to write a section of a paper and have one day to do it. Firstly, you write the title of the section and start thinking about its content (i.e., the number of paragraphs, the figures, etc.). Since you have one entire day, you want to write the section as perfectly as possible. So you perhaps grab a cup of coffee, talk with your colleague in the corridor, and figure out the perfect ideas for every sentence. At the end of the day, and due to the high expectations, it is 5:00 pm, and you are still writing the section.

Now imagine that you have only one hour to write the same section instead of one day. You realize that there is no time for coffee or corridor conversations. So you skip both and focus on the essential task. You stop focusing too much on the quality of the content and just start writing a couple of sentences at a time. In doing so, you have broken the ice quickly by written one sentence after the other. Then you split the sentences into paragraphs, add minor edits, and rearrange everything to fit the main idea. Finally, you get the job done in one hour. The written section is imperfect, of course, but you know that not a single section will ever be perfect after the first shot.

%%{init: {'theme':'base'}}%%
flowchart TB;
a(["Need to Write"]) --> q{Bikeshedding?}
q -- Yes --> x["Do Something Else"]
q -- No --> z["Add One Sentence"]
x["Do Something Else"] --> a(["Need to Write"])
z["Add One Sentence"] --> z["Add One Sentence"]
z["Add One Sentence"] --> e["Edit"]
e["Edit"] --> r(["Get the First Version Ready"])

The takeaway here is that you should not spend too much time on the quality of the writing. It is an iterative task by nature. Refinement comes later. So, don’t allow yourself too much time for its completion.

Over-Engineering Tools

The Law of Triviality could also manifest as over-engineering in the research context. As researchers, we aim to understand the research problem and give a well-founded output. To do so, we use (and sometimes create) tools to aid the research process. It is common for Computer Science researchers to spend a lot of time on over-engineering tools. This behavior is often unnecessary, as research tools are not production-ready software products. Research tools are meant to be used to prove or refute a hypothesis. It is the hypothesis that matters the most.

Thus, there’s a fine line between tool implementation and planning/overthinking. Spending too much time on small implementation details can leave us paralyzed and unable to advance on the research project. I have seen this happening when trying to make the software more generic than it should be. We want to keep our options open if we change the project scope later. To do so, we add unnecessary abstractions and use complicated architectures. This will not save the researcher if the initial hypothesis is wrong.

%%{init: {'theme':'base'}}%%
flowchart TB;
a(["Research Hypothesis"]) --> b["Need a Software Tool"] 
b["Need a Software Tool"] --> c["Implement the Tool"]
c["Implement the Tool"] --> q{Bikeshedding?}
q -- Yes --> x["Optimize/Test/Improve the Tool"]
q -- No --> z["Run Experiments"]
x["Optimize/Test/Improve the Tool"] --> z["Run Experiments"]
z["Run Experiments"] --> e(["Write the Paper"])

In general, unnecessary time spent on tooling is another way to postpone the writing. Also, it makes the work harder in the future, as good tools need to be maintained. In reality, a tool is often easier to improve later, once the paper is submitted, rather than trying to make it good from the beginning. No one knows how the paper will change in the future after peer review. So we are left with an overcomplicated project that we don’t have the time budget to simplify. The solution is the same: implement something that “just” works.

Over-Meeting

Collective research projects are plagued by subsets of researchers spending time on trivial tasks that they can contribute to. As individuals, we tend to avoid making high decisions and taking responsibilities alone. Thus, decision driven by meetings and “democratic agreement” is a typical strategy. This explodes the law of triviality into the chaos of unfruitful meetings.

Meetings with highly opinionated researchers can quickly turn into a mental battlefield. People need to be understood by everyone and have the same understanding of the rest. At the end, large meetings go off track with individuals either not understanding or wanting to contribute. For example, it is easy to deviate to non-technical areas, the superficial parts everyone understands, as a way to contribute. Meetings often focus on trivial areas like implementation details, titles, and names. The essential and expensive research decisions take little time to be discussed.

%%{init: {'theme':'base'}}%%
flowchart TB;
a(["A Problem Arises"]) --> x["Meet With the Right People"]
x["Meet With the Right People"] --> y["Understand the Problem"]
y["Understand the Problem"] --> d["Propose Several Solutions"]
d["Propose Several Solutions"] --> e["Discuss the Solutions"]
e["Discuss the Solutions"] --> q{Bikeshedding?}
q -- Yes --> x["Meet With the Right People"] 
q -- No --> z["Pick a Solution"]
z["Pick a Solution"] --> r(["Build and Test It"])

The result of most meetings is often… can you guess it? To decide where to meet again and at what time, just to follow up the discussion! Don’t get me wrong, meetings can be helpful, but be careful with Parkinsons’ Law of Triviality because half of the people aren’t listening, one third of the people have different ideas, and the rest might disagree.

Mitigation Strategies

The Law of Triviality is a common problem in all human activities involving time management. But in research, this behavior is a sign of other problems such as lousy supervision or lack of focus. Some research directions are polarized. People could have a hard time deciding between them. We shouldn’t let trivial matters emerge freely to narrow solutions, expecting an answer to come up naturally.

The supervisor should move the research in a more productive direction in such situations by creating well-defined and measurable tasks. Being wrong about a minor decision such as framing a research question or presenting an experiment’s results (i.e., tables, figures, etc.) is acceptable. Overlooking primary research methodologies or protocols isn’t. Should every controversial discussion be stopped then? As a rule of thumb: If the debate can’t be resolved in less than 15 minutes, it should be interrupted.

We procrastinate on the hard calls or discussions. The hope is that once the low-level details are precise, understanding the bigger picture will become easier. Unfortunately, this is rarely the case. The Parkinson’s Law gives us a false sense of achievement deciding on trivial topics while the pressing ones remain.

These are some strategies to mitigate its effects:

1. Have clear goals and a short to-do list: Ensure that your tasks are short and clear enough for you to be able to address them. If you have a meeting whose goal is to simply discuss a topic, you will not be clear on what’s expected from you in the meeting. It’s far more effective to state that your goal is to accomplish something specific and measurable, such as framing 3 research questions, deciding on how to present the results of an experiment, or deciding whether to follow a particular research direction.

2. Time-box your to-do list: To limit you from spending too much time on a task, set a fixed amount of time for it, and hold it to that limit.

3. Front-load your to-do list with the most critical tasks: To ensure that you spend the needed time on the most important tasks, rank them at the top of your to-do list. If you do need extra time for a more important item, at least you’ve got it first.

4. Recognize trivial matters: Now that you know the Parkinson’s Law, you can be more aware of it. If your team is prone to this behavior, ensure they’re also familiar with it. You can even share this article with them.

5. Call it out: If needed, you can use another phrasing to respectfully convey your point more effectively. Say something like:
   • “It seems we’re spending too much time on lower priority items…”
   • “It would be more beneficial to move on and spend more time on XXX topic.”
   • “I appreciate the passion the group has for this topic. However, our time would be better spent on…”
   • “I appreciate the passion the group has for this topic. However, we need to finalize a decision.”

6. Get agreement to move on: Once you’ve identified and pointed out the trivial matters, the team can agree to move on to the more important topic(s). If the goal is to make a decision, make the team vote, call it done, and move on. If the topic comes up again, you can kindly remind them that a vote was taken, a decision had been made, and the item is closed.

7. Agree to hold each other accountable going forward: This requires trust among members of the team. Ensure you’re creating and maintaining a culture of respect and support. This makes it even easier to speak openly on topics that could be perceived as rude by others. It also makes it easier for folks to feel comfortable speaking up.

Conclusion

The Parkinson’s Law of Triviality is the act of spending disproportionate amounts of time discussing trivial parts of a problem instead of focusing on more important topics. It explains why trivial and low-priority items dominate project plans and meetings. People are more comfortable talking about things they understand well rather than complicated multilayer problems. This behavior avoids making tough decisions and tackling core problems. Instead, people tend to monitor the progress of less important tasks.

In the research context, this is considered unproductive because it focuses on trivial matters of little impact. It often manifests as over-engineering, implementing unnecessary abstractions and practices to keep our options open when we can’t decide on something. This behavior can also be considered a form of procrastination in which we postpone making hard tasks by endlessly discussing trivialities. It may be caused by bad leadership and their inability to make decisions. Successful research projects are disciplined in their focus. The laser in on the research hypothesis and the research artifacts.

In summary, be careful with Parkinson’s Law of Triviality. At its core, it’s not mere procrastination or laziness. It’s unnecessary work that we do simply because we have the time. And I see it happening every time. When something is not urgent, people take their time.

A final corollary: “If you give yourself less time to do something, you will probably do good work, no hours spend doing unnecessary work.”

So, instead of finishing something next year, next month, or next week, remember Parkinson’s Law because most likely, you can finish it today!

Further Reading

• The Original Parkinson’s Law and The Law of Triviality
• Bikeshedding and The Law of Triviality
• Bikeshedding in Software Development

Footnotes