Conway’s Law & Distributed Working. Some Comments & Experience

The eye-opener in my personal experience of Conway’s law was this:

A company with an IT department on the 1st floor, and a marketing department on the 2nd floor, where the web servers were managed by the marketing department (really), and the back end by the IT department.

I was a developer in the marketing department. I could discuss and change web tier code in minutes. To get a change made to the back end would take me days of negotiation, explanation and release co-ordination.

Guess where I put most of my code?

Inevitably the architecture of the system became Webtier vs Backend. And inevitably, I put code on the webserver which, had we been organised differently, I would have put in a different place.

This is Conway’s law: That the communication structure – the low cost of working within my department vs the much higher cost of working across a department boundary – constrained my arrangement of code, and hence the structure of the system. The team “just downstairs” was just too far. That distance was composed of gaps & differences in priorities, release schedules, code ownership, and personal acquaintance.

Conway’s Law vs Distributed Working

Mark Seemann has recently argued that successful, globally distributed, OSS projects demonstrate that co-location isn’t all it’s claimed to be. Which set me thinking about communication in OSS projects.

In my example above, I had no ownership (for instance, no commit rights) to back end code and I didn’t know, and hence didn’t communicate with, the people who did. The tools of OSS—a shared visible repository, the ability to ‘see’ who is working on what, public visibility of discussion threads, being able to get in touch, to to raise pull requests—all serve to reduce the cost of communication.

In other words, the technology helps to re-create, at a distance, the benefits enjoyed by co-located workers.

When thinking of communication & co-location, I naturally think of talking. But @ploeh‘s comments have prodded me into thinking that code ownership is just as big a deal as talking. It’s just something that we take for granted in a co-located team. I mean, if your co-located team didn’t have access to each other’s code, what would be the point of co-locating?

Another big deal with co-location is “tacit” knowledge, facilitated by, as Alistair Cockburn put it, osmotic communication. When two of my colleagues discuss something, I can overhear it and be aware of what’s going on without having to be explicitly invited. What’s more, I can quickly filter out what isn’t relevant to me, or I can spontaneously join conversations & decisions that do concern me. Without even trying, everyone is involved when they need to be in a way that someone working in a separate room–even one that’s right next door–can’t achieve.

But a distributed project can achieve this too. By forcing most communication through shared public channels—mailing lists, chatrooms, pull request conversations—a distributed team can achieve better osmotic communication than a team which has two adjacent rooms in a building.

The cost, I guess, is that typing & reading is more expensive (in time) than talking & listening. Then again, the time-cost of talking can be quite high too (though not nearly as a high as the cost of failing to communicate).

I still suspect that twenty people in a room can work faster than twenty people across the globe. But the communication pathways of a distributed team can be less constrained than those same people in one building but separated even by a flimsy partition wall.


The Panama Pepers: a longtail SEO example

A Flemish friend commented recently on facebook that after all the news items about the ‘Panama pepers’ there were still no hits for it in search engines. (For those of you not previously acquainted with the Flemish talent for multi-lingual puns, I should explain that ‘peper’ in Dutch as pronounced as the English ‘paper’ but means pepper. He went on to mention a secret recipe for Norwegian salmon with Panamanian peppers).

And it was true! There were no hits on all the interwebs for Panama pepers.

Which brings us to the subject of longtail SEO. By writing pages on specific, not-widely-popular terms, websites attract to their site the small number of visitors who are interested in the topics to which they think searching those terms will lead them. Except: ‘small’, when your potential audience is The World may mean hundreds of thousands of visitors. Not so small after all.

Although Pepers is not an english word, by writing an article on the subject, and especially by discussing the Panama papers & Panama pepers (not to mention associated recipes), I thereby expect to rise to search engine page 1, if not hit #1, for the term.
We’ll see how it goes…

Update after 4 months now produces thousands of hits. This page made it to the first page, but only just. Clearly I need still lack a recipe or two for Panamanian peppers.

De Panama Pepers: een voorbeeld van SEO longtail.

Een Vlaamse vriend merkte onlangs op facebook dat na al het nieuws over de ‘Panama pepers’ waren er nog geen treffers voor die termijn in de zoekmachines. (Voor degenen onder u die niet eerder kennisgemaakt hebben met de Vlaamse talent voor multi-lingual woordspelingen, moet je weten dat ‘peper’ wordt in het Nederlands net zo uitgesproken als het Engels ‘papers’. Hij merkte verder een geheim recept voor Noorse zalm met Panamese pepers).

En het was ook zo! Er waren geen hits op de interwebs voor ‘Panama pepers’

Wat brengt ons op ons onderwerp: longtail SEO. Door het schrijven van pagina’s over specifieke, niet-alom-populaire termen, trekken websites het kleine aantal bezoekers aan die interesse hebben voor de betrokkene onderwerpen. Alhoewel: ‘klein’, wanneer uw potentiële publiek de wereld is, kan honderdduizenden bezoekers betekenen. Niet zo klein, dus.

Hoewel ‘Pepers’ geen Engels is, wordt door het schrijven van een artikel over het onderwerp, en in het bijzonder door het bespreken van de Panama papieren & Panama pepers (en de bijbehorende recepten), verwacht ik uiteindelijk eerste plaats te nemen in zoekmachine rankings.

We zien wel hoe het gaat …

MacBook Pro clamshell mode with the lid open

Or rather: how can I disable the built-in display and carry on working on an external monitor without having the laptop overheat and whine like an aeroplane because the lid is down?

OS X users have spilt a lot of pixels on this and I too was frustrated because my shiny new 34″ screen made the laptop screen redundant; but keeping the lid shut often made the fan turn on.

SwitchResX came to my rescue, not for the first time. It has a daemon option with a menubar icon for turning displays on/off & for switching the resolution.

I got SwitchResX originally because my monitor does picture-by-picture display of 2 computers plugged in to it at once; which is only truly cool if said computers have a screen resolution option for half-a-screen. Which SwitchResX solves by allowing custom resolutions. So I’ve become a fan: it works simply and reliably and solves my problems.

I only recently came across this dance which I haven’t yet tried. I know other attempts to ‘trick’ the screen off failed after Mavericks

IIS Express : Run a child web application in a virtual directory under a parent application

Like this: Edit your IIS Express config file at

"%userprofile%\My Documents\IISExpress\config\applicationhost.config"

Create a site which has two applications defined in it, e.g.

<site name="MyTopLevelAndChildWebAppsInOneSite" id="123" >
    <application path="/" applicationPool="Clr4IntegratedAppPool">
        <virtualDirectory path="/" physicalPath="C:\Users\me\Source\TopLevelWebApp" />
    <application path="/Child" applicationPool="Clr4IntegratedAppPool">
        <virtualDirectory path="/" physicalPath="C:\Users\me\Source\ChildWebApp" />
        <binding protocol="http" bindingInformation="*:51234:localhost" />

And then run the site, matching it on the siteid:

start "Woo!" "C:\Program Files (x86)\IIS Express\iisexpress.exe" /siteid:123

Browse to, and close, your web apps in the usual way from the IIS Express icon in the systray.

Optionally, experience the pain that is web.config inheritance. But try not to.

Apple keyboard for Windows & the Command key for Control

If like me, you swap between Mac and PC you’ll have been irritated by everso slightly different keyboard layouts. So here’s my Apple Extended UK Keyboard Layout for Windows Installer.

When I wrote it I was using one of these:
Apple Pro Keyboard
But since the Apple full-size layout hasn’t actually changed since then, I still use it for my aluminium keyboard.

Swapping between Mac and Windows

In addition – even if using a PC keyboard – a Mac-PC swapper will undoubtedly suffer repeated Cmd and Ctrl shortcut confusion: You want to type Cmd-X for cut and suddenly the Win-X menu comes up instead.

My preferred solution for this is an AutoHotkey script, partly because after using Autohotkey for a few weeks I realised it was an utterly brilliant, all-singing, all-dancing customise-your-Windows-in-every-way tool, with an all-but-zero footprint.
My script is, which also has shortcut keys for arranging windows on a big screen.

The other reason I use autohotkey is that it enables a cherry-picking approach to swapping or duplicating Cmd-key/Ctrl-key shortcuts, which I find works much much better than doing a straight Cmd<=>Ctrl key swap. I got this approach from the keyboard layout used by Parallels on the Mac, which simply duplicated common shortcuts such as Ctrl-X, Ctrl-V to the Cmd-key. If you swap regularly between Mac & PC, this approach works well.

Inverting Mouse Scroll Direction

Since about the time that iPhone launched, OS X scroll direction, both mouse and keyboard, has used the metaphor of “push the document up to move it up the window” rather than the previous “push the scroll bar up to move the document down the window.” Windows has stayed firmly on the scrollbar metaphor.
Oddly enough, Microsoft mice come with a Windows driver that let you reverse scroll direction via the UI. For other mice, you can FlipFlopScrollWheel. Oddly, this is not per-user but per mouse/usb port combination, which means if you plug the same mouse into a different port it’s scrolls in the opposite direction.

Back to the Keyboard

If you do want a more complete Cmd<=>Ctrl key swap, then you do it with Randy’s SharpKeys.

Warning! You can’t swap keys around with it so do just this: map Left-Windows key to Left-Control. The right windows key will then still open the Windows menu and do all the Windows-Key stuff that it should do, such as Windows-L for Lock screen/Switch User:

Sharp Keys: Map just the left Windows key to Control key

If you want other keyboards than Apple UK, download the Microsoft Keyboard Layout Creator to tweak your layout.