DRY is a comforting illusion, based on a misapprehension of how mid-scale enterprise code is actually developed. DRY's assumption is that there's sufficient organizational capacity to coherently design the "thing"; and that only one thing should be done in only one place according to some overarching vision - observationally, a vision missing in most mid-scale companies. My experience is that there's almost never a coherent, managed design in any but the smallest and the largest organizations. The former because of social scale, and the latter because of a necessity to deliver at scale.
In the middle bracket, it just doesn't happen.
Mid-scale applications are mostly developed in a form of loosely managed anarchy. Different teams, different incentives, different approaches - all without a competent traffic cop i.e. an architect. Those 10x architects just do not exist in the mid-scale companies, in my experience. The good ones move to high-scale companies, and the peter principle kicks in below.
If your team is responsible for a feature: repeat yourself as much as you need in order to ship the product. If it's really important, you'll come back and correct it later - within you sphere of responsibility and according to your incentives. Absent a competent architect's direction and managerial instruction, just repeat yourself as often as you need in order to keep the context sufficiently local to deliver what you're paid to deliver.
kayo_20211030•51m ago
DRY is a comforting illusion, based on a misapprehension of how mid-scale enterprise code is actually developed. DRY's assumption is that there's sufficient organizational capacity to coherently design the "thing"; and that only one thing should be done in only one place according to some overarching vision - observationally, a vision missing in most mid-scale companies. My experience is that there's almost never a coherent, managed design in any but the smallest and the largest organizations. The former because of social scale, and the latter because of a necessity to deliver at scale.
In the middle bracket, it just doesn't happen.
Mid-scale applications are mostly developed in a form of loosely managed anarchy. Different teams, different incentives, different approaches - all without a competent traffic cop i.e. an architect. Those 10x architects just do not exist in the mid-scale companies, in my experience. The good ones move to high-scale companies, and the peter principle kicks in below.
If your team is responsible for a feature: repeat yourself as much as you need in order to ship the product. If it's really important, you'll come back and correct it later - within you sphere of responsibility and according to your incentives. Absent a competent architect's direction and managerial instruction, just repeat yourself as often as you need in order to keep the context sufficiently local to deliver what you're paid to deliver.