SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 

The Details are in the Small Print

By Phil Factor,

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.

 
Total article views: 42 | Views in the last 30 days: 1
 
Related Articles
BLOG

Develop a High Availability/Disaster Recovery Strategy

Develop a High Availability/Disaster Recovery Strategy – Protecting your company’s most valuable a...

FORUM

Documenting SQL as a Administrator not Developer

Documentation, SQL Server

ARTICLE

Application Developers don’t own their data

As a data guy, I always smile when application developers refer to ‘their’ data. If only it were tha...

FORUM

Development strategy

How do you handle development in your company?

ARTICLE

Document Your Database

Computer professionals are constantly complaining about the documentation for the software they use....

Tags
database weekly    
documentation    
editorial    
 
Contribute