The 6th Principle - Build Integrity In

Build Integrity In

The customer only sees the user interface, no matter how much work the developers have put into an application. It is important that the look and feel of the system comes naturally and features are helpful and not disturbing.

The result of your work must not look like a collection of small solutions, but as one integral system.

  • Perceived and Conceptual Integrity
    Perceived integrity is when a system appears to be knowing what the user wants of it next. Study the workflow of the future users and try to build this into the application.
    Conceptual integrity is the way the system is designed. When you need to rewrite most of the system in order to make small changes, then your design is rotten. Always keep in mind that development includes learning, making decisions and it is a process - you will never reach perfection.
  • Refactoring
    Complex problems do not always require complex solutions, but to find a simple solution requires more than one attempt. Use refactoring in order to maintain the integrity of the system. Refactoring means rewriting code which is no longer good enough or you have discovered a better solution during your learning process. Do not hesitate to do it, because stronger integrity adds value to your product.
  • Build and Smoke Test
    It is a best practice to run Build and Smoke Tests. Introduce an automated build process running every night, if practicable. The build process is best followed by an automated test run. This way you can easily keep track of progress and developers get fast feedback from effects of recent implementations.

Real Life Experience
Refactoring and automated builds are used at a company we know. The daily routines and processes are in place. However, the automated build process is not followed by automated tests. During the day someone gets stuck with his work, because of a problem he cannot explain from his part of the system. He starts to ask other developers, if they know about this. In most cases the problem was introduced as a side effect of an implementation someone else did. This results in a lot of wasted time, because the developers often wait for this problem to get fixed. It is less likely that you need to spend time asking around and waiting by using automated tests, because then you would already notice the problem in the morning and someone could take care of it.