You need details of what the development team have provided, how it works, and how the operations team will run it. Even a basic level of how it works, and what to do if it doesn't will prevent some poor sod on the nightshift struggling to cope with a simple problem like a full disk.
Whether it's code, operating instructions or incident management any team of larger than zero will benefit from writing it down. And the benefits grow exponentially - which is why any large team lives or dies by its processes and documentation.
A developer once told me that his program didn't need documenting as "my code is perfect". But even that "perfect" code did not exist in a vacuum.
The program specification was based on an third party data format that was not formally defined (leats not to us) and so the data was processed based on assumptions and empircal evidence. When an unforseen data case arose (in this case a stock market ticker symbol was altered when a company demerged) the program had no way to deal with it. The "perfect" program could only be be reset by restarting it - which meant it lost all current status.
Thursday, 22 November 2007
Subscribe to:
Post Comments (Atom)
Copyright 2007. 2008 Paul Davey
The author asserts his moral right to be identified as the creator of these works.
So if you think one of these phrases is pithy/worthy/funny I'd appreciate some credit!
No comments:
Post a Comment