Design. Document. Deliver.

There is only one way to have a fully maintainable and supportable system: document what has been designed and implement what has been documented.

Anything other than should be considered as having its long-term supportability and maintainability compromised.

Now, it is sometimes inevitable and necessary that systems be put in place that have not been properly documented before build time. That’s okay, but what is required in these circumstances is acknowledgement and agreement up front that ideal practice is not being followed and  compromised system is the result.

I worked on a high-profile (and high-stress) project where comments from the managers were often like: ‘don’t worry, junior admin that’s working way beyond experience and expectations will have documented all the components’. That upsets me. Not only are the (supposedly) experienced managers absolving their own responsibility they are heaping pressure where it least deserves to be.

By agreeing up front that the expectation is for a system that cannot (and will not) be fully documented we are making an effort to reduce the stress on the implementer who already has the unpleasant task of trying to create complex applications on the fly (and inevitably feeling that they’re making the best of a bad job) by saying that there’s a shared responsibility when it comes to the later questioning of why nothing matches up.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.