If It’s Not Written Down, It’s Not Done

Do you ever have those moments where you solve the same problem again because you didn’t write down how you solved it the first time?

When you’re running hard, particularly in the early-going of a new company or product, the temptation is to let documentation go until everything else is done. After all, things are moving so quickly, the theory goes, that documentation would be obsolete as soon as you create it.

What you’ll find, however, is that you and your team will waste significant time re-solving the same problems if you don’t write down the basics. As a guy I used to work with always said “If it’s not written down, it’s not done.”

At a minimum, for any technology product, you should have an up-to-date README that has the following information:

• A brief description of the product and how it works
• Any prerequisites required on the machines where the application will run
• How to install, configure and get the product running

For an example of a simple README, here’s one of my projects on Github.

I have a love-hate relationship with documentation, as do most developers. I hate doing it, but I love it when it’s done and available.

As we talked about in a previous post about knowing where all your stuff is, continuity of information allows the entire team to move more quickly over the life of a project and de-risks your business.

Your Assignment

Take a quick look at the README in your project’s source code repository. Does it exist? When was it last updated? Ask your developers if the README is up to date for your project. The best way to test is to have someone on the team follow the instructions provided to the letter and see if they work.

If your documentation is incomplete or doesn’t exist, have the team start getting it into shape asap.

Remember, it’s not done until it’s written down.