Apples, Acorns And Product Consistency
Seemingly brilliant designs by hot shot developers can result in big problems after the glory and bragging rights have been established. Some independent, arms length testing and review can save a lot of angst and anger before the customer does your QA.
In the days when things were actually manufactured, I once worked with a guy who could make anything out of apples and acorns. Nothing short of brilliant, with all the baggage that goes with it.
The problem was that he could only make one working prototype with the apples and acorns. He was a developer, and that small problem was not his – it was a manufacturing problem, and to him it seemed that all that they made were problems. That everyone was working for the same company never registered with him for some reason, perhaps because the brilliance was compartmentalized.
It took a while to accommodate the brilliance, which eventually became a net asset to the company. But it took a second layer of developers to turn that brilliance into practical products that could be reliably manufactured. This, of course, increased the cost of sales, which was eventually offset by higher valued products that could command higher prices.
Hyper efficient physical implementations of echo cancellation circuits and half adder encoders may not seem comparable to software development, but it is, particularly where a brilliant developer is concerned. In this case, the brilliance takes the form of highly abstracted code based on assumptions that all too often are not intuitive. They also have the unfortunate tendency to be very dependent on what might charitably called boundary conditions.
There is one difference between hardware and software. In the former, the number of building blocks is relatively limited, with each having a specific scope. The effort to redo one or more of these physical building blocks is prohibitive. This somewhat natural barrier does not exist for software.
Although OOD/OOP can limit reinventing wheels, the barrier to do so is not very high. It’s very easy to inherit and override, or add some interfaces, or encapsulate one thing in something else, any and all of which has the effect of changing the grain of wood. Like the manufacturing analog, an effective solution is to reuse tried and true components, make sure each boundary is clearly defined, and testing and review done by others who don’t have an intellectual or emotional investment in the brilliant design.
© Copyright 2009 Chuck Brooks for FutureWare SCG
A Word From Our Sponser
Have a lot of Logon IDs and Passcodes? Want to make sure you’re the only one that knows them? 
KeyRing keeps your personal information private and secure
Tags: OOD, OOP, product design, quality assurance, software development