Many companies view paying for employees to learn as an unnecessary cost. Anything that is not tactical or does not produce immediate, measurable results is "fluff, and those who endorse opposing view are not considered serious-minded, action-oriented business people. But the absence of deep technical understanding drives a "more is better" philosophy, which leads to more elaborate gauges, more reviews, more audits, more inspections, and more checkpoints (because it is always "safe" to check and check again).And after few lines where they talk about different quality initiatives like ISO, Six Sigma:
On the surface, these quality initiatives demonstrate a "commitment to quality" and make people feel that they have accomplished something. In truth, however, they fail miserably in achieving those things that guide an intelligent and balanced approach to fostering quality in a PD process: the time, dedication, and hard work required for a deep technical understanding of that process.First, I'd like to add documentation into those "more is better" things. Same goes with different certifications and process models.
All of those things are used when those who doesn't have deep technical understanding try to control development process. They try to enforce some "best practices" they've seen in some publications without understanding them correctly and just think that "we must do this because everyone does this". There's at least two problems with this:
- If you only follow best practices, you're only doing what those who developed did few years a go.
- "Best practice" might not be the best in your context.
Maybe the root cause for all of this is that we tend to be lazy and try to take shortcuts when building our own ways of working. But there is no shortcuts. Yes, you can and should follow what others are doing. But you should find out why and in what context they are doing those things.
