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.
ARY all the time, if necessary; AI or no.
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.