Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
You may have heard that there is no right answer. It’s a favorite saying of some fine arts professors. It’s designed to prevent favoring one approach to a problem over another. However, in the technology world, this is correct, but the thinking is backwards.
In most technology situations, it’s not that there are too many solutions; there are not enough. The key is finding alternatives to your initial solution when it doesn’t work out.
Real World Problems Don’t Have One Easy Answer
While in educational settings, we are conditioned to believe that there is one easy, correct answer that, when we find it, the clouds will part, the sun will shine, and there will be heavenly music playing all around us. Real world problems do sometimes have simple answers; however, I have yet to see the clouds part even once when I’ve realized the simplicity of a solution.
In the real world, it’s not always the first approach that leads to an answer. It’s also not always the second or third. Finding answers often requires attempts at multiple solutions and combinations of solutions until an acceptable answer is found.
It’s important not to seek a single right answer to problems. Doing this is a fool’s errand that often ends with disappointment. Rather, being open to multiple possible, probable, and good solutions is a prerequisite.
Don’t Take No for an Answer
One of the most difficult things is to learn when “No” doesn’t mean “No.” It may mean, “I don’t know how.” Or it may mean, “not this way.” Often, when we confront others to ask them how to do something, their immediate response is that it cannot be done. It’s impossible, they might say. Often times, this simply means that it’s beyond someone’s experience.
I get the “No” message all the time. In integrating one product with another, I’ve heard it countless times, in countless different forms. Nearly always “No” melted away once I tried a few alternatives. Whether it was routing the information through a third system, designing a custom integration component, or simply trying a non-standard implementation strategy, the “No” didn’t really mean no.
Often, younger, less experienced professionals hear the word “No” and run away in great fear. It was as if they had been confronted with a giant who refused to let them pass. This is something that naturally fades a bit with time and experience. It is also something that you can consciously defend yourself against. Before you just accept “No” for an answer, consider whether it is really a no, or if it’s simply that the path has not been trodden before.
Seek Outside Input
No matter who you are, you live inside the prison of your own mind. We are all prisoners to all that our experience and learning has taught us. As a result, the solutions that we find are confined to that world. Instead of beating our heads against the proverbial wall trying to find another solution, it is often good to share the problem, or parts of the problem, with peers. This is especially true when the peers that you have as resources have a radically different background than you do.
One of the things that I’ve learned from those I work with is that someone who is focused on core network connectivity sees things very differently than a software developer or someone responsible for server infrastructure. In fact, the very source of conflict between the groups can be a powerful way to find solutions.
When faced with a performance problem, the developer might immediately jump to fixing the SQL queries so that they execute faster. The server people might seek a new, faster server, and the network connectivity staff might focus in on the latency between the application server and the database server. None of these approaches in themselves may solve a performance problem; however, together, there is the possibility that a solution can be found.
The Best of Both Worlds, Please
More often than not, the best solutions don’t exist in a vacuum. They are simply an assembly of parts of other potential solutions that would never make it on their own. Let me describe one real-life example.
I was confronted with a situation in which a client with 300 regional locations needed to implement an employee review system. The system would be electronic for the tabulation of data but would need, contractually, to be signed off on by the employees being reviewed and the reviewer.
These documents used to clog up an internal mail system designed to get critical documents to each location and then back to the central office. As a result, they wanted to implement an electronic forms solution. The solution supported electronic signatures; however, there was a problem. The organization couldn’t implement the requisite public key infrastructure (PKI) to allow electronic signatures to be used.
The current physical system wasn’t working because of the errors, the cost to transport the reviews, and sheer logistics. However, neither would the completely electronic eForms solution work. After much deliberation, it was decided that there was a solution that met the needs of the customer.
Each form was given a serial number. That serial number and the associated entries on the form were hashed using the MD5 hash algorithm used by some electronic signatures. This MD5 hash of the form data, including every response, was printed in barcode form on a signature sheet. The signature sheet also contained other barcodes for the form’s serial number, the user’s ID number, etc.
This sheet, and not the whole form, was faxed in and recognized automatically by the recognition software. This information met up with the eForm data already in the system, including the MD5 stored with the form. The result was that you had tamper proof assurance that the form didn’t change since the employee was reviewed.
Ultimately, this saved hundreds of man hours of data entry and enabled better reporting. However, this was done with a solution in which neither the fully physical or fully electronic solution would have worked on its own. It’s the solutions like this that require skill in alternative problem solving.
Learning How and What
One of the important parts of the previous example is that we needed to know how electronic signatures worked and what the objectives of the project were. Learning these pieces showed the team that there were effective solutions that could blend technologies.
Conclusion
Alternative problem solving isn’t as simple as telling someone to just try something different, nor is it as complicated as launching a man to the moon. By understanding that there are multiple answers to a problem, not being stopped by the failure of a single solution, seeking the input of others, and combining solutions, you can become an expert at alternative problem solving.
About the Author
Robert Bogue, MCSE (NT4/W2K), MCSA, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He writes on topics from networking and certification to Microsoft applications and business needs. Robert is a strategic consultant for Crowe Chizek in Indianapolis. Some of Robert’s more recent books are Mobilize Yourself!: The Microsoft Guide to Mobile Technology, Server+ Training Kit, and MCSA Training Guide (70-218): Managing a Windows 2000 Network. You can reach Robert at Robert.Bogue@CroweChizek.com.
