Finally, we talk about inappropriate coupling driven by business concerns. Most of the time, business people aren’t nefarious characters trying to make things difficult for developers, but rather have priorities that drive inappropriate decisions from an architectural standpoint, which inadvertently constrain future options. We cover a handful of business pitfalls and antipatterns.
Pitfall: Product Customization
Salespeople want options to sell. The caricature of sales people has them selling any requested feature before determining if their product actually contains that feature. Thus, sales people want infinitely customizable software to sell. However, that capability comes at a cost along a spectrum of implementation techniques.
Unique build for each customer
In this scenario, salespeople promise unique versions of features on a tight time scale, forcing developers to use techniques like version control branches and tagging to track versions.
Permanent feature toggles
We introduced feature toggles in Chapter 3, which are sometimes used strategically to create permanent customizations. Developers can use feature toggles to build either different versions for different clients or to create a “freemium” version of a product — a free version that allows users to unlock premium features for a cost.
Some products go so far as to add customization via the UI. Features in this case are permanent parts of the application and require the same care as all other product features.
With both feature toggles and customization, the testing burden increases significantly because the product contains many permutations of possible pathways. Along with testing scenarios, the number of fitness functions developers need to develop likely increases as well, to protect possible permutations.
Customization also impedes evolvability, but this shouldn’t discourage companies from building customizable software, but rather to realistically assess the associated costs.