"Simplicity is the ultimate sophistication," Leonardo DaVinci said. This seemingly counter-intuitive statement is actually quite true.
It is relatively easy to look at every nuance of an issue—technical or otherwise—and provide a complicated interface, user experience, or explanation. It is far more powerful and difficult to find the simple and clear equivalent that really works. We respect the orator who can—with just a few simple words—make an issue clear for the audience. We seek educators who can take a complex subject and make it simple for us.
Simplicity can also be found in how we approach our technical work. Always seeking simplicity should be a fundamental value in engineering design. Most engineers know that. Yet it is so easy to get caught up in unimportant details that complicate what you are trying to accomplish.
Complexity often works, in the sense that a complex system still solves the problem—in fact, it may even solve it perfectly. The problem with complexity is in the difficulty of the initial construction of a system and especially in the ongoing maintenance of it. Typically, complexity increases costs and therefore decreases the likelihood of a project even getting off the ground.
The examples of the issues which arise from complexity in technology are numerous. This can be seen in the Reduced Instruction Set Computer (RISC) versus Complex Instruction Set Computer (CISC) debate in general computing.
The reason that CISC was able to resurge in recent years is that it allowed for optimization of the most important general operations. By simplifying the approach to chips again, performance was enhanced and stability was increased.
Ryan Somma Another example, closer to our industry is MXF. This standard attempted to solve a tremendous number of interoperability requirements. Some important. Some less important. This complexity resulted in real-world implementations that were not fully interoperable. Simplification was required.
There are numerous practical approaches that can be taken in engineering to help assure simplicity. An overriding rule is to try to slow down and take the time that you need to do things properly. Every engineer will instinctually seek a simpler answer when not rushed. Simplify your work life and do a better job at the same time!
A more subtle, yet powerful technique arises in the requirements phase of a project. Examine each requirement for how it is like another. This can be the most powerful tool in simplicity. If the requirement is much like another, then why are there two requirements? Can one be eliminated?
We have all heard of the 80/20 rule, but here is an opportunity to actually apply it during the requirements phase. Consider carefully the relative importance of the requirements you are faced with and focus your initial efforts on those requirements that are truly worth it. Doing this reduces and thus simplifies the require-ments.
Even if a requirement is a "no-brainer," you should still drop it if it isn't important. So many times these are the ones that become a problem, often because of unintended consequences downstream.
When entering the design phase of a project, look for more opportunities to simplify. Consider using a layered approach with layers of abstraction in your design. Push the lowest levels of detail down as far as possible. Stick to your layers and they will protect your design.
We have all heard that "the perfect is the enemy of the good." Find a way to make the design good enough. Don't make it perfect. Don't try to solve problems in the design that you don't truly need to solve.
During the build phase, another consideration in simplification is the structure of the vendors and integrators that you work with. Reducing the complexities in the responsibilities of the parties who will participate in the project will simplify communication and coordination. It wouldn't be wise to only select one vendor in larger projects, but being smart about vendor selection makes sense.
Reducing complexity in earlier phases of the project makes the testing and acceptance phase a little smoother. A less complex design is easier to test. Simpler re-quirements are easier to verify with users.
Arguably during the maintenance phase, maintaining the simplicity you have designed is most critical. It is easy in any system to allow ongoing requirements changes and other maintenance issues to turn a system into a spaghetti of technology that cannot be maintained. As requests come in to make changes to the sys-tem, the same philosophy that was applied in the requirements and design phases should be employed again. If it isn't important—even if it is easy—don't do it. If it can be done easily and effectively in the existing design, don't add a new complexity to the system.
Albert Einstein said, "Everything should be made as simple as possible, but not simpler." Despite all of the advantages of simplification, do not go too far with this advice. No problem can be reduced beyond what is reasonable.
It's quite simple really! Being smart about what is really important in all of the complexity in front of you is going to provide you with all of the value. You can Count on IT!
John Footen is a vice president at National TeleConsultants and the head of its Software Solutions Group. He is also co-author of the book "Service-Oriented Media Enterprise." He can be reached atjfooten@ntc.com.
