The Attraction of Laws

Bright? He's a common ignorant slob. He don't even speak good English.

By Julian Browne on June 5, 2011. Filed Under business, humour

I noticed last week just how many half-written articles I have queued up for completion. Postwise, the last twelve months has been heavy on ideas but light on completion. Sorry about that. Unless you think my stuff sucks in which case: "you're welcome". It's been a very busy period and writing time has been hard to find. But when I look at some of those half-formed works I see that they lack a narrative sense of beginning, middle, and end. Ideas are great but I find it hard to summon up the enthusiasm to finish them unless I am also caught up in the story that brings them to life.

David wondered whether the team had deliberately
given him the wrong directions for the meeting room

This one is an exception because it only has a middle. It's a collection of observations that has amused me for some time and was inspired into being by a post from Dan Pritchett in which he discusses Conway's Law. Conway put forward the idea that:

organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations

It means if your organisational communications are complex then so too the communication paths of the systems you design. Dan turned this around and said that in designing architectures you could actually map organisational structure to them. I liked the idea because it fits with my philosophy of embedded, developer-owned, governance as opposed to the old-fashioned and bureaucratic standards-police approach adopted by many organisations. Here's a quote from Dan's post:

So many companies attempt to achieve quality through process, governance, checklists, sign offs, and many other impediments to delivery.

The hope is that through all these processes poorly built software will not be released to site. The reality is the best way to achieve high quality software is to give people a sense of ownership in the code they write.

Indeed. And, as I mentioned last time, this is precisely the approach that successful internet companies have taken, so we know it works too.

Anyway, I was mulling over whether to write an article on how SOA relates to Conway's Law - something along the lines of "Model your services according to the way your organisation communicates, and you'll avoid POA-style business process anti-patterns and be much more SOA rather than JBOWS".

I didn't get far with it, partly because I'd already written the same thing (minus Conway's Law) some time ago. In any case it didn't have a beginning, middle and end so I never got around starting it. Plus, as it turns out, Dirk Krafzig already did it in 2008.

But Conway's Law stuck in my mind. It's not a law is it? Nobody is bound by some unseen force to design poorly communicating systems just because they work for a company that's crappy at it. Very few of the eponymous laws are fact-based. They're stereotypical clichés that alert us to common pitfalls and enlighten us to the circumstances that make up anti-patterns of behaviour. Sometimes they're funny too. And like anything in life that requires the recipient to actually think before acting on the embedded message, they're also kind of dangerous in the hands of the unconsciously incompetent.

A warning sign that the person in your meeting might be found a little wanting when it comes to knowing what they are talking about is that they will frequently refer to these laws as if they are knowledge. They are not. OK .. clearly some are. Newton's Second Law (that force equals mass times acceleration) is hardly a matter of opinion, since we use it to construct new laws that explain the behaviour of physical objects, make cars safer and design spaceships. But real laws are rarely referred to by meeting-groupies and consultants. Why? Because real laws require study, learning, understanding and their results are incontrovertible. That is to say you can be tested on them.

So, as a useful add-on to your bullshit bingo card, I present my favourite list of eponymous laws. Some true, some questionable, mostly amusing.

• Brooks' Law

  Let's start with an old favourite - Brooks' Law. Fred Brooks said that adding people to a project that's already late will make it later. It has this affect because now all these new people have to brought up to speed and that takes everyone's mind off the job. Not only that but you've also added to the communication paths in the project and increased the risk that important information will be missed. It's true of course but not always so. If I had an army of personal assistants I would definitely have a shot at getting late things done more quickly. You know Brooks Law is being abused when your project is late and they start adding more project managers to it. Just as you are about to collapse from the tedium of all the meetings with them they will all ask you at once if adding more people would make your project faster. Explaining Brook's Law whilst being affected by it has been known to cause recursive loops in space time that has made entire change programmes disappear in an instant.

• Sowa's Law

  How true is this? John Sowa said:

  Whenever a major organization develops a new system as an official standard for X, the primary result is the widespread adoption of some simpler system as a de facto standard for X.

  EJB and Spring. WS-* and REST. XML and JSON. Anything from Sun, Microsoft, Oracle vs. anything similar from the open-source community. This is a good one to remember because (whilst it's not a law) it does make you question Official Standard X as put forward by the seemingly learned consultant as opposed to doing the simplest thing that works.

• Parkinson's First Law

  One of my heroes. Cyril Northcote Parkinson, patron saint of my support group Quixotics Anonymous. His first law:

  Work expands so as to fill the time available for its completion

  does to some extent jar with my comment on Brooks' Law. You see if I did have an army of personal assistants then either my workload would just expand to fill my extra free time, in which case I would still be late, or I would fill it up reading twaddle like this on the web. You cannot win. Let's face it - you're going to be busy and sometimes you are going to be late.

• Parkinson's Law of Triviality

  Cyril again. He gets a second mention thanks to Parkinson's Law of Triviality also known, via his true-to-life story of the amount of time it takes an organisation to debate what colour to paint the bikeshed, as Bike Shedding (and, I assume, the inspiration for the title of the mercurial Zed Shaw's blog). You see this a lot in software projects - people will argue for days about what to call a project, who should sit where, what colour the logo should be, but arrange a session on techniques for managing high-availability in distributed systems and three people will turn up. One won't say anything because they have no idea what you are talking about, one will do nothing but check their email (fulfilling the prophesy of Parkinson's First Law) and the other will leave once they realise you aren't still talking about the logo.

  Parkinson's Law of Triviality is explained by two things.

  Firstly, some shit is really hard, which means you're probably not going to get it right first time around. Especially if you try and do complex things in one go. You need experience and an adaptable attitude. Lots of people don't have this. Colours of bike sheds on the other hand are easy to understand. And you don't need any distributed system experience to argue for your chosen colour.

  Secondly, Parkinson's Law of Triviality is based on Sayre's Law which states:

  In any dispute the intensity of feeling is inversely proportional to the value of the stakes at issue

  We argue about insignificant crap, or stuff we think we understand well (like bike sheds), at the expense of stuff that is important or related to areas where our knowledge is maybe not the best in the room. So, for the record, if I were ever to bump into say, Steve Vinoski at a garden party, I'll make a really big deal about where we sit, and have some forthright opinions on what we have for lunch, but pretty much start checking my email when he brings up the subject of middleware.

  I've done a lot of work in the middleware and integration space but I am wise enough to know not to get all up in the business of someone who would kick my intellectual butt in it. Especially at a garden party. Not so for most practitioners in middleware. It's full of 'specialists' whose knowledge is in inverse proportion to the day rate they charge.

• Rothbard's Law

  Because as economist and libertarian Murray Rothbard said:

  people tend to specialize in what they are worst at.

  So, perversely, people won't debate complex topics (like middleware) much (in accordance with Parkinson's Law of Triviality) but they will specialise in them.

  If you're not sure about this ask a small software house, or better still a creative agency, to come in and pitch for some niche high-end embedded systems development work. Make sure the scope is well out of their comfort zone. Make sure they haven't done it before. Will they decline the project as being beyond their expertise? No siree.

  Now ask one of the big systems integration consultancies (you may need to hint at the fact you have a large budget for the work). They'll be a specialist before they even know what it is you want. And whatever technology is least applicable to the job will be exactly what they propose.

• Spolsky's Law

  So you hire big-systems-integration-consultancy and they bring with them least-applicable-technology framework. Management will do this because the phrase 'out of the box' was used maybe thirty times during the pitch. All frameworks these days do pretty much everything out of the box. Sometimes I wonder why we have software developers at all. Frameworks are sold, by consultancies, on the basis that they abstract everything. And when their developers go on the course that's all they learn about - the abstractions.

  Joel "did you know we have great offices?" Spolsky had something to say about abstractions:

  All non-trivial abstractions, to some degree, are leaky

  What Joel meant was that even though you have a have a bucket full of coarse-grained beautifully-modelled behaviourally-aligned domain objects they don't live on pixie dust and fairy magic. You'll need that bucket though. Soon you'll hear the drip drip drip of your budget leaking through those abstractions and the best piece of fairy magic is it does so without leaving even the tiniest remnant of useable software.

• Muphry's law

  If you're going to be critical about all this leaky framework use then timing is everything. Unfortunately you will have to wait until a painful amount of your company's money has been wasted, otherwise nobody will take you seriously. Without weight to your argument it's all a bit semantic and conjectured. Wars of words are tricky things. You can point at someone's code and say why it's duff, but that's no easy task when it comes to word documents. Whatever you do, don't take solace in the fact that they have grammatical errors or typos in their designs as cautioned by Muphry's Law:

  if you write anything criticizing editing or proofreading, there will be a fault of some kind in what you have written

  Muphry's Law comes with two clarifying laws to be wary of if you have a mind toward criticism.

• Sturgeon's Law

  90% of everything is crap

  Theodore Sturgeon was a writer of sci-fi. Tired of the criticism his genre received he remarked in a revelation that in fact 90% of everything is crap. That would include 90% of software. I just checked. It does. So make sure you're focusing on the 10% that has a realistic shot at being something other than crap. Otherwise you are fighting the inevitable.

• Hanlon & Clark's Law

  Clarifying law number 2, or more accurately laws numbered 2a and 2b, which are essentially the same, are Hanlon's Razor and Clark's Law. It can be a frustrating experience having to watch a stupid idea take shape. It's tempting to assume that anyone that ignores your much more logical approach has some issue with you personally. Some people will tell you it's all about stages of competence. Robert Hanlon put it more succinctly:

  Never attribute to malice that which is adequately explained by stupidity

  J. Porter Clark explained why:

  Sufficiently advanced cluelessness is indistinguishable from malice

• Galls Law

  If there's one law that I do like it's Gall's Law from the book "Systemantics: How Systems Really Work and How They Fail" by John Gall. I cannot prove it's true but all my experience in dealing with the schoolboy errors of enterprise architectures leads me to believe it to be so.

  A complex system that works is invariably found to have evolved from a simple system that worked.

  and more poignantly ..

  The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

  As an aside, if you liked the Parkinson books, John Gall's book is in the same spirit (think verbal Scott Adams without Dilbert). Later editions of it were retitled "The Systems Bible: The Beginner's Guide to Systems Large and Small", though you can still get the 1978 versions on Amazon.

• Zawinski's Law

  And when you do finally get your way and have to design something, remember to keep it simple. That means both meeting the minimum working set of requirements and holding back the code's natural desire to take you on a journey of its own:

  Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

  (Jamie Zawinski also famously said 'Some people, when confronted with a problem, think "I know, I'll use regular expressions.” Now they have two problems').

So there we have it. A brief trip around my favourite laws. Remember never to use these in meetings to make things sound smarter than they are. Especially if you are keen to leave a good impression.

Which reminds me:

• Fey's Law

  Room for one last law. The most important of all. Tina Fey is an American actress and comedian. She became quite well known outside the US after an uncanny impression of Sarah Palin on Saturday Night Live in 2008. Anyway, whilst working in Chicago she wrote a sketch about Catherine the Great, from which Fey's Law is derived. If you take nothing else away from this post I hope it's this - a reminder that we may do many things in our working lives, both good and bad, but we do not always get to choose how the world perceives us.

  You can be a murderous tyrant and the world will remember you fondly.

  But fuck one horse and you're a horse-fucker for all eternity

Notes

The painting is 'Wanderer above the Sea of Fog' by David Caspar Friedrich painted in 1818.