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.

Right tool for the right job

I've always believed that consistency matters, whether it be at the architecture or the technology level. Its just much easier to manage a team with differing abilities if there is a consistent model and implementation.

I'm fortunate however in that I've picked technologies that actually work. Pity two fools that I heard on the floor of JavaOne (Moscone South if I remember correctly) they were arguing, well lets say talking at each other, about the merits of two different Ajax libraries (I have no clue which). The discussion was annoyingly loud and annoyingly stupid. At one stage however there was a work of genius

One chap (lets call him Fred) said

"Yeah, but at least we agree that you can do anything in Ajax"

To which his friend (lets call him Bert) said

"Yeah, there isn't anything you can't do"

A chap wandering past threw in one of those conversation grenades that leave the discussion dead and the participants suffering shell shock

"Try writing a VOIP client"

Personally I nearly exploded trying to hold in the belly laugh that wanted to get out. The point was brilliantly made. Consistency is good, but make sure you are at least in the right technology ball-park for the problem you are trying to solve.

Consistency matters, but don't be consistently stupid

Technorati Tags: SOA, Service Architecture