How To Make The Systems Guy Love You

"The most common problem with specs is when they’re written by someone without any idea of the things programmers really need to know." That's true. But the real problem here is the fact that when the project goes sideways, and the stakeholders are in a tizzy over the divide between what has been specified and what has been delivered, you as a developer, or architect, or project manager, need to have a 'CYA' strategy.

So, how can you both try to deliver what the business analysts have promised, while also covering yourself when things go wrong? The strategy isn't an earth shattering secret. 

You communicate and document. That's the biggest and simplest self-preservation strategy out there. If you're doing your job right, make sure there's a papertrail attesting to that point.

Spend some time making your solution configurable. That way it can adapt to a change or two when the top architect gets fired, and the new architect comes in and wants to assert her authority.

And of course, keep your configuration routines separate from your data routines. And keep both of those separate from your code.

Then, bring it all together. Will the end result win your programmer of the year? Perhaps not, but a configurable, layered, well documented project with a well communicated history will deliver an end product you can defend to the death if the need arises.

For a more clever and in-depth analysis of the situation, head over to Mock's blog and read the entire article on how to make the systems guy love you.

I don't agree with “Documentation wasn’t mentioned in the spec” excuse explained here. Required documentation should be included in specs (the "common sense" argument mentioned in this point seems more like an excuse). Acoording to the required documentation (diagrams, documents, etc.) you can plan the required effort (somebody must pay the work!) in order to built it.

Also, sometimes documentation is redudant. Some people say tha if you need to document too much, it may be indicating that your desing is not clear enoguth. In Java, for example, you can understand some frameworks just by undersanding the design. Because of this, I think that “It’s so simple it doesn’t need documenting” and “My code is self-documenting” are sometimes are valid.