Quality of design
I saw many instances in my career where I thought the initial analysis was poorly done, and processes were not cleanly separated. This led to variables being corrupted in unexpected ways. Coding standards cannot correct for poor analysis.
All too often, so-called design documents were a restatement of requirements: they said what was wanted but did not show how to achieve that. For 1950s programmers transcribing mathematics into Fortran, the requirements were often enough; but, for example, a modern database meeting modern requirements needs much more thought. Even a simple members list of an organisation should be more than just getting correct postage labels: e.g. reports on how many by county or country, ...
Design reviews ought to emphasise these matters, but often they don't. Management often feels they obstruct the need to get on with the coding.
I spent my career wondering how to turn an engineering graduate into a good programmer, and never did find the answer.
Biting the hand that feeds IT
