Something that I noticed over the last months while doing design reviews is that hardly anyone documents decisions in a design. Most designs I review are physical designs, which is understandable as most IT people are technical people who could not care less about logical designs. I am perfectly fine with that, although I do recommend taking a different approach, as long as you document why you are going down a specific path.
There can be specific constraints or requirements (both technical and business related) which justify your decision, but if you don’t document these constraints or requirements chances are someone will change the design based on a false assumption and who knows what it will lead to…
iHunger says
I agree with this in principle, but the cynical side of me thinks that documenting the decisions/constraints won’t prevent someone arbitrarily changing the design, it only means you can give them grief later for messing everything up.
Duncan Epping says
At least they can’t say they did not know about these constraints or requirements. I tend to add it to the beginning of the documentation instead of at the end so it is the first thing people see / read. (or skip for that matter…)
Nicolai says
Note to self, for the Defence exam ๐
Completly agrees on it though. The major drawback on this is that, it requires the reciever of the design to actually read it. ๐
daniel says
I didn’t use to document what I did before I started working in the defence industry, few people actually read and benefit from all the hours I put in documenting, but atleast now I know that if I have to do something twice I already know the pitfalls and all the information isn’t lost with me. Documenting a little is better than nothing at all, the rest is a matter of discipline.