FPO-Case-Featured-Image

I want to take a break from code for a moment to talk about outer space and how to get there. You may have heard of the famous Fisher Space Pen. [iframe src=”http://www.youtube.com/embed/ODO0zQBPI2k” width=”560″ height=”316″] https://www.youtube.com/watch?v=ODO0zQBPI2k

The Requirements

Space travelers need a pen that can write in the following conditions:

  1. In a vacuum.
  2. With no gravity.
  3. In temperatures of +150°C to -120°C (302°F to -184°F)

Lots of American brainpower and dollars were employed to develop a pressurized ink cartridge to fulfill these requirements, while the Russian space program chose to use a pencil. They moved on to other requirements of the larger task which was getting people to space and bringing them back safely and efficiently.

Snopes.com says that the numbers involved in the cost of developing the pen have been inflated over the years, and were spent by an independent inventor, so the story is considered apocryphal. But like all great stories, just because it didn’t happen, doesn’t mean it isn’t true.

The Right Stuff at the Wrong Time

If you need to get to the moon and back, you need astronauts. I think astronauts are great at working on big products which perform tasks that need to be highly optimized on a variety of hardware. Software like video games or 3D graphics packages need astronauts who can build and support products with big budgets and long development cycles. These kind of projects can take years to develop and are very high risk, even for big-name products. There are teams of specialists on such projects, and copious budgets for quality assurance (QA). The smallest details need to be thought out ahead of time and scheduled across the teams. But even then, you need to factor in extra time for the corner cases that nobody thought about, or last-minute “must have” features. But since all of those schedules and budgets you wrote last year are now wrong, you need to rewrite them and add another six months of development to your timeline.

In Soviet Russia, software develops you

Not all projects have the same level of risk, and many are developed on a much faster timeline. Cosmonauts are good at adapting to rapidly evolving requirements and fast turnaround times. A cosmonaut knows that the sooner he puts a prototype into a client’s hands, the faster it can solve their problems. Maybe the principle stakeholders are not very technical, but have a vision for an end product and need help turning their hazy notions into a polished UI. When you work in consulting, you don’t always have the luxury of picking your clients. Every organization has strengths and weaknesses, and as a consultant you are there to provide them with skills they may not possess in house. It can be challenging to speak about technical issues when the core competency of your client is marketing. A cosmonaut can talk about more than just code, he can understand complex business requirements quickly from a wide range of industries and turn those into working products that amaze and delight users. Sometimes all you have is a single developer,  a sketchy list of requirements in a Google doc (which is still being edited) and a budget of X hours. This fairy tale of a specification describes broad business logic goals with perhaps a tiny bit of thought about specific UI elements if you’re lucky. There might be no thought given at all to the overall UX. This is not a “spec”. This is a mere speck of a spec. This is the moment when a good cosmonaut pulls out a pencil and starts sketching. The business processes are digested quickly and the development begins immediately. If this is a web application, should it be built on multiple pages or is it a single page app? What Javascript libraries do we know of that can fill that calendar requirement on page 6 of the spec? What solutions do we need to research to make sure we can meet all requirements on time and under budget? Cosmonauts may not have all the answers handed to them, but they knows where to find them quickly.

Developing in a vacuum sucks

In the consulting business, you often need to be able to quickly build a prototype to demonstrate a proof of concept and then iterate over that prototype until you have a minimal viable product (MVP). At that point, you’ve jumped over a lot of hurdles that sprung up unexpectedly and that insight has given you a much deeper understanding of the core requirements. Some call this stage Alpha or Working Prototype, but the truth is you don’t have time or budget for specific “phases”, but you do have an incremental path to product perfection. At this point, you have a core of code that you may need to re-factor, and a bunch of UI/UX elements that could use improvement, but at least you have a working product and some good ideas around how to refine your work. To put it in terms of our metaphor, you’ve got a rocket that gets you to space and back, and now you’ve got time to worry about secondary requirements like space pens. It’s time to get this puppy into the hands of some real world users and find out what features they really need to make their jobs easier. The bottom line is a successful outer space ecosystem (developer group) needs both astronauts and cosmonauts, and sometimes you might need to be a little of both. Both will get you into space, but which one to choose depends on what you want to do once you’re up there. If you need to get into space quickly and safely in order to build your own Death Star, call some cosmonauts.