A few years back I worked for a defense contractor that suffered from what I call "bubble gum engineering". 'Bubble Bum Engineering' refers to the practice of adopting a new technology followed by discontinuing after a short period of time. Kind of like spitting out the bubble gum after the flavor is gone.
Our program was complex, a mission-critical self-propelled fully automated weapon system, and taming that complexity with a compressed schedule was a challenge, but one that we capable of addressing. What made the program more challenging than it needed to be was the fact that some of our software managers would take business trips across the country for meetings, and this gave them opportunities to sit next to anonymous vendors peddling their 'wares' and ample time to read up on the new 'sexy' methodologies. They'd drink in the articles or vendor solicitations with wide eyes and eager wallets only to bring back these 'snake oils' announced by a routine all-hands meeting.
Off we'd go with a dramatic change of direction, fast-n-furious with new training, new procedures, and new development mechanisms! Then, shortly after we'd settle in on the new methodology the bubble gum had lost it's flavor to our managers, who'd replace it with the even newer methodology/technique acquired on their last business trip.
Time-after-time we'd be directed a change of course, time-after-time we'd accept these new challenges with depleting zeal slowly chipping away at our schedule, our software stability, and our morale.
I've learned through these challenging trials that there is a limit to reducing the complexity of a problem. Fact is, the problem space of a program defines the minimal complexity of the system, however there is no limit (read that as infinite) to the addition of added complexity. You can take a moderately difficult problem and make it infinitely complex. That is the lesson I learned from that experience anyway.
No comments:
Post a Comment