I work in a monolith driven development environment.
The application is now so huge, that rather than reuse code, team members just add new but very similar methods for new features, because you can no longer identify the code you should be reusing/tweaking for that new feature, because it's lost in a sea of shit code and complexity, maintained by multiple developers (some good, some bad, some awful) over the last ten years.
Closely tied to Customer Driven Development, where be features get developed because customers are willing to pay for the development, even if the change doesn't make much sense, or is being used to mimic a bad manual customer business process.
In fact, companies that do this are probably more successful than not.
Your customers are your source of revenue, 'what they want' is good for your business :)
In the early stages of a company, before mass market adoption, it makes sense for companies to please whoever they can before 'lift off' into broader adoption.
So many companies got their start this way. Microsoft, Oracle etc..
From an architectural standpoint, it may sometimes seem 'impure' but then you really do have to ask yourself what you are building and why :).
I largely agree with you. The challenges with this largely fall on the business side. I've once worked at a place where a customer agreement was structured in such a way that tied up our development and QA resources for resolving issues for them that weren't due to a fault on our product. For a small company of ~10 developers, we spend an awful amount of time tying up resources on tracking down issues that ended up being bugs in their own software; they just happen to discover them while using our product. And we really didn't get all that much money from them, either. It's not uncommon for a small startup to tie themselves up with a poor customer agreement for the sake of name recognition or misplaced hope in the agreement opening doors down the road.
CDD is when a customer is convinced to buy very expensive software that amounts to nothing more than a cosmetic upgrade to their existing broken process.
What you perceive as 'cosmetic' might be some really minor thing ... but it may be absolutely critical to your customers operational needs. Remember if you have zero IT ability than the smallest process change can be a huge pain.
Example: Customer Service may be a great chance for customers to give a heads up about things that are broken or needed features. CS Reps might hear about it all the time. But they have no way to log that information, or for it to be refined. Product leaders therefore are screwed: there most important feedback is lost.
With a small change to CSR, staffers can make note of things, put priorities, now if there is a 'blow up' in a release, product can know about it right away.
The application is now so huge, that rather than reuse code, team members just add new but very similar methods for new features, because you can no longer identify the code you should be reusing/tweaking for that new feature, because it's lost in a sea of shit code and complexity, maintained by multiple developers (some good, some bad, some awful) over the last ten years.
Closely tied to Customer Driven Development, where be features get developed because customers are willing to pay for the development, even if the change doesn't make much sense, or is being used to mimic a bad manual customer business process.