Conway’s Corollary

Ian Bicking’s post on Conway’s Corollary is a must-read thought on isomorphisms between the organization and product structures.

What, asks Bicking, if we don’t fight this, but embrace it. Organizational structures are allegedly for our benefit. Why not allow them to shape product? Or when this is inappropriate why not recognize that the two MUST be aligned and if product can’t follow organization, we should refactor organization to reflect and support product.

Modularity At Fine Granularity

Ian Bicking has a fascinating question. I’m just going to quote the whole thing because it’s so good and important : 

The prevailing wisdom says that you should keep your functions small and concise, refactoring and extracting functions as necessary. But this hurts the locality of expectations that I have been thinking about. Consider:

function updateUserStatus(user) {
if (user.status == "active") {
  • ").appendTo($("#userlist")
    .attr("id", "user-" +;
    } else {
    $("#user-" +;

  • Code like this is generally considered to be terrible – there’s logic for users and their status, mixed in with a bunch of very specific UI-related code. (Which is all tied to a DOM state that is defined somewhere else entirely — but I digress.) So a typical refactoring would be:

    function updateUserStatus() {
    if (user.status == "active") {
    } else {

    With the obvious definition of displayUserInList() and removeUserFromList(). But the first approach had certain invariants that the second does not. Assuming you don’t mess with the UI/DOM directly, and assuming that updateUserStatus() is called when it needs to be called, the user will be in the list or not based strictly on the value of user.status. After refactoring there are functions that could be called in other contexts (e.g., displayUserInList()). You can look at the code and see that particular things happen when updateUserStatus() is called, but it’s not as easy to determine what is going to happen when inspect the code from the bottom up. For instance, you want to understand why things end up in

      — you search for #userlist but you now get two functions instead of one, and to understand the logic you have to trace that back to the calling function, and you have to wonder if now or in the future anyone else will call those functions. The advantage of the first function is that blocks of code are strict. You execute from the top to the bottom, with clear control structures. When GOTO existed you couldn’t reason so well, but we’ve gotten rid of that! (Of course there are still other exceptions.) It’s not entirely clear what intention drives the refactoring (besides adherence to conventional standards of code beauty), but it’s probably more about code organization than about making the control flow more flexible. Extracting those functions means that you now have the power to make the UI inconsistent with the model, and that hardly seems like a feature. And I have to wonder: are some of these basic patterns of “good” code there because we have poor tools for code organization? We express too many things with functions and methods and classes (and perhaps modules) because that’s all we have. But those are full of unintended semantic meaning. Anyone have examples of languages that have found novel ways of keeping code organized?

      So, it’s a great question on modularity where we tend not to have much explicit thinking : down at the smaller granularity (compared to all the patterns for classes etc.) My immediate comment is that if Ian refactored his code like this :

      function updateUserStatus() {
      var id = "user-";
      if (user.status == "active") {
      } else {

      it would solve most of the problems. In this version we aren’t fussily creating extra functions for tiny fragments of functionality which are only relevant to narrow situations (ie. users, userlists). Now the new functions are more generic and widely applicable. They’re doing enough that it’s worth the overhead of creating them. They’re still usefully hiding the bit of complexity we DON’T want to think about here – the actual jQuery / HTML details of how lists are constructed – but they’re leaving the important details – WHICH list we’re updating and what parts of a user we show – in this locality rather than allowing it to become diffuse across the program. Of course, we can’t prevent another bit of code updating the list itself somewhere. (That’s more a quirk of the HTML environment where the DOM is global. In many analogous cases we could prevent most of the code having unauthorized access to a list simply by making it private within a class.)

      Modules In Time : Synthesizing GitHub and Skyrim

      Thanks to Bill Seitz I picked up on a Giles Bowkett post I’d missed a couple of months ago which compares the loosely coupled asynchronous style of development that companies like GitHub both promote and live, with the intensely coupled synchronous raids that occur in online game-worlds.

      Bowkett seems confused by the apparent contradictions between the two. And yet obviously impressed by the success of both. He wants to know what the correct synthesis is.

      That really shouldn’t be so hard to imagine. The intense coupling is what happens in pair-programming, for example. Or the hackday or sprint. Its focus is on creating a single minimum product or adding a single feature / story to it.

      The right synthesis, to my way of thinking, is intense / tight / adrenalin fuelled / synchronous coupling over short periods, where certain combinations of talents (or even just two-pairs of eyes) are necessary. And loose / asynchronous coupling everywhere else. Without trying to squash everyone’s work into some kind of larger structure which looks neat but doesn’t actually serve a purpose.

      The future of work is highly bursty!

      It shouldn’t surprise us, because modularity is one of the oldest ideas in software : tight-cohesion within modules of closely related activities. Loose and flexible coupling between modules. It’s just that with these work-patterns we’re talking about modules in time. But the principle is the same. The sprint is the module focused on a single story. The wider web of loosely asynchronous forks and merges is the coupling between modules.

      To return to a theme I started many years ago, I commented on this excellent article about why web-site development has got so damned hard. (And remember when we all thought of web-apps as lighter and simpler than desktop apps? What happened?)

      Anyway, here’s my comment.

      I think the problem is less the multiplicity of programming languages, than our insistence that we should always be separating our languages in different places.

      This goes against the basic tenets of cohesion and coupling. We cluster unrelated activities together because they happen to have the same syntactic sugar, while separating tightly-coupled activities because half of them happen on the client and the other on the server. Why the hell should this implementation detail have to be reflected in our architecture?

      What I’d like, controversially, is to be able to mix-and-match the languages within the same source file, grouping together the python, javascript, html and sql that actually has to work together in one place. I have no trouble dropping into regular expressions or similar DSLs from inside my main code, why should dropping into a layout or query language be different?