@morbiuswilters said:You sound like one of those documentation freaks who believes writing every single thing down will make their software and systems perfect. Most of the work I do is interoperability reverse engineering. Things like "I have this thing in Project Server with a custom field, and I want to get the custom field back, and I don't want to use the API cuz I just don't. Help??" Having a functional spec of how Project Server saves its custom fields, for example, saves me from having to grovel through the databases and write it myself.Even ignoring my niche, some documentation is still useful. There are exceptional circumstances where things which normally are done aren't, and having an explanaiton there shows that it was a conscious decision rather than an oversight.@morbiuswilters said:Then you defend the actions of a DBA who enacted a change to the design and business logic without asking anyone or documenting it.There was a second part to my post, you know. I think that the DBA screwed up badly. He should have asked someone for sure, and if there was a spec he should have changed the spec. I think he's a complete and total fool and should not have a job. I just recognise that he might not have been solely to blame; some of the programmers I work with think nvarchar(50) is T-SQL's only datatype, and others usually don't add indexes because they just don't remember, things which it falls to me to clean up when my boss gets yelled at for our apps being slow. Since this system was documented, and was designed well before the DBA got involved, it is all the DBA's fault.