I can't name examples, but I've worked for places where this happened, and the results were paralyzing. The only way to do it right is to add each feature as if all your customers were going to use it, but instead, people cut corners and write features in such a way that they only support the targeted customer(s). They compound the problem by adding special cases in the business logic to make sure the feature doesn't affect other customers even though it's broken for them. They add features for one customer that aren't even logically coherent for other customers. They lower their sights from "make this code work for every valid set of inputs" to "make this code work for all of our current customers, except the ones who won't notice because they don't use this feature yet."
The result is completely unmaintainable. You can't change anything because every piece of data has accidentally acquired special meaning.
"You can't remove the dog_shave_preferences column! It's how we distinguish between customers who were added before June 2013 and customers who were added after!"
The work to add a customer whose data doesn't trigger the right special case logic starts to be seen as a "new feature" rather than fixing bugs.
"Hold on, this is a fundamentally new set of requirements! We've never had a customer before who had the Bloop module enabled and had a logo bigger than 5k and wasn't AcmeCorp! We should have been aware of this new requirement before the customer went live."
The trap is how quickly people adapt to this kind of thinking, to the point where normal engineering starts to feel weird to them. I once quite seriously suggested creating a database table to record which customers a certain feature was broken for and had it shot down because people thought the byzantine special-case tests it would have replaced, which had no other purpose, constituted valuable business logic. The ideas and conditions we had invented to track the limitations of our code had started to feel like real business distinctions that they couldn't imagine living without.
Suffice it to say that eventually we slowed down to the point where declaring a feature freeze didn't feel like a drastic change to anyone, including our customers, and embarked on a substantial rewrite. It didn't end well. I've encountered another example that was a lot more sane (people knew they were doing the wrong thing all along and didn't actually start to believe in the reality of the distinctions they wrote into code) but it suffered from the same maintainability problems.
The result is completely unmaintainable. You can't change anything because every piece of data has accidentally acquired special meaning.
"You can't remove the dog_shave_preferences column! It's how we distinguish between customers who were added before June 2013 and customers who were added after!"
The work to add a customer whose data doesn't trigger the right special case logic starts to be seen as a "new feature" rather than fixing bugs.
"Hold on, this is a fundamentally new set of requirements! We've never had a customer before who had the Bloop module enabled and had a logo bigger than 5k and wasn't AcmeCorp! We should have been aware of this new requirement before the customer went live."
The trap is how quickly people adapt to this kind of thinking, to the point where normal engineering starts to feel weird to them. I once quite seriously suggested creating a database table to record which customers a certain feature was broken for and had it shot down because people thought the byzantine special-case tests it would have replaced, which had no other purpose, constituted valuable business logic. The ideas and conditions we had invented to track the limitations of our code had started to feel like real business distinctions that they couldn't imagine living without.
Suffice it to say that eventually we slowed down to the point where declaring a feature freeze didn't feel like a drastic change to anyone, including our customers, and embarked on a substantial rewrite. It didn't end well. I've encountered another example that was a lot more sane (people knew they were doing the wrong thing all along and didn't actually start to believe in the reality of the distinctions they wrote into code) but it suffered from the same maintainability problems.