One of the most compelling forces that drive engineers is the desire to do quality work. I’ve seen this time and again in various settings and I often think back to when I started doing technical work, when quality meant doing a quick test after writing some software.
My first technical job was in a research laboratory where a physicist or research associate would describe what they needed to have built. My colleagues and I would put together a prototype and were often surprised when the response was “great, I can use this right away!” Many times these prototypes were tools being used for other purposes and instead of reporting bugs, our users would just let everyone know how to work around the problems.
As developers and engineers, there was often the feeling that we could have done much better work under different circumstances. The researchers were satisfied with the “duct tape” approach of putting together ordinary pieces to build exceptional instruments for their experiments.
Just as some of that old software was “spaghetti” code that wasn’t well-structured, the assembly and wiring of pieces looked like spaghetti as well. But the experiments were usually successful and we were able to pat ourselves on the back for a job almost-well done.
I eventually found myself working again with physicists in the regulated medical device world. They were still able to hobble together impressive prototypes using the components that we built, but moving from prototype to production required more disciplined engineering. Requirements were more formal, testing was rigorous and we were satisfied that our designs and the resulting devices were good. We had built the next-generation gamma “camera” for medical imaging.
After seeing the first real product on the factory floor, I remember thinking that I would probably not want this device to take images of my own body, mostly because I still had the vision of the research lab and the way that things were thrown together in such as fragile way. It did not provide me the picture of a device that should be anywhere near my body. Of course, the equipment was quite safe and was a popular and effective diagnostic tool.
Some of my colleagues agreed. We had a completely different perspective of a product once we had been closely involved with its development.
Several years had passed and I had moved on to be a consultant, still in the medical device industry. One particularly interesting contract was overseas and I was fortunate to have a seat in business class during one of the flights.
That flight was my first time on the then new Boeing 777 so I was quite impressed and excited to be there. While waiting to taxi for takeoff, I struck up a conversation with my neighbor at the window seat who happened to be a retired Boeing engineer. As the plane started to move he pointed out the window. “I designed those engine supports”.
He mentioned that the 777 was the first aircraft to be designed entirely by computer, digitally rather than physically by assembling mock-ups. He explained that earlier aircraft designs were modeled as life-size mock-ups in large assembly halls. If a design change was requested for something, no matter how small, someone would need to go down to the model and change the pieces in place. All pieces had the responsible engineer’s name or phone number visible and although the pieces were life size, they were often made of wood or other easy-to-change material.
I was amazed and quite impressed with that older, trusted but simpler method of modeling the aircraft. With my own experience developing software, these newer computer-based design tools didn’t seem to be nearly as safe or complete as the old methods. I said that he must be placing a lot of faith in these tools to trust his own life to them.
“Not really”, he said. He told me that his faith was in the work that his colleagues and he had done and continued to do. The tools are there to communicate the designs, to make sure everyone was aware of the complexity of integration details. But the process through which everyone worked and to which everyone contributed was another key aspect that inspired their faith. They still modeled what they built using different methods and tools.
Building a modern proton therapy system for cancer treatment is a complex undertaking and it certainly has the potential to bring harm to people.
It’s not as complex as an aircraft, nor does it provide the same type of hazards, but it does require a different kind of quality system, risk analysis and overall design process.
Modeling the system components is an important part of that process for the same reasons it is for aircraft design. It communicates the structure and behavior of each of the pieces and communicates the details of the interactions between them to development and test engineers.
Modern tools using standards such as UML and SYSML offer real benefits, not only to larger and complex system designs. Many of these tools support requirement management and traceability, support for complete testing and validation of products, even support for risk analysis and automated document generation.
Today I can say that if I had to deal with my own cancer and proton therapy was a prescribed solution, I would be confident, even eager to be treated using the same equipment with which I was involved. My memories of components strung together in spaghetti-like fashion have been replaced with knowledge of the dedicated and outstanding engineers and physicists that understand how to communicate complex designs, including complete models of their work.
