Colour Your Environment

Have you ever been about to type a command and stopped to double-check if you’re on a test server or a production box? Or even executed a command and then had your heart stop because you weren’t sure which environment you’re logged in to?
One of the most effective ways to make sure you always know which environment you’re in is simply to colour-code. Use different coloured backgrounds on your desktops or change the colours of your menu bars.
When choosing colours I suggest the following:

  • Be consistent in your colouring. E.g. Production environments should always be the same colour. Never any other colour.
  • Use a simple colour scheme. Mark important differences rather than unimportant ones. For example, a 3 colour system: production, test and development environments.
  • Use a memorable colour scheme. For example, red for production to indicate “danger” or “stop”, because you need to be careful with production. Orange for “test” because you can be a little more relaxed but still need to be aware of other tests that are running. Green for your personal development environment, because you should be able to do anything on your own box.
  • Once you’ve picked a colour scheme, use it everywhere: paper folders, physical servers,  whiteboards, everywhere.

Hopefully, if you colour your environment, you’ll never have that “Production? Please don’t be production” feeling again.
 

Take Time to Go Fast

Imagine that you have to drive a long distance as fast as possible. Do you just jump in your car and put your foot down?

  • You won’t get there fast if you run out of fuel. You need to take time to fill up.
  • You won’t get there fast if you have an accident. You need to take time to drive safely.
  • You won’t ge there fast if you have to come back because you’ve forgotten something. You need to take time to pack properly.
  • You won’t get there fast if you pick a poor route. You need to take time to look at the map / program the SatNav.

We all know that, when driving, we need to take time to go fast.
Why don’t we understand the same thing about writing software?

Practice: Don't Repeat Yourself (DRY)

Description

To eliminate information repetition of all kinds.

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. Andrew Hunt and David Thomas (2000) The Pragmatic Programmer

This does not only apply to code:

  • Copy-paste (surface features of the code are the same)
  • Logical / Functional (the same logical process, but surface features vary)
  • Data (the same information in two different places)

But also to:

  • Documentation (requirements, for users etc.)
  • Software architecture
  • The software development process

To help you remember this practice, write out 100 times, “I will not repeat myself”.

Solutions

  • Repetition in process calls for automation
  • Repetition in logic calls for abstraction

Alternative Names

  • Single Source of Truth (SSOT)
  • Single Point of Truth (SPOT)

Forces Against

  • Ignorance of parts of the system (I didn’t know it was already there!)
  • Reliance on surface information rather then deep understanding. Assumption that is different because it looks different.
  • Reuse of existing information from several non-colsolidated sources.

Problem Overcome

  • Duplication requires that all copies must be maintained
  • Leads to larger code / data base, making finding defects more difficult

Contraindications

  • Automated derivation (eg. caches, generated code / documentation) where the original source is well know.
  • Certain optimisation techniques

Part of Development Lifecycle

  • All

Related Practices

  • YAGNI

Examples

  • Code reuse: Classes, subroutines, code libraries
  • Data Normalisation
  • Design Patterns

References

  • N/A