De-duplication and normalization of software generally supports the idea of making your product configurable. Chasing de-dupe is a prerequisite part of the configuration complexity clock cycle. Things have to be somewhat normalized and centralized if the customer is going to be responsible for configuring them.
If you embrace duplication and using code as configuration, you can skip much of Mr. Bones' Wild Ride. This path is maybe preferable for certain B2B SaaS vendors. "We can't do custom code anymore" has been a really catastrophic take from management for some problems. Modern tools allow for "configuration" and its deployment to happen in very ergonomic, high-level ecosystems. Approaches like spinning up a common DLL and one project per customer means you don't have to worry so much. You have an opportunity to de-dupe, but it's not mandatory. Things that are truly common will be made known by their reference counts.
bob1029•8mo ago
De-duplication and normalization of software generally supports the idea of making your product configurable. Chasing de-dupe is a prerequisite part of the configuration complexity clock cycle. Things have to be somewhat normalized and centralized if the customer is going to be responsible for configuring them.
If you embrace duplication and using code as configuration, you can skip much of Mr. Bones' Wild Ride. This path is maybe preferable for certain B2B SaaS vendors. "We can't do custom code anymore" has been a really catastrophic take from management for some problems. Modern tools allow for "configuration" and its deployment to happen in very ergonomic, high-level ecosystems. Approaches like spinning up a common DLL and one project per customer means you don't have to worry so much. You have an opportunity to de-dupe, but it's not mandatory. Things that are truly common will be made known by their reference counts.