A short while ago, I had to write a compelling document for a client about a library that I had developed during my tenure, call it A-Team Library or ATL . Having to learn the " eyes-wide-shut " culture to maintain the couples-of-decades old code and simultaneously develop on the top of it was very disheartening. It was time a lot of things were given fresh thoughts. Not the least of all duplication of code and functionality . But not just that. Like in a programming language, when there is more than one way of doing something, when those ways are opposing, it causes nothing but confusion. So was the case. The business seemed to be far from realizing it.Instead of showcasing the issues that were being faced and yet not realized, let me state the alternate - how things in such cases can be better: Business has to realize or let known: When the engineering team accepts the authority of the business in deciding the priority of features, the business has to be prudent enough...
Another effective [debugging] technique is to explain your code to someone else. This will often cause you to explain the bug to yourself. Sometimes it takes no more than a few sentences, followed by an embarrassed "Never mind. I see what's wrong. Sorry to bother you." This works remarkbly well; you can even use non-programmers as listeners. - From "The Practice of Programming" by Brian W Kernighan & Rob Pike.