DRY as a concept needs to have better bounding. I think it's counter productive in many instances. (Albeit highly useful in others.) I've observed discussions

DRY as a concept needs to have better bounding. I think it's counter productive in many instances. (Albeit highly useful in others.) I've observed discussions with people citing it becomes particularly pathological when DRY is employed by Enterprise Architects. From my experience I tend to agree with that statement. I think RFC's (SHOULD, MUST, NOT, etc) with a reference implementation are a much better approach. If you want to move quickly use the reference. If it doesn't fit your use-case for whatever reason, document why you're branching out and get on with it. Obviously this approach poses an issue where documentation diverges from reality but ideally writing it down first will help clarify the objectives. Ideally the ABI/API for anything that's shared wouldn't be changing that much so maintaining the document shouldn't be too erroneous. If it is it might be an indicator to encourage duplication. Pieter Hintjens RFC's for ZeroMQ is a great example of what I mean; https://rfc.zeromq.org/ https://rfc.zeromq.org/ The GraphQL spec is pretty good too; http://facebook.github.io/graphql/October2016/ http://facebook.github.io/graphql/October2016/ Yes all of these things take time to write up but if you're going to constrain someone by saying "use this and under no condition nothing else" then it should be well documented.