Projecst

Rules of Thumb: Projects

Planning

Rule of Thumb 58: Never underestimate the destructive power of an idiot with a backhoe (or a pile driver, or a fishing trawler).

Rule of Thumb 59: There is no such thing as enough disk space, CPU power, cable already run, or network bandwidth.

Corollary 1: Alas, there is such a thing as too much.

Rule of Thumb 60: Sometimes a really bad answer is still the best possible answer.

Corollary 1: The lack of a good answer is no excuse for doing nothing.

Corollary 2: Don’t pretend that an answer is good just because you’re intending to implement it.

Rule of Thumb 61: In the long run, all decisions are wrong.

Rule of Thumb 62: Westheimer’s Rule: To estimate the time that it takes to do a task: Estimate the time you think it will take, multiply by two, and change the unit of measure to the next highest unit. Thus, a one hour task will take two days.

Corollary 1: If you think this estimate is utterly absurd, and you haven’t gone through some similar process, instead of multiplying by two, multiply by four and add 1.

Rule of Thumb 63: You can always incrementally add one more. Sometimes the straw breaks the camel’s back. More often, the camel just goes slower and slower.

Rule of Thumb 64: The difficulty of support does not grow linearly with the size of the site. Eventually your site outstrips your methods, and you must bite the bullet and move to new methods.

Corollary 1: Nobody bites the bullet until there’s not enough time to do the existing work. At that point there’s not enough time to make the changes.

Rule of Thumb 65: Adding one single instance of a new kind of computer, operating system, application, peripheral, etc, has a much higher administrative cost than adding one more of what you’ve already got.

Corollary 1: This is true even if you already have several dozen different kinds.

Corollary 2: If you buy one, you might as well buy 10.

Corollary 3: If you buy 10, you may as well buy 11 and keep one for spare parts.

Rule of Thumb 66: Application-to-application differences confuse everyone, especially users and support staff. Ditto UNIX-to-UNIX differences, etc. By contrast, complete consistency completely stifles improvement.

Purchasing

Rule of Thumb 67: If it can be shipped in more than one box, it will be.

Corollary 1: If you order 10 of the same thing and they are shipped in the same box, it’s just to keep you from noticing that they’re not the same revision.

Rule of Thumb 68: The detail that gets left off of the purchasing specification is always the crucial one.

Rule of Thumb 69: Free software isn’t free.

Corollary 1: Neither in the sense of “free speech” nor in the sense of “free beer”.

Corollary 2: This is not necessarily a bad thing, since most organizations trust neither free speech nor free beer.

Rule of Thumb 70: Free hardware is actually more expensive than hardware you pay for.

Corollary 1: Always look a gift horse in the mouth before you ride it.

Corollary 2: Look afterwards, too – the ride often jogs things loose.

Rule of Thumb 71: It will always cost you more to support a thing than the vendor told you. It will usually cost you more to support a thing than to buy it. Sometimes it costs 10 times as much to support a thing as it did to buy it. Refusing to support something often results in the thing being unusable. Once it’s installed, supporting a thing is sometimes cheaper than not supporting it.

Corollary 1: Before buying, make sure you’re committed to support – but see the beginning of the rule.

Rule of Thumb 72: For every dollar you spend on a client, expect to spend a dollar on a server.

Corollary 1: And vice versa.

Rule of Thumb 73: If you currently have a centralized solution, it lacks flexibility and what you really need is a less centralized solution. If you currently have a decentralized solution, it lacks consistency and is difficult to administer, and what you really need is a more centralized solution.

Implementation

Rule of Thumb 74: For every hour late a night or weekend project starts, it ends two hours late.

Rule of Thumb 75: The only way to be sure that you couldn’t have fixed it in the time you had is to fail to fix it in time. Giving up and backing out the change while hope remains is not a failure of nerve, it’s a sign of maturity.

Rule of Thumb 76: If you tell them that the new version is better, it isn’t enough better. If you tell them it’s worse, they’ll claim that it’s worse forever, no matter how much worse it actually is. If you set no expectations, you might find out whether it’s better or worse, but you’ll probably just learn whether your users are optimists are pessimists.

Rule of Thumb 77: The success of an upgrade can be measured by the length of time for which the complaints are trivial. It can’t be measured by the number of complaints, which is a constant. Nor can it be measured by the first complaint, which is always fundamentally irrelevant.

Corollary 1: It can’t be measured by the time until the first complaint, which is not only a constant, but also the smallest available unit of measure.

Rule of Thumb 78: No program is so obsolete that nobody wants it any more.

Corollary 1: No program is so new that nobody needs an updated version.