Agile Zone is brought to you in partnership with:

Software Developer, Mentor, Architect and UX/UI craftsman. Also, a psychology nut that loves curling. Zac is a DZone MVB and is not an employee of DZone and has posted 66 posts at DZone. You can read more from them at their website. View Full User Profile

Identifying the PLOT in Software Design

05.23.2014
| 6245 views |
  • submit to reddit

In 1957, C. Northcote Parkinson proposed in his book Parkinson's Law that "organizations give disproportionate weight to trivial issues." This statement later became known as Parkinson's Law of Triviality, or PLOT. Parkinson spoke of a story contrasting the trivial cost of building a bike shed to an atomic reactor. Although Parkinson was referring to organizations as whole, over the years this problem has become a pervasive issue in software development. It typically arises in situations that require a forum/audience. These can include reviewing concepts, designs, software code, or functionality demonstrations. At times it may feel as if the conversation is moving slow or is losing focus; this may be attributable to PLOT. Before getting frustrated, it's important to understand why this happens and what techniques can be used to help mitigate these discussions.

Why does Parkinson's Law of Triviality exist? People want to add value and feel valued. This is an amazing attribute of human nature. In software development, the more common a feature or functionality is, the more compelled people are to respond. This response results in the form of an opinion, concern, or suggestion. Once discussed, most people are filled with a sense of accomplishment and feel that they added value. Additionally, if a discussion resolves in their favor, people feel valued and are filled with a sense of worth. For some, these feelings are not even consciously recognized. In other words, their hearts are in the right place. It's important not to forget or diminish that.

Armed with this knowledge, how can PLOT be mitigated? The good news is the hardest part is already done. Understanding that it exists and using this information to educate others is half the battle. The section below covers a variety of other techniques that can also help.

  • Before or during a discussion, clarify the impact and/or frequency of the subject at hand.
  • Identify the difference between hard to change, complex, and long-term impact versus small change and minimal effort.
  • Recommend phasing a concept or suggestion. Acknowledge that the door for future enhancement is not closed.
  • Encourage further discussion after a meeting with a smaller, focused group. This helps defuse herd mentality.
  • Empower someone to be the final decision maker. This can be different people for different discussions.
  • When necessary, time-box conversations or ask for a time-check to keep everyone aware of the time invested.
  • Be flexible, balanced, and allow for concessions, but keep the end goal in mind.
Published at DZone with permission of Zac Gery, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)