1. Because you don't know what the root cause is. Often the problem / issue raised is just a side effect of the real problem. Finding the real one can be a nightmare.
2. Because you don't know how to fix it. Let's be honest, you would encounter things new to you and it requires some learning curve to actually be able to do it and another 10000 hours later (reference from Outliers) of using it to master the skill. Obviously, if you don't have the skill, you gotta learn it and learning takes time.
3. Because you have to test it if it affected other areas and was indeed fixing the issue and not hiding it. Testing alone can take a lot of time. Especially if the fix affects all parts of the system i.e configuration files, libraries, templates etc.
4. Because your boss or colleagues keeps on asking status reports or anything distracting every 30 minutes. Loosing focus can be as good as going back to square 1. I might be generalizing this extremely, but the point is, if you bug developers too much, productivity is easily cut by half.
5. Because of too much bureaucracy and/or politics. Too much guidelines, approval processes and overly gross security measures are counter productive. If debugging must be done in production, i.e bug is environment related, then access must be provided.
6. Because you have to get it tested and deployed. This one, is the last, because, often, business people are aware of the deployment schedules.
No comments:
Post a Comment