I was clearing out some shelves the other day when I came across a vast strategy document I'd written for a multi-national about their IT development strategy. The contents outlined a variety of 'Agile' techniques and organizational changes that would underpin a business reorganisation. It was old. I flicked through it. 'Good stuff.' I thought. I leant it to a colleague who I thought would find it of interest. He admired its thickness and dignity, but I suspect he never read it.
Although I occasionally weep at the years spent writing such documentation that nobody reads, I've never lost sight of its importance. For example, Backup Strategy documentation is vital though, like the small print in an advert, it's there more to protect than to be read. It demonstrates to the organization that the team has thought analytically about the topic, in depth.
When people come into IT from another discipline, where they were used to reading documents and communicating their ideas that way, they are often astounded to learn that whole classes of IT Strategy documents are often purely tactical rather than informative. This is especially true where IT proposals will cause organizational 'restructuring' and possibly job loss. Such documents serve their tactical purpose better unread, although if you know how to delve into their 'small print', you can learn a lot about an organization, and the likely longer-term consequences of any proposed changes.
Planning and strategy documents are merely part of the broad spectrum of IT documentation. For programming, again, documentation shows that the developers have thought through the function and structure of their code, analytically. It is an essential part of any team process. Sadly, many developers often have a remarkable antipathy to the very thought of producing any such documentation, perhaps on the assumption that no-one will ever read. They will spend hours in rapt concentration on an apparently trivial and unimportant code routine, yet recoil in horror, like a vampire at garlic, when asked to document their work. Some even believe that it isn't part of their job, like a celebrity chef who refuses to help wash up. Others delude themselves with the belief that their code is 'self-documenting'.
Sure, there are many more exciting activities in life, but if you can master the art of writing the whole range of documentation that underlies the development and upkeep of modern business systems in the typical enterprise, then you are greatly empowered. If you can learn the higher and more zen-like skill of reading and understanding it, then you'll find that the 'small-print' in any organization is always illuminating.
Phil Factor.
