Original image from Engine Labs
One of the most common phrases to describe a task that is not as complicated as it seems is “It’s not rocket science!”. The phrase is as common as “It’s not brain surgery”.
The implication is that rocket science (or brain surgery) is vastly complicated and beyond the realms of ordinary men and women. Rocket scientists must possess a superior intellect to deal with all of the fantastical challenges and problems that their devices provide. After all, they put things into space.
It may surprise you to know that in my own experience about 5 percent of any “rocket science” project that I have been involved in required a deep and high-level knowledge of physics and plasmas. Most the issues that came up with ion thrusters, the particular type of space propulsion I dealt with, would not be out-of-place in any office, staff room or power plant.
What kinds of problems are the most common? Here are 3 challenges that a typical space propulsion project faces:
Challenge 1 — Over-complicating the design
Rocket science is a specialist field which means that people involved need to gain years of experience to get a handle on how best to design, test and deliver new rockets and propulsion devices. This is much the same as any company that deals in product development, be they for example, new types of household goods, cars or even houses.
Since propulsion devices tend to be designed for each mission, the practice is to make the device and system do many things. However, all this does is complicate the development process and increase the risk of slipping the schedule or not being able to deliver what you said you were going to.
Plans and schedules are usually drawn up with many lines and links, all showing how the varied aspects of the design will be built and when all the meetings will take place. As usually happens, taking the time to test the device is always predicted to be much shorter than reality; a symptom of over-specifying the design and not learning from previous projects.
Like any new product, if you over-complicate the design of anything, you tend to run into a lot of problems. This can be a new process, the look of a website, trying to teach a class or delivering leaflets to thousands of homes; not exactly a problem solely in the realm of rocket science.
Challenge 2 — Only dealing with numbers and schedules instead of people
It is amazing how the flash of a set of requirements gets the mind thinking about ways to solve all the intricate demands that the customers give you. It is almost like being given a mighty challenge like searching for the Holy Grail!
However, a part of the problem is that a requirements specification is a convention rather than the actual desire of the customers. What this means is that it is a formal way to capture the ideas of the customers, or it is a translation into “abstract-ese” what they really want.
A huge mistake, then, is to treat the contract and the requirements as the definition of what the customer wants rather than an abstract concept of what they want. As requirements tend to be written in an unambiguous, quantitative manner vast reams of schedules, predictions and analysis reports can be launched without actually finding out if they are worthwhile.
Putting it another way: loads of meaningless work can be done by taking the documents and numbers at face value instead of talking directly to the person and trying to understand their vision.
How many times in your own work has a new process of edict come down from high with an “effective immediately” command accompanying it? How many times are you told it will solve everything because what you did before was unproductive? Typically it is not helpful or useful but off you still have to go, filing papers, making up reports and generally being seen to be busy rather than actually being effective.
This happens in rocket science as well; in fact the more specific nature of the projects often tricks engineers and managers into thinking that space propulsion is different and that they need to “do it this way”; that the documents are the absolute truth and what people actually think is less important.
Challenge 3 — Doing too many things at once
The last challenge is the most recognisable in any workplace: being told to do or doing too many things at once and thinking you are getting work done.
This is almost a direct consequence of over-complicating the design and trying to do all the requirements that you are given with equal importance.
Where doing too many things at once really comes into play is when you test your devices. The simple issues are often the cause of so many delays and re-tests.
For example:
- Was the data recorder actually plugged in?
- Have you turned the engine on?
Because of the apparent time pressure due to over-complication, tests are normally stuffed to the brim with parameters to measure. What then happens is that they take longer to do because Nature does not get fooled that easily. You have to do things step by step and check everything. This would go a lot easier if you were not trying to build the best rocket ever!
As you can see, these very common issues that arise on rocket science projects have less to do with knowing equations and intricate theories and much more to do with trying to get a simple result without wasting your own time, money and patience. This is something common to a lot of jobs and situations so you might say that for most of the time doing rocket science is “not rocket science”!