ITER vs. iPhone: the two extremes of system engineering


When designing a complex product, there seem to be two very different kinds of challenges.

ITER, the International Thermonuclear Experimental Reactor, is a device with a clear customer requirement:  solve all world’s energy needs. It may or may not be possible to do with the Tokamak-like design, conducting nuclear reactions in thermonuclear plasma held together by a strong magnetic field. This game of scratching the boundary of technological possibility usually means that even if it will ever be found possible, there is  going to be exactly one way to do it. Every shape of every component of this mega-complex device of 15 billion euro, will be dictated by the laws of physics.

The iPhone is an example what we have on the other side of the spectrum. The device is a piece of plastic with a colorful touch screen, some radio frequency capabilities and very little else. It is a platform designed to run software, which will define its usefulness. In this world of endless possibilities, it is the designer’s job to decide what will actually solve the user’s problem, and even what the problem is, so that this device can solve it, in the first place. There’s no document of customer requirements. The customer would never know for life to tell what they are.

We call this technology driven and design driven solutions. The two types of engineering require different skill sets to get it done right.  This is what happens when the two are being confused. The managers at LG were probably spending money and yelling at engineers to squeeze a color screen and a bluetooth receiver into a tiny box. At the same time, what they were supposed to be doing is understanding how important is not to forget the pause position inside an hour long MP3 podcast, when the phone is switched off. The product definition person was probably writing specs about how a jumping lizard on a pink background would be cool to get more sales. He completely missed how cool would it be able to set a calendar alarm in less than thirty clicks. Unfortunately for their team, one would usually buy smartphone based on more than a glance at the store shelf.

Conversely, the software industry is full of technology failures conducted by people with perfect knowledge of what exact problem they are going to solve and how the solution will look like. It starts with hiring the wrong engineers to handle the complexity of the task. Sometimes it goes unnoticed, resulting in code that 99% works but is completely unmaintainable. It then continues with failing to invest in development process, testing, validation. Industry-wide, more than a half of software projects end up in a failure.

So, do yourself a favor and read five best books on how to manage your type of a product development, before messing it up.


Build a software firm in three hours, for $1000

When Runge and Kutta invented their numerical methods for solving differential equations, they did not mean it will be a computer algorithm, simply because they did not have computers in the 19th century.

Several standards for building a software development organization list processes which need to be carried out to make the whole thing work. You absolutely need someone to do HR, someone to do marketing, someone to do risk management (and if you never heard of ISO15288, please do yourself a favor and go read it now). The good news is, that in the modern outsourcing marketplace, you can hire specialists in any of these tasks – within hours.

oDesk is a mega-marketplace for outsourcing/off-shoring jobs. From Creative Writing and Document Translation, to Data Entry, QA and Software Development, oDesk trades tasks of different complexity and size, from hours to months. oDesk offers pretty good UI, employee tracking features (including screen monitoring for per-hour employees), and a reputation/ranking/review system for both employers and employees.

oDesk features:

  • Instant hiring – find candidates in hours and hire them in seconds. Same goes for firing, of course, which makes the hiring less risky than in the real world.
  • Cheap workforce – low-qualification tasks, such as “fill a table with what you can find on google about..” may cost as low as $1/hour, shipped overseas. As it always happens in free market, things becomes cheaper for the buyer and more expensive for the seller.
  • Scheduling freedom: some company actually hired a QA team in the time zone to get them bug reports overnight.
  • Finding candidates with a very specific, narrow skill set. If you need to make a Firefox plugin, or an iPhone app, you will likely find a dozen engineers who have finished a similar project just a week ago and have the API class names fresh in their memory. If you need to do online marketing survey from sites in Japanese, you will have it two orders of magnitude cheaper than local experts. Same goes for proofreading, improving English and translation.
  • No need for tedious task prioritization: hire as many people as you like. No need to wait while your in-house team gets to that.
  • Fixed price/per-hour payment.

You can review past works/employment history on oDesk itself, with employer reviews. oDesk also offers series of qualification tests for candidates.

The interesting part starts with giving hiring privileges to a contractor. If you have a software product idea, hire a recruiting specialist to find the right people to raise a complete firm from scratch. Have separate people write the spec, design, draw screenshots, code, test it, have them all interact, make them hire you a marketing team to set up a google ads campaign, and also to register a paypal account for sales. Needless to say, you can monitor them all from your smartphone.

This is how idea-to-market time can be shortened dramatically. On the other hand, if you are an engineer (or other information worker) stuck in the middle of nowhere or born in a less happy place on the planet, oDesk enables you to sell your talent without leaving the chair. This is how oDesk makes our world a better place.

Peaceful co-existence

A zoo attendant explains a sensational show – a lion and a lamb sharing the same cage.

“How did you guys do that?” a visitor asks.

“Very easy, ” says the attendant. “Just replace the lamb every morning.”

…and this is how you cover up for design flaws during the project maintenance phase.

Semi-Automatic Umbrellas

Ever heard your developers respond “this is impossible to do” to a customer request?

This morning, the wet season, also known as “winter” begins in Tel Aviv. A guy walks into a store. “Listen,” he says to the storekeeper, “do you have an umbrella that not just opens, but also closes on a button click?”

Well, of course not. That would contradict the conservation of energy, and consequently the time translation symmetry – a basic property of the universe we all live in. What a stupid customer.

“No,” says the shopkeeper, “but I will give you something else”. And then, to a certain degree of surprise, he takes out an umbrella with two arrow buttons on the handle. When you press the up arrow, the umbrella shoots and unfolds violently. Then, if you press the down arrow, it folds quickly – but does not shrink to original size. The remaining 1/4 of the process is for the user to do in his spare time, charging the spring system for the whole new cycle.

This real story is to demonstrate only one thing: spec and design documents cannot always be separated. What the customer really needed, was to stay dry by quickly folding the thing when he boards a bus. He did not, mind you, need a perpetuum mobile.

Inventing such a device is possible only when you get both the model of a customer and the system design constraints into one mind. Product managers may falsely assume that they are supposed to analyze the customer desires and translate them into a spec for the technical people to implement. The developers, in turn, may often trick themselves into thinking they are being paid to implement a list of features. In fact, both groups are supposed to establish a high-bandwidth communication channel to link the two complex worlds, to be able to convert customer requirements into customer needs.

[Credit: I first heard of the invention from AF. Today I actually saw it in action.]