Things We All Agree On

In contrast to HolyWars, are there general principles that most WikiZens believe in despite coming from different perspectives and language preferences? Here are some suggestions:

• OnceAndOnlyOnce

  • Although one may disagree on the DuplicationRefactoringThreshold, most agree that it is an important factor.

• CodeSize

  • All else being equal, less code is better than more code. Of course this must be balanced with readability, consistency, perceived value of strong-type-checking by some, etc.' (LinesOfCode)

• Change-friendly

  • Code should be change-friendly. In other words new requirements should not require a lot of rework. Often the pattern of likely future changes is in dispute, but at least we can document our assumptions about changes we target.

• Consistency/standards

  • The variations on ways to do things should be kept to a minimum unless there is a reason for a diversion. It is generally easier pick up work where somebody else left off if certain standards or rules are followed. It is also easier to swap implementations if standards are followed.
    • Note that there is some tension between this and OnceAndOnlyOnce. OnceAndOnlyOnce replaces a repeated pattern with an abstraction that is used instead of the repeating pattern -- typically a function call. Using the abstraction instead of repeating the pattern "inline" creates a new way to do the abstracted activity, which must then be learned in order to understand the code using the abstraction. Then someone reading the code will see least two ways to do that thing -- using the pattern in place, or using the abstraction. That's why applying OnceAndOnlyOnce to small, simple patterns is often a bad idea -- it just creates more things to remember.
    • Bureaucracies often fight this battle. They create dedicated departments to handle "common" behavior to have economies-of-scale. However, some departments don't like the service for various reasons, and thus duplicate some or all of the functionality of the standard service, but in their own way.

• Conceptual Reuse - Ideally the same concepts are reused for multiple purposes so that we don't have to reinvent the wheel or relearn different idioms for otherwise similar things. The file/pipe/stream equivalency in Unix is an example.

• Performance

  • We want things that run fast, run on cheap boxes, use less bandwidth, etc. However, how performance is weighed against other goals is still contentious.

• Quality

  • We want thing that run as we expect them to, without errors or crashing.

• Avoid Controversy

  • Working only on the uncontroversial stuff is a recipe for disaster. (Source: RapidDevelopment).
  • Please explain. It perhaps won't lead to promotions or knowledge expansion, but it can be "good enough".

• Avoid Risk - Stick with what is known and tried

  • Note that this can be different than "avoid controversy". Sometimes one finds oneself on a doomed train, and attempting fixing it would stir up controversy. (Of course there may be short-term risk versus long-term risk.)

• Demonstration or Proof of Correctness and Quality

  • We agree that it's nice to have confidence that programs and program components that will operate as advertised, especially when they were written by other people or TheNewGuy.
  • A program that has not been tested or proven isn't any less correct than the same program that has been tested and proven correct, but the level of confidence in the latter is much greater than confidence in the former.
  • This desire motivates such things as unit tests.

• Coupling with Problem Domain

  • We agree that, given all else is equal (such as efficiency), a program written in a manner that is tightly coupled with the problem it happens to solve is generally better than a program written in a manner that is difficult to conceptually connect to the problem domain (due to cross-cutting concerns, for example). This improves readability. It allows programmers reading the code to understand the problem being solved, and it allows people specialized in the problem domain (but not in programming in general) to understand, debug, and write their own programs.
  • This desire motivates DomainSpecificLanguages and languages that may readily be extended to match a problem domain. It also partially motivates AspectOrientedProgramming (along with OnceAndOnlyOnce), which allows cross-cutting concerns to be handled separately from the problem domain.

• Magic

  • We agree that we'd love to have computers that do exactly what we mean for them to do rather than exactly what we tell them to do.
  • We also agree that this isn't happening.

I think we can all agree on something vague enough that we can interpret to be the way we want it to be. The interpretation and expression of a principle is everything.

Perhaps if each is read with "all else being equal", then we agree on them. Most disagreements I see can be traced to the weighting of two or more of these against each other.