The Unwritten Laws of Systems Engineering

David F. McClinton wrote a paper on The Unwritten Laws of Systems Engineering. I thought of these during the recent discussion on Critical Path, in the context of "what other activities are taking place on a software project outside the context of writing code?

• Everything interacts with everything else
• Everything goes somewhere
• There is no such thing as a free lunch
• Configuration Management - never confuse change with progress
• Functional Analysis - never be afraid to start over
• Failure to Commit - better is the enemy of good enough
• Engineering documentation - if it is not written down, it never happened
• Planning documentation - never be above plagiarism
• Allocation of resources - a thing not worth doing is not worth doing well
• System synthesis - There is no shelf, to get the "off the shelf" part
• System integration - any interface left to itself will sour
• Work planning - plan your work, work your plan
• Contingency planning - we don't have time to do it right, but we have time to do it twice
• Assignment of tasks - nothing is impossible to the man who doesn't have to do it
• The problem of make work - don't keep polishing the cannon ball but do get the caliber right
• Design validation - any analysis will be believed by no one but the analyst conducted it
• Performance validation - one test is worth a 1,000 expert opinions
• Test planning - never conduct a test if you can't live with the result
• Time management - after all is said and done, a lot is said and little is done
• Briefing chart complexity - never use a word chart when a picture will do
• Systems risk management - never go in with the first wave
• More risk - never go in with the second wave either
• Management style - have the heart of a child, but keep in a jar on your desk
• Legal proof - deny everything, admit nothing, demand proof, and reject the proof

Mr. McClinton was for many years a Chief Systems Engineer at Lockheed Missiles & Space Company