Draft 0.01 / October 5, 1999
This is a dumping ground for notes to myself. Many of the items here have been moved to either Hints to System Designers from Ops or Human Side of System Administration.
The Principle of Least Effort: "Progress doesn't come from early risers -- progress is made by lazy men looking for easier ways to do things Time Enough for Love, p71 Also the short story called "The Man How Was So Lazy He Couldn't Fail" by Robert Heinlein. This story described a man who was extremely successful, not through great efforts on his part, but because he chose a 'path of least resistance'. He recognized when he was up against insurmountable forces, and chose a different course of action.
Change the problem that you are solving <Unistrokes example>
Fix problems at their source - vendors, engineering, etc. Feed knowledge back to people developing systems
Do it once by hand. The second time document it. The third time write a tool.
You can always incrementally add one more.
Sometimes the straw breaks the camels back. More often, the camel just goes slower and slower.
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: 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.
Adding 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.
Bruce-Brigg's Law of Traffic: At any level of traffic any delay is intolerable.
Joyce's Law of Bathroom Hooks: A bathroom hook will be loaded to capacity immediately upon becoming available.
If you don't have access it is impossible to support... quite while you are behind.
Westheimer's rule: To estimate the time 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.
For every hour late a night or weekend project starts, it ends two hours late.
Instrument and measure (objectivity is your friend)
You can only hit something if you have something to aim at
You get what your reward... be very careful about what metrics you choose <ping test>
Don't confuse the process with the result. <user's don't care about backups, only that you can restore their files.>
Some people write the most gorgeous code but can't deal with human beings. Some people know how to knit system together by write clumsy code. Other people are extremely personable. A diverse staff can be a real strength. Know what you bring to the party.
Understand how temperament / Myers-Briggs effects how people do their jobs (Please Understand Me II)
software engineer, architect, integrator, PM, educator, tech writer, facilities, vendor relations
Many organizations try to fix problems by outsourcing them. This almost never works. Making something work as an outsourced item requires well designed interfaces with clearly understood expectations. Requirements need to be well understood, performance metrics need to be carefully crafted and design to encourage the outsourcer to work in the clients best interest. You need to remember that outsource vendors primary goal is to make money, not to deliver the very best service.
The other type of outsourcing that works well is when you want some sort of service which is commonly needed by multiple orginizations and don't need much customization. In these cases, outsource firms may be able to achieve economies of scale which allows them to deliver a higher quality service for less cost and hassle.
Most IS/IT/IM organizations grow along a common path. The group starts small with the staff doing everything. Eventually the ongoing activities are commodities and an operations group is formed. This is almost always a good thing to do. Unfortunately, most groups continue to divide the organizations up along a horizontal in the hopes that they can scale their organization. In really large organizations you end up with a food chain which is:
Political > Discovery (New Technology) > Architect > Design > Implementation > Operations
Alas... there is so little connection between folks that whatever is thought of up at the head almost never makes it down to the arms and legs of the organization. I believe organizations follow this path because splitting an operations team out works so well.
Rather, IS/IT/IM teams should form teams vertically around areas of expertise. This actually scales better because the up-down communication is typically much more bandwidth intensive than the cross-functional communications.
Not: if you are structure around a particular product or project, you typically want to structure horizontally.
distributed -vs- centralize -- knowing where to split the work.
Some people live for adrenaline
When to split. Realize that anytime you split a group you have an interface which needs to be documented and maintained. My experience is that you can easily burn 2 FTE maint a good interface (specs, reviews, extra documentation, etc). So you should only split something out when you are getting a good return and that the split allows groups to work more effectively by shielding them from other details. Separating architecture from design from implementation is almost always wrong. Separating technologies and mostly independent systems makes good sense.
2nd system effects