The smallest change necessary: Wise boss imparts important design principle
By Robert Cravotta, Technical Editor -- EDN, March 29, 2007
Being young and inexperienced, I interpreted this response as a lack of understanding of my grasp of the system operation and how I could make it work better. As much as I grumbled about the inefficiency of continuing to use the system as it was, I always ended up making the minimum changes necessary, and the projects moved ahead well enough through all types of technical ups and downs.
We were breaking new technical ground, and we had plenty of opportunities for an in-depth analysis of the failure data when setbacks occurred. We plowed the information we learned from that analysis right into the ground- and flight-equipment software. As the projects advanced, I realized how many lessons learned I was incorporating into the system software.
It wasn't until we handed the project equipment, software, and data to another development team that I realized how valuable those lessons were. At the handoff of the project to the new team, my role changed to that of a third-party-review member. (I learned another lesson in that role that I'll share in a future "Tales from the Cube.")
|
The new team comprised a set of ambitious engineers who, not unlike my earlier self, wanted to prove how much they could improve on the work of previous teams. This time, though, the team had wide reign to replace and rewrite whole subsystems, which manifested in the team having to relearn some hard-won lessons. When they replaced a subsystem, members failed to take the time to understand why the legacy system did seemingly unnecessary things in apparently trivial conditions. The team not only re-created challenges we had already overcome, but also complicated the failure analysis by changing too many things at once that were codependent on each other.
While living through these avoidable and frustrating episodes, I came to understand the wisdom of my technical lead's responses in denying my requests to rewrite the software just to make it "better." If he had granted my requests, I would have missed retaining some of the lessons that my predecessor learned and incorporated into the software. Further, I probably would have repeated some of the troubleshooting efforts that the previous team had already tackled.
The value of making the smallest change necessary to the system becomes apparent when you are working on a dynamic prototype and pushing the limits of your team's and industry's experience. The time for making the system operate better, without changing function, comes later in the project, when you have a significantly more mature understanding of your system's behavior and have shifted your focus to reducing costs by squeezing out the inefficiencies.
For additional discussion of this topic, read and comment on Robert Cravotta's related blog post, " The consequences of redesigning a complicated embedded design from scratch ."
Share your Tales from the Cube and receive $200. Contact Maury Wright atmgwright@edn.com.
