Top 10 IT Rules

I started keeping lists long before Craigslist existed, (maybe guys called Craig do this sort of thing). In fact when I heard about Craigslist I thought this guy had stolen my idea, unfortunately, with the Internet today there is nothing that is sacred anymore. So, if this list helps you, use it, distribute it, pass it on, whatever! But, please indicate who the author is. There is actually a Top 40 List of IT Rules, coming out soon, so this Top 10 is just the tip of the iceberg.

We will start with Rule 0, naturally, because computers work in zero's and one's, so there has to be a rule zero. It is fittingly, more important than rule number 1, and will be referred to in subsequent rules, in fact you could call it the mother of all rules, cause if you fail to follow rule 0 you will get burned (which is another rule along the lines of Admiral Shallowater Murphy).

Strangely enough, many of these rules apply to other walks of life as well.

0. Rule Zero (ground zero). Make a copy (and file it). This is not just a backup, this is way more pervasive than that. Write a good paragraph - Ctrl-S, save it to disk. Going to the washroom - Ctrl-S, save your work first. About to make minor changes to some code - make a copy first. About to hand-out your only pencil sketch schematic drawing during a meeting - make a copy first.

1. Rule One: Get it in writing. My Dad always told me this, it's the most obvious rule in life, but the one broken the most often. Because, it applies to many, many situations where we chose not to invoke it, such as; informal meetings, minor changes or modifications, trade-offs, errant emails. How many times have we seen people try to build a system on vague, high level requirements? Get the details understood and get them in writing. Even better - get a picture or draw a picture, mock-ups save a 1000 words. We live in a visual world, so don't' just get it in writing, do mock-ups and wireframes (but explain them). However, do not get too bogged down on this. For example, I have seen situations where the client had a consultant come in and write the detailed system requirement and it took 2 years to complete. By then the system they needed was obsolete! The requirements had probably changed. Rule of thumb, it should not take more than 6 months to write detailed requirements, and if it does then you need to read the rest of these rules below.

2. Rule two: Keep it simple (de-mystify the business, don't add to the BS). Keep information systems simple, the new KISS, and Yes you can Shout it out Loud) Don't get hung up on too many small details -nothing is perfect, a small step forward is better than no step. Have a master plan, for sure, but do the detailed requirements one module at a time, and keep the language in plain easy to understand terms, i.e. keep it simple.

3. Rule Three: Nothing is as simple as it looks. We do live a complex world, so organize your work in building blocks and create successful steps along the way. Do your work in "chewable chunks", (thanks to a colleague of mine for that one). In other words, organize your work (and logic) in achievable tasks and building blocks.

4. Rule Four: Anything is possible. Think outside the box. This is true, given the correct amount of time and money, and / or a very creative and brave soul. Short-cuts can lead to innovation, and faster completion times. Don't sell a good idea short, don't be afraid to cut-corners, or leap buildings (maybe not tall buildings), but always challenge yourself, push yourself to think outside the box, or at least consider it.

5. Rule 5: Always have a Plan B. There are three certainties in this world; death, taxes, and Murphy's Law of Technology (anything that can crash will). So, consider the worst case scenario, and always have a plan B.

6. Rule six: Listen. (a) Listen to your customer. (b) Listen to your team members. (c) Especially, listen to your gut. In general always; listen to all three, then contemplate, revise and confirm - the smallest detail can cause a lot of grief. There are not a lot of good listener's in this world, so if you can do just this one thing well you will succeed.

7. Rule seven: Set deadlines. Nothing gets done with out a target date. Assign it to someone to do, and the chances of it getting done have just increased, significantly. It sounds obvious, but, many small tasks and good ideas, do not get handled in this manner, (this includes monthly goals and yearly goals as well as life long ambitions). Write it down and give it a deadline, chances are good it might get done, don't write it down and don't give it a deadline, and the chances are extremely good that it will NOT get done.

8. Rule eight: All deadlines can be broken. Doing good work is more important than making a deadline. No one will remember that you made the deadline if it doesn't work.

9. Rule nine: Test everything. Test your code, test your client's ability to receive your code (a dry-run implementation), test their ability to understand your work by setting up a JAD/RAD session and working with proto-types and beta versions. Test your client's ability to accept your work (this could be interpreted as getting progress payments after a UAT time period). Test your testers, test yourself.

10. Rule ten. Number it. This could have been rule two for the number of times I have see a list of items that are not numbered. "Is that task we're discussing paragraph 3 on page 2, oh, the pages aren't numbered either?" Give me a break. Three items in a bullet list might be acceptable, any more, and they need real numbers, letters, or both.

Craig M. Mackay, CMC.
Vice President, Information Solutions,
Nortak Software Ltd.
Ottawa, Canada