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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s