I hold that the more simple a solution gets, the more time that is required to think all potential system issues through, especially if you're in an industry where failure means loss of money, life or property. It would probably be a good exercise to inspect the history books and see who signed off on a "simple idea" that later came to mean the loss of his or her job and shame to the organization.
Sure, extra features have extra complexity and this is why people shy away from number of parts. Even in the electronic world, the rule of two's apply. Consider a binary system that has two 2 elements - on or off. The number of potential states is 4. But if you have 3 elements, the number of potential states are 64, not 8 as some many imagine! Since failures often like to happen at interfaces, you may imagine what the possibilities are for potential failures if a system had 10 elements and all states were relevant. Its daunting that a quick calculation shows number of states being exactly.... 1.23794e+27!
Having worked in the turbocharging world, I quickly absorbed that this principle has another side to the coin. Automotive turbo manufacturers like to keep their trade secrets, especially when it comes to the technicalities of aerodynamic enhancements on the compressor maps. Fortunately, the mechanisms of varying nozzle area to manipulate expansion ratios were not so erudite.
Honeywell's VNT turbos used a handful of movable vanes whose angles were actuated electrohydraulically by proportional solenoid, as this animation here shows. Within turbo circles, people called that complicated. Cummins Turbo Technologies had patented a moving vane wall and fixed shroud design to do the same thing, this vane wall actuated by an electronic actuator via a series of gear reductions and linkages. Interestingly, another private turbo guy whom I had the pleasure to talk with had accomplished nearly the same function simply by applying a swing valve in his turbine housing which was then actuated electronically.
In the end, which design would you say was more simpler?
If you look at it from a mechanical point of view, you might say the switchblade in the turbine housing design. Looks simple from the outset, right? Well, it actually depends on the system variables you chose when you considered your system design.
One manufacturer who currently has variable geometry turbos in their portfolio kept mechanical movement simple in the interest of cost. In the validation stages however, they had more than a headaches to face. Field units were coming back with foreign object damage on their vanes which interfered with vane movement, oil leakages arising from improper assembly processes that polluted the unit and curiously, a case of intermittent interference issues between vane and shroud that required frantic brainstorming to minimize customer dissatisfaction. The latter as it turned out was a systems latency issue that the mechanical department had little grasp of.
The reality check here is that, you need one eye on reality at all times. Keep it simple stupid is not always simple as you think. If you design something really simple and fail to take account of all the system interactions that can make or break the design, you've not made anything simple, infact the outcome might spell trouble in the future.
"Simple" could also require more development and testing time.
A case in point where that applies is in the graph below which shows that the number of development flights to validate a surface launched missile in the 1970's had an interestingly linear and inverse relationship with cost. Apparently, complex systems require little testing. They require most cost to validate, sure, but this upfront development cost might just mean lower life cycle costs in the long run. It has been said that the space shuttle, a 3 billion dollar vehicle with hundreds of systems, required fewer than five development flights.
I recall a funny incident during the course of my undergrad years when we were designing an off-road buggy for intercollegiate competition. The final chain drive from jackshaft to the rear axle was a full 22 inches in linear distance center to center. To transfer this 10 horsepower, a bombproof motorcycle chain was selected with 1/2 in. pitch.
We quickly realized the law of transference of energy in failures - one hard component will transfer its wrath to a weaker element which will then fail in graceless fashion Hence, this heavy chain drive needed a tensioner or it would chew away at the steel sprockets during sudden load transients and stall our car.
We brainstormed with ferocious intensity and came up with multiple solutions. When it was crunch time and we had a just a few more days to complete build, one team member proposed a "simple" idea to prevent modification of the chainguard itself. He evangelized a flexible polymer idler sprocket that would sit in between the tight and slack sections of the drive which would rotate with chain movement and be completely encased within the existing chainguard.
It was simple and cheap. And what the heck, it looked great on the company website where the product was shown running on a chain in a stationary drive application. It should have worked in our application as well right?
Not quite. Soon after we bought this $35 item and installed it, it had teething problems and it wasn't long before one of us would open the chainguard to find the worn out tensioner lying loose inside the case. The engineer in this case had misapplied a product that worked well on a stationary industrial application. However, its softness and compliance were completely ill-suited for a moving application where shock loads and transients of chain operation were in effect.
The funny part of this story is that as Murphy's Law would dictate, we would stall our car this way for the first time precisely on the day of competition at site. In the end, we ended up fabricating a more rigid tensioner out of steel which held plastic idler wheels to push down on the chain. We also changed our guard design to accommodate this setup. That extra machining time and modification might have cost us more, since in the real world, you have to hire a fabricator and his skills to do the work for you. And that is the dilemma of a systems engineer. To reduce risk and keep the same performance, you need to increase cost.
So as we have it, KISS is not so simple to implement. As our regulatory world of engineering gets more and more stringent with durability, safety and environmental issues, engineers must let go of the burning torch of simplicity and learn to embrace complexity especially in light of the industry they are designing for. What are your experiences on this topic? Please leave a comment.