A temporal corollary to Conway's Law

Conway's Law is almost invariably quoted from:

• the conclusion to "How Do Committees Invent?", the 1968 paper where Melvin Conway introduced his idea
• the preface published 42 years later on the author's website
• Chapter 10 of 'The Mythical Man-Month', where Fred Brooks dubs it 'Conway's Law'¹

I returned to these three sources and found my favourite way of stating the Law in a section heading of Conway's paper. Its succinctness is unparalleled:

It immediately struck me as the most quotable version. One you may want to pass down to a keen junior colleague or tattoo on your forehead.

The motives why someone involved in the design & crafting of software is interested in Conway's Law are the same as those an aeronautical engineer has to keep an altar to Sir Isaac Newton.

My job for the past three years — that of designing, implementing, and maintaining software under the banner of the University of Cambridge's 'Digital Admissions' group — is the role that has most challenged my assumptions about how software is made and has brought me face-to-face with realities such as Conway's Law.

Viewed from a certain angle, universities are extruded timepieces embellished in gowns & mortarboards. They are bound to a relentless procession of deadlines: submitting admission applications, choosing course options, sitting exams, attending graduations... indices on an ivy-clad clock face.

The calendar that dictates when and how our systems are used casts a long shadow. Development roadmaps and milestones form a carbon copy of the academic calendar, a failure to avoid the Unconscionable Maps that Borges cautioned us about².

At times we operate in a manner more appropriate for farmers. That is to say, beholden to Spring being for lambing, making hay in Summer or harvesting as leaves lose their chlorophyll and wither away.

My experiences collaborating on software to manage and track milestones of the academic calendar drive me to suggest a temporal corollary to Conway's Law. That is, that the frequency of external phenomena moulds the software itself.

I have seen systems and assumptions coagulate around a base need in a way that makes change arduous. By way of example, consider a data-intensive and critical process that only happens once per year.
The development team will be aware that the process enabled by the system only needs to happen infrequently. This temporal structure will percolate through to the design of the system. The result? Hindering any activity that deviates from this assumption, such as testing that wishes to exercise a path regularly or a change in circumstances whereby the business needs the process to happen more frequently.

As for providing an account of why this happens, I will let the good doctor explain: "the incentives which exist in a conventional management environment can motivate choices which subvert the intent of the sponsor"³.

While Conway's Law is a mapping that holds in development efforts for all manner of software, I hope the temporal corollary is more of a cautionary note than an unshakeable covenant.

There is always a danger of miscalculation in trying to extrapolate from personal experience. Regardless of what you think of the above, I urge you to go back to Dr. Conway's paper and give it a read, away from meta-commentary and online chatter. You won't regret it.

'Ritter, Tod und Teufel' by Albrecht Dürer (1513). In the public domain.