After writing about the Software Engineering Myths Microsoft claims to have busted, I’ve been thinking about their find that organization structure is the most predictive factor for bugs.

And it makes me think, to what degree are organizations’ code bases shaped by their formal or informal organization structure? Are core modules and root objects often the domain of senior developers and objects lower in the hierarchy the domain of juniors? My experience is that it often tends to be, and it seems a reasonable overlap: after all, you want your more trusted developers fiddling where the damage can be greatest.

But how about other attributes of the code base? In the world of Perl, are CPAN authors often hired as external consultants? Are the most communicative programmers the ones that will write network services? Are the modules most used also written by the programmers that are most in contact with others?

And does organization structure also shape general code base structure? Will a more hierarchical organization tend more towards hierarchical object structures, while more chaotic or flat organizations tend towards more chaotic or flat code organization?

A lot of questions, but no answers… But one thing that comes to mind is, if organization and code structure follows each other, is this a good idea? I think few people designing a data model or object hierarchy starts with the organization structure as a blueprint, but speaking from my own limited experience, you can often at least see a reflection of either in both. Is this a good or bad thing? What can the consequences be?

One thought on “Does code base structure follow organization structure?

  1. Trevor says:

    Well, organization and code structure could be similar if the people creating the organization’s hierarchy are also the same kind of people doing the employing, or at least managing the things that determine whether employees stay with the organization or leave. The chances are, though, that at any time there will be a mix of employees at least to some extent trying to reproduce the type of code structure in which they believe.

    Whether this would be a good or bad thing, in my opinion, is whether the customer can accept the product. Even though most of the code might be transparent to the customer, when it comes time to talk about new features one might find that a hierarchically structured code lacks the flexibility to match the changing needs of a customer with a more flat structured organization. And vice versa. In terms of business success as a supplier, it might be worth having on board people capable of understanding the essential need in people for hierarchical, or flat, structures so that the code produced does not lock out the other type of structure.

Leave a Reply

Your email address will not be published. Required fields are marked *