For most of us, when we get right down to it, our focus is on solving our customers' problems (whether they are part of the same company we work for or not is irrelevant). If we are wise, we are constantly searching for better ways to get the job done, either more efficiently to save resources, or more effectively to provide higher value. We're always on the lookout to improve our repertoire of tools.
In the technology world, there is certainly no shortage of tools, and more become available all the time. As geeks, we love our gadgets: our utility belts are stuffed beyond capacity. The calculators of the '80's were replaced by the PDAs of the '90's. There were the slide rules before that for those of us who care to admit it. The beat goes on.
Project managers can sling a mean Gantt chart, analysts deftly wield their class diagrams and ERDs. As we expand the notion of tools from the physical devices to the conceptual ones, the options available to us increase significantly, the number of intractable challenges diminishes. Problems arise, though, when we learn a new tool and suddenly believe we can now fix anything.
If a tool is one way we can get something done, one way to achieve a goal, there are a couple of important considerations. First, it is likely that there is another tool available that is just as reasonable to achieve that same goal. Particularly as we consider conceptual tools, there is rarely a situation that must be resolved using one specific approach: quite often, there are a number of approaches that will suffice. Second, all tools will have their constraints and limitations: there are some situations where a particular tool is only marginally applicable, some where use of that tool is downright wrong. I can't think of a failure mode for a VCR where a hammer makes sense.
We get into trouble when we become proficient with one tool at the expense of all others. There are many project managers that will dive into Project at the first hint of trouble, and CFO's that will do the same with Excel. Analysts can fall into the trap of thinking Use Case for everything they need to understand, every role in an organization seems to have its default tools. For most complex jobs, though, it is not a question of which tool makes the most sense, it is more a question of what variety of tools do I need to deal with all elements of this problem, and what is the most reasonable order for applying them.
The products we develop today are at least as complex as houses or automobiles, sometimes more so. We wouldn't think of trying to understand one of these with a single analysis tool, or attack every development problem with a single implementation solution, but in the software world this happens on many projects. While we can tinker with backyard sheds and go-karts, our skills and repertoire of tools will be exposed as lacking when we try to scale up to real world problems. Many shops have discovered the equivalent of that Ikea hex key, and struggle with many challenges where that key doesn't fit.
Whenever we run into a situation where we have a problem that doesn't easily yield to the tools we are most comfortable with, we need to step back and reconsider rather than attack the problem more vigorously with the same approach. It is usually a safe bet that for any problem we encounter as we are learning about our product space or implementing our solution, there is a tool that exists that fits that challenge very well. We need to constantly appreciate and learn how others attack and solve problems they face. If we are stuck in a rut, we are probably applying the wrong tool, and we should step back to reconsider our approach.
Take advantage of special member promotions, everyday discounts, quick access to saved content, and more! Join Today.