When deciding on the choice of tool, process, or methodology, developers, architects, and team leads feel a strong urge to “do exactly as is best practice” (or standard), that is, as recommended on popular web sites or in text books.
On average following some “best practice” may protect against bad mistakes. Some reasoning on why choose some approach over another should always be done though. Sometimes there is glaring examples that show that some given best practice is quite obviously not so good after all.
An Example
For the sake of this post I will use the example of “Feature Branching”. The idea of feature branching is that instead of having many developers work on the same code line, while implementing different features, to have developers create branches per feature that will be integrated back into the main code line when done.
While the first part of this idea sounds fantastic and fits wonderfully to models of distributed source control, the second part becomes absurdly complex for large and “wide” code bases and when applied with more than a handful of developers.
There is no need to discuss for what kind of projects and management setups feature branching may work. Assuming you are about to develop an actual solution that is under constant development, feature branching obviously does not work well, as companies that have products with large code bases do simply not use this approach.
This is obvious in the sense that where large teams work on a large solution code base (note: see also local vs. distributed complexity), feature branching is not used as a means of regular feature development. This, to my knowledge includes Facebook, Google, and definitely not traditional SAP (check out the references below).
How Come?
How come something is touted as best practice that does not get embraced where it should actually matter most: At scale?
Here are some guesses: For once, peer pressure is strong. It can be a frustrating intellectual effort to argue against a best practice. Secondly “experts” are somewhat wrong most of the time, simply because professional writing about a field as wide as software engineering leaves little time to actually practice first-handedly what you are writing about. Most expert authors will only ever have experienced tools and approaches for a short time for small problems – and actually have little incentive to do otherwise. And finally: Something that solves a problem in the small and distributed (as often in the OSS community) frequently does not work well in the large and interconnected.
But then: Does it make sense to do differently?
It obviously does – considering the examples above. But one does not look to the likes of facebook. The simple truth is that, if you do not stand out in some way, you are by definition mediocre – which is nothing else but saying that other than for political protection or some other non-market reason, there is no particular reason to have you win the market.
When does it make sense to do differently?
Even assuming you are completely sure to know a better approach, when does it make sense to fight for adoption?
I think the simple answer is: For disruptive approaches, the only meaningful point in time to fight for it is in the very beginning of a project or product (and sometimes organization).
Remember the technology adoption life cycle (see “crossing the chasm” and others):
What this says is that even if you manage to win the enthusiasts, winning the mainstream audience is the harder part.
In our example, the market is the product organization and the disruptive tool or approach is the technology we want to see used. Luckily, initially our organization will have a significant number of visionaries and enthusiasts with respect to anything that promises to give our product a head start.
Over time, choices have been made, customers acquired, visionaries will become pragmatics and the willingness to do anything but the most predictable and least harmful as far the specific product’s development is concerned will fade. That is, the product organization as a whole makes a transition very much in correspondence with the product’s target group changes.
Consequently, introducing a disruptive change from within might turn out to be a futile exercise in any but the earliest stages of a product’s life cycle.
Summary
Doing differently can be the difference between mediocrity and excellence. Foundations are laid at the beginning of product development. Non-mainstream choices must be made early on.
References
- Martin Fowler on Feature Branching
- Does-Facebook-use-feature-branching (Quora)
- Paul Hammant on Trunk Based Development
- Paul Hammant on Google’s vs Facebook’s Trunk Based Development
z the world 