Parkinson’s Law of Triviality (as proposed by C. Northcote Parkinson in 1957) is that people give disproportionate weight to trivial issues. Parkinson gives as an example a hypothetical (planning) committe deliberating on the building of a nuclear power plant and a bicycle shed. Parkinson stated that “the time spent on any item of the agenda will be in inverse proportion to the sum involved.” Clearly a nuclear reactor is vastly expensive and complicated and the average person is unlikely to understand it because it is so far outside the realms of their daily experience. A bike shed, on the other hand, everyone understands (or thinks they do, which can be even more dangerous). The result is that people will be reluctant to discuss for long the nuclear reactor either because they assume those working on it understand it or because they are to fearful of making themselves look foolish in front of the experts. The bike shed however can result in endless discussions because everyone involved wants to add their “feature” and show that they have contributed. While discussing the bike shed, debate rages over what the best choice of roofing should be, whether there should be windows, whether it should be fully enclosed with walls and a door etc, etc rather than whether the shed is a good idea or not.Parkinson’s Law of Triviality is something that frequently creeps into architecture discussions. When requirements are being discussed and how best to realize them architecturally it is frequently the case that when the domain under discussion consists of parts that are familiar and ones that are not it is the former that will often receive inordinate amounts of discussion whereas the latter do not (but usually should). A good example to illustrate this is that of e-commerce systems. Because most people have used such systems everyone will have an opinion on the bits they are familiar with (the actual look and feel of the shopping experience for example, do you call it a shopping basket or a trolley, do you allow goods to be placed in the basket before you have logged in or registered and so on). The part of the system that deals with payment however (i.e. that goes off in the background and does credit checks etc) or checking stock level is not seen so people will probably have less of an opinion on it. This part, at least as far as the web site owner is concerned, is the most important however because if that does not work he will lose money. Worse however is if the “payments specialist” says that this is the way payments will work, and no one else feels they have the expertise or authority to challenge her. Doing something because that’s the way we always do it is an example of the Golden Hammer anti-pattern and does not always result in the most innovative or creative new systems.

So how to protect against falling foul of Parkinson’s Law of Triviality?

1. Good architects need to develop deep domain knowledge and know how to, and be fearless in doing so, challenge expert opinion. Frequently appearing foolish by challenging the blindingly obvious is a small price to pay for occasionally highlighting a problem which everyone else overlooked because they were following conventional wisdom.
2. Ensure complex problems receive proportionately more discussion than simple ones. In other words cut the discussion of addressing the simple problem sooner to allow time to discuss the complex ones. Better still if in a meeting there are several problems to be discussed prioritise them by complexity and start with the most complex first. Leaving simpler ones till the end means you can rush those through when everyone gets tired or you are out of time.
3. Recognise that everyone has an equal say and it is often the people who know least about the problem that ask the daft, but hard, questions. This of course would seem to go against number 1. If everyone is an expert doesn’t that mean no one will be naive enough to ask the simple but challenging questions? No. A good team has a diverse mix of skills, knowledge and opinions and should allow everyone to comment.
4. Leave your ego at the meeting room door and do not use your relative position in the hierarchy of the company to trivialise other peoples ideas or prevent constructive discussion because it is not “going your way”.
5. Finally capture all decisions in a systematic way (recording at the very least what the decision was, what options were discussed, the rationale for choosing the one you did and any related decisions or implications).