The ten commandments of IT projects

And lo a new project did start and there was much wailing and gnashing of teeth, for up on the board had been nailed ten commandments that the project must follow and the developers were sore afraid.

1. Thou shalt put everything in version control, yeah even the meeting minutes, presentations and "requirements documents that aren't even finished yet" for without control everything is chaos
2. Thou shalt not break the build
3. Thou shalt never deploy to a shared environment anything that is not under version control
4. Thou shalt be honest about how long a task will take
5. Thou shalt test both the happy and unhappy path
6. Thou shalt automate everything that can be automated and do so early
7. Thou shalt not re-invent the wheel "just because"
• Most specifically thou art not Doug Lea, do not create your own threading library
• If you are Doug Lea then just use your own threading library
8. Assume Murphy's Law to be always true and never state "that is very unlikely to happen"
9. Code unto others as you would have them code towards you
10. Do not screw with the environment configurations without first verifying you are not messing things up for others

The punishment for breaking these commandments is to be relegated to the project management office and be responsible for the many and various Excel spreadsheets report that people outside of the project appear to hold sacred.  

-----

Now because I know that folks will look to interpret these things in many ways lets be clear on a few.

9. Code unto others as you would have them code towards you

This is important, you should write code that is designed to be understood by someone else and written in a way that if you came to it fresh you would be able to understand it.

6. Thou shalt automate everything that can be automated and do so early

This is important, too often people don't automate and more importantly don't automate early, trying to retrofit the automation once the project reaches a certain size.  You should really have everything automated before a single line of code is written, something that 'does nothing successfully'

5. Thou shalt test both the happy and the unhappy path 

8. Assume Murphy's Law is true

Too often I've heard the phrase "that won't happen" followed by "it happened in the first day in production".  This is why its really important to test the unhappy path and to clearly identify the bounds you are going to be operating within.  Hoping that something won't happen isn't a strategy.