Uniformity != Efficiency
Within any software organisation, there will be sporadic attempts to establish uniform processes, tools, and/or practices. Examples might include:
- “Every team must use the same hardware/OS/IDE”
- “Every application must use the same in-house commons/utilities API”
- “Every application must use the same infrastructure – application server/container/configuration/ORM/database”
- “Every application must use the same release mechanism”
Such efforts are largely well-intentioned and arise from the belief that reducing variation will reduce waste. But is this assertion evidence-based?
Based on my own experience, I would say the answer is a resounding no. Consider the following:
- At Company A, I was tasked to write a generic transport API to encapsulate all data protocols used between in-house and third-party applications. As I could not modify the published interfaces of the external applications or adapt the internal applications to those interfaces, the API was abandoned
- At Company B, I owned 2 protocol drivers in a suite of 20. A driver SDK was rolled out to ease development of new drivers, but retrofitting legacy drivers proved so time-consuming that new features were delayed
- At Company C, a generic journalling platform was developed upfront in anticipation of future journal-based applications. The platform had some initial success, but when my application was forced to use a radically different content structure an enormous integration effort was required
A cost-benefit analysis would conclude the above attempts were doomed from the outset and delivered little or no customer value. Customers value features over technical uniformity, and even then standardisation cannot be achieved when interfaces are not owned, when conformance costs are unconsidered, or when the uniformity is designed upfront.
Despite the limited availability of Great Developers, I am fortunate enough to work with Dan Worthington-Bodart. In addition to evangelising Crazy Fast Build Times of sub-10 seconds at QCon earlier this year and authoring the excellent TotallyLazy functional Java library, Dan is renowned for exposing flawed technical strategies – for example, in 2009 he buried Feature Branching with the pithy
Feature Branching is a poor man’s modular architecture
In the same vein, Dan once commented on a well-intentioned, ill-fated standardisation push by off-handedly saying
Making everything uniform will not automatically make everything efficient
Therefore we can summarise Bodart’s Law as
Uniformity != Efficiency
Bodart’s Law tells us that the cost of imposing uniformity upon a sufficiently large variation will permanently outweigh the value introduced by the homogeneity, and that ultimately the siren’s song of uniformity should be a byproduct of success as opposed to an un-evidenced requirement.
Leave a Reply