11

The DRY Principle (Don't Repeat Yourself) states that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system." Most of the time this refers to code, but it is often extended to documentation also.

It is said that every software system has an architecture whether you chose it or not. In other words, the software you build has a structure and that "as built" structure is the architecture of the software. Since a built software system comes with an architecture, is creating an architecture description of that system a violation of the DRY Principle? After all, if you need to know the architecture then you could always just look at the code...

Improve this question
5
  • Do you actually believe you can discern the architecture by looking at the code? The code will tell you all the functional and nonfunctional requirements, the architectural trade-offs,deployment issues, business context, use case scenarios, etc, etc? If you code can TRULY tell you that, that's one hell of a trivial system.
    – luis.espinal
    Commented Oct 12, 2010 at 17:06
  • @luis.espinal, It is possible to discern static and dynamic structures from the code and the running system respectively. Whether those structures are equivalent to a system's architecture will depend on your school of thought. As you've pointed out, you'd still be missing some big chunks including any architectural drivers and rationale behind design decisions.
    – Michael
    Commented Oct 13, 2010 at 4:40
  • What veritable school of thought equates code derived structures to a system's architecture? If we know that we will miss some big chunks including any architectural drivers,then we are missing the entire architecture. This proves trivially that the static and dynamic structures that can be discerned from code alone do not represent the whole of an architecture (independently of the school of thought.) If we look at pretty well established definitions of systems and software architecture (ie SEI's or INCOSE's), they are clear in that code is only a fraction of an architecture.
    – luis.espinal
    Commented Oct 13, 2010 at 11:30
  • case in point. A system's architecture might require me to deploy on a specific number of machines, with external interfaces being turned off and on in an specific order. Static and dynamic structures derived from code alone will hardly capture that (if at all.) Clearly however, these are part of the deployment and operational aspects of a system architecture. And any code derived structure will only pertain to the realizations of static aspects of a software application (or component) architecture. It can never be for a systems architecture.
    – luis.espinal
    Commented Oct 13, 2010 at 11:33
  • 1
    @luis.espinal, I invite you to submit an answer to this question! It sounds like you bring an excellent perspective that I think would add some real value to this topic. You're preaching to the choir on this, so why not create an answer which fully explains your thinking so everyone can benefit? It's why I asked the question in the first place.
    – Michael
    Commented Oct 13, 2010 at 19:45

5 Answers 5

Reset to default
11

Does duplicating your thoughts into code violate DRY principle?

Geez, if you could just know the architecture by looking into code, there wouldn't be such things as "architecture description documents" in the first place. It's not a repitition, it's another level of system description, which can't be trivially deduced from the code, and vice versa. So it has its full right to exist even if you embrace DRY.

Improve this answer
8

Don't take DRY as a hard and fast rule. It's a good thing, but you can only approximate it in practice.

Also I think it's not well written. "Don't repeat yourself" doesn't seem to cover the equally important case that to make a semantic or functional change you would have to edit source text in multiple places, saying different but coordinated things.

Rather than take it as a commandment not to be violated, it is better to understand why it is a good idea and make sensible choices about it. The reason it is bad to have to make coordinated edits in multiple places is that you, the editor, make mistakes. You are not 100% reliable to make the changes without error. If you have to make 10 different source text changes, and you only get 9 of them right, you've put in a bug. That is why arranging the source text to minimize the number of coordinated changes is a good thing. It minimizes bugs.

We don't belong to a religion in which DRY is one of the commandments. It is just a handy, though slightly misleading, way to encapsulate some common sense.

Improve this answer
4

An Architecture Description, or Software Design Description does violate DRY. However, in a large organization, where projects last years, developers come and go, and the system is too large for any one person to keep all the details in their head, it is a critical document. The amount of "repetition" needed to keep it in synch is totally worth it for the effort it saves during the next update or maintenance.

Improve this answer
1
  • 1
    That's a misunderstanding or blind application of DRY. An architectural description is not a violation of it. If one were to blindly apply DRY in this manner, then anything but the code is a violation of it... and clearly this was not the intention of those who came up with the the idea of it.
    – luis.espinal
    Commented Oct 12, 2010 at 17:11
2

An architecture description does not violate the DRY principle.

Your software system comes with an architecture, sure. And it's spread out over many files, in many classes, with many extraneous and details that are unnecessary for an overview.

Your architecture document should be like the first paragraph of a news report: it's an outline, a summary, a roadmap of the project.

Improve this answer
1

If you date the document, it then describes the architecture at the time of writing.

Whereas the code represents the architecture at the present moment.

Two separate things - not the same knowledge.

As long as you state that the document represents the architecure at the time of writing, you're not duplicating knowledge IMO because its different knowledge if its about the system at another point in time.

Improve this answer
1
  • Code never represents architecture. It is just a manifestation of the architecture. Code that was changed today might still represent the architecture of yesterday. Furthermore, it might not represent the intended (or contractually required) architecture, which is what you have to worry the most. Code doesn't tell you if it's right or wrong, only that it runs. To know if it is right or wrong, you have to look at the intended architecture and the requirements that drove the system to begin with.
    – luis.espinal
    Commented Oct 12, 2010 at 17:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.