|Over-engineering? (Portland, OR)|
With all the success SpaceX is having, we should not forget the problems and misses of recent launches, for example an shut-down in-flight and problems with thrusters required to get the Dragon to the ISS when in orbit.
From the SpaceX Updates page:
After Dragon achieved orbit, the spacecraft experienced an issue with a propellant valve. One thruster pod is running. We are trying to bring up the remaining three.One may look at these issues and be concerned about SpaceX design, manufacturing quality, engineering, redundancy and what not. I am actually encouraged by these glitches.
From where I am sitting as a software industry professional of 17 years it looks like SpaceX is taking a page out of the software industry, where over-engineering is the silent killer of projects, causing them to be late, costly, and even dead on a much late arrival. Obviously if these problems would deteriorate missions into catastrophes we wouldn't be praising SpaceX, but at the same time I would actually be also worried if SpaceX didn't have any problem whatsoever. The space (no pun intended) between failure and over-engineering is the sweet spot that allows companies and projects to be successful by moving as fast as possible with positive results and subsequently keeping cost down.
As a young engineer I confess I wanted to create the perfect design for everything I did, build it with no compromises and call it done when there were no bugs left. Many gray hairs later and time in the real world there's a phrase I repeat every time an existing component, application or software architecture is compared to a suggested one - "Unwritten applications are perfect". There are no compromises, no bugs, no problems in a product that lives as a PowerPoint presentation, Word document or the back of a napkin.
As a product moves through the digestive tract that leads from people's minds to a product, it reaches a right of passage, a decision point if you will - continue to tinker until it is "perfect", which is asymptotically never, or make it good-enough, willing to iterate after it ships, realizing this version is not the last. As a perfectionist in rehab it is important to remember that. A French proverb captures it well - "Le mieux est l'ennemi du bien." (relevant also to this post on which I've been working on and off for a couple of months...)
Consciously making the choice in advance to not release an imaginary product but instead a real one means it will have problems, but when these happen, no one is surprised and the system as a whole is robust enough to counteract and built with change in mind - from cameras that have a firmware that can be upgraded to software components that validate their input, all the way to airplanes being able to land with no engines or a Falcon 9 rocket that can operate with only eight operational engines.
Let's face it - sh*t happens, so assuming it doesn't or worse - assuming one can work on a system until it is perfect, both carry great risk to actually completing a mission or releasing a viable product.
In the next few years I bet SpaceX will show us that it can continue and iterate on its success, yield better and better products and show us that over-engineering should not be found not only in software but also as part of rocket-science.