4 ms·

There is a tendency in Software Development, that terms lose their meaning the more they are used. I think it is partly due to software people not talking concr

There is a tendency in Software Development, that terms lose their meaning the more they are used. I think it is partly due to software people not talking concrete, physical objects that much, but more about abstract ideas with more or less relevance to reality. This can lead to interesting effects. For example, I have heard "DRY - Don't repeat yourself" most times I encountered it as a reasoning for obsessive refactorings, where functions where extracted from code without any regards to abstraction layer just because a few lines of code looked the same (or could be rewritten to look the same). But originally the term was coined to represent the principle of "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". "DRY" was however so catchy, that the slogan propagates without the explanation of the principle. I think agile suffers a similar fate. Countless consultants, managers and engineers have rendered the word almost meaningless. Even with the Agile manifesto at hand, it is sometimes hard to free agile from the multiple layers of paint spread over it. DevOps suffers the same fate, and while I haven't researched this, I assume that even waterfall is probably a gross misrepresentation of the original ideas.

crdoconnor 9y ago
I think DRY is actually an axiomatic principle of good code. However, there are several axioms and they all conflict, so maximizing one at the expense of the others means you are writing bad code.
- wirrbel 9y ago
  Do we have the same understanding of code being DRY? Because it is not an axiom. It is a guideline on reducing errors, that are enabled by writing the same information in various places of your code. As opposed to "reduce code duplication at all costs" which does emphasize textual/structural equivalence. https://twitter.com/BonzoESC/status/442003113910603776/photo/1 https://twitter.com/BonzoESC/status/442003113910603776/photo...
  - crdoconnor 9y ago
    When I said there are several axiomatic principles and they conflict that's ^^^ precisely what I was talking about. Reducing duplication at all costs is harmful.
    - wirrbel 9y ago
      okay, I guess I am nitpicking on the word axiom ^^. DRY-as-in-the-original-sense is not an axiom because you can actually give good and simple reasons from which you can deduct the principle. You are definitely are right in the sense, that treating soft truths as "hard facts" is a problem in software.
      - crdoconnor 9y ago
        No, I do mean is that properties of good code can all be boiled down to a set of fundamental principles. I think one of the defining features of all of those principles is that they directly conflict with one another. Good code means achieving a local minima, because up to a point, maximizing any one of these principles (e.g loose coupling) will inevitably violate one or more of the other fundamental principles. I.e. maximizing loose coupling often has the side effect of violating DRY or ramping up language complexity (another fundamental principle). I don't think you really can derive DRY from other principles, though I'd be curious to hear what you think it could be derived from.
maxxxxx 9y ago
Nice summary especially about the real intent of DRY and how people implement it. I think what it comes down to is that software development is very complex so any attempt to produce cookie cutter rules will fail eventually. OOP is a good idea, Agile is a good idea, DRY is a good idea but you still need the judgement to see how it applies to your specific situation. I started doing this in the 90s and I feel that there is a growing trend to replace judgement with process and strict rules.
- wirrbel 9y ago
  Agree with the first part of your post. > I started doing this in the 90s and I feel that there is a growing trend to replace judgement with process and strict rules. Hmm, I am not quite sure whether I share your sentiment on process and strict rules. I don't mind process if it is actually one that is sensible and leaves freedom to the individual. For example, in my experience as a developer, Scrum can drastrically improve developer-management communication. Story point estimation with estimation cards has always revealed stories with unclear scope or requirements. This requires however, that both sides actively try to improve that process. I have often heard of people who said "Scrum doesn't work" who actually were really running a very weird subset of it (for example burndown charts and velocities, but no proper story point estimation), etc.

crdoconnor 9y ago

I think DRY is actually an axiomatic principle of good code. However, there are several axioms and they all conflict, so maximizing one at the expense of the others means you are writing bad code.

wirrbel 9y ago
Do we have the same understanding of code being DRY? Because it is not an axiom. It is a guideline on reducing errors, that are enabled by writing the same information in various places of your code. As opposed to "reduce code duplication at all costs" which does emphasize textual/structural equivalence. https://twitter.com/BonzoESC/status/442003113910603776/photo/1 https://twitter.com/BonzoESC/status/442003113910603776/photo...
- crdoconnor 9y ago
  When I said there are several axiomatic principles and they conflict that's ^^^ precisely what I was talking about. Reducing duplication at all costs is harmful.
  - wirrbel 9y ago
    okay, I guess I am nitpicking on the word axiom ^^. DRY-as-in-the-original-sense is not an axiom because you can actually give good and simple reasons from which you can deduct the principle. You are definitely are right in the sense, that treating soft truths as "hard facts" is a problem in software.
    - crdoconnor 9y ago
      No, I do mean is that properties of good code can all be boiled down to a set of fundamental principles. I think one of the defining features of all of those principles is that they directly conflict with one another. Good code means achieving a local minima, because up to a point, maximizing any one of these principles (e.g loose coupling) will inevitably violate one or more of the other fundamental principles. I.e. maximizing loose coupling often has the side effect of violating DRY or ramping up language complexity (another fundamental principle). I don't think you really can derive DRY from other principles, though I'd be curious to hear what you think it could be derived from.

maxxxxx 9y ago

Nice summary especially about the real intent of DRY and how people implement it. I think what it comes down to is that software development is very complex so any attempt to produce cookie cutter rules will fail eventually. OOP is a good idea, Agile is a good idea, DRY is a good idea but you still need the judgement to see how it applies to your specific situation. I started doing this in the 90s and I feel that there is a growing trend to replace judgement with process and strict rules.

wirrbel 9y ago
Agree with the first part of your post. > I started doing this in the 90s and I feel that there is a growing trend to replace judgement with process and strict rules. Hmm, I am not quite sure whether I share your sentiment on process and strict rules. I don't mind process if it is actually one that is sensible and leaves freedom to the individual. For example, in my experience as a developer, Scrum can drastrically improve developer-management communication. Story point estimation with estimation cards has always revealed stories with unclear scope or requirements. This requires however, that both sides actively try to improve that process. I have often heard of people who said "Scrum doesn't work" who actually were really running a very weird subset of it (for example burndown charts and velocities, but no proper story point estimation), etc.