Confusing does not always mean Wrong

In a recent project, a member of the client’s technical team was asked to look at software that had been written by other programmers. The more time he spent with the program, the more problems he found. He had issues that even a non-technical professional could understand, at least conceptually: the design was not good, the use of data tables was confusing, and the data was hard to locate.

There are many times that these types of issues are true and this is a costly problem for business. Unfortunately, this was not one of those times. This software was actually well designed and well written. It was the programmer doing the review that lacked experience with the tools and advanced systems. His wrong assessment was his response to being confused.

Worried WomanWorking on software projects, it is far too common for a programmer to look at another programmer’s code and declare, often with great authority and confidence, that it has major problems and has to be rewritten. Sometimes this is correct, sometimes it is not. Either way, it can be expensive.

In my first job out of college, I worked for a firm where we commonly modified software that had been originally written by outsourced contract programmers. Our team was really good at understanding the programming code written by others and then making changes and improvements.

It was only later when my career moved along that I really realized what a wonderful skill it was to understand the work of others without automatically declaring it wrong.

Of course, I will admit there have been a couple of projects over the years were I was so resistant to a quick response that I let the project go longer than necessary when a rewrite was actually the right and most prudent business answer.

This type of problem is very common in highly technical fields. However, the problem is suprisingly common in other areas we might not consider technical. I think most of us have been confused at one time or another by things like insurance, payroll taxes, and even the obscure rules of a sport.


When confused, our easy, quick response can be to declare that something is wrong. This is even more common when there is no one sufficiently competent checking this declaration for accuracy.

Just because you are confused by something does not necessarily make it wrong. Maybe it is wrong. Maybe you have not spent the time to gain understanding. Maybe it looks complex because you are inexperienced with the tools, the project, or the design. Maybe it is all of these things.

Learning to recognize our own limits is critical for our reputation and our messages. Understanding what we don’t know can be the beginning of real knowledge. Admitting these hopefully temporary limits is a step in communicating our real expertise and our credibility.


Glenn S. Phillips is the author of Nerd-to-English: Your Everyday Guide to Translating Your Business, Your Messages, and Yourself. His website,, will lead you to more information about effective communication training, risk assessments and genuinely helpful tips. You can email Glenn directly at

© 2011 All Rights Reserved.  Glenn S. Phillips and Forte’ Incorporated. (205) 985-1111


About the Author

Glenn S. Phillips works with leaders who want to leverage technology and understand risks within. An author and blogger, Glenn is often quoted in national media, plays a really ugly tuba (it even has a bullet hole) and is a fan of dark chocolate and great puns.