Software isn’t easy mode, it’s a different level

Shuhao Wu just posted a great response on the differences between hardware and software development. In it, he makes the argument that because of the emphasis on rapid iteration and experimentation, we learn more easily/quickly in software than hardware development. I don’t think that this is universally true, and that looking at some of the differences reveals that there’s more at work than cycle time.

I was also an aerospace engineer, but I found that 10-year timelines and billion dollar budgets didn’t really appeal to me — I preferred the fast iteration, small teams, and intensely personal creativity that startups (and specifically software startups) offer. So I learned to code — python to node, backbone to angular, objective-c, and a bit of microcontroller development here and there. So while I don’t claim anything more than an opinion, I’ve been fortunate enough to see both extremes in a relatively short amount of time (about two years).

This is what I have learned. Your brain on software development is fundamentally different than your brain on long term [1] hardware development. When you’re writing software, individual hypotheses can spring up and be tested in a matter of seconds. You poke and prod at your code. You throw stuff away. You write better stuff. You’re always experimenting, because the only penalty is wasting your time.
It’s not without a touch of pride that some programmers speak of ther laziness. This isn’t the same kind of laziness that causes you to sleep late on a Sunday. It’s the kind of laziness that drives you to build tools that make your life easier as a developer. You share these tools, and other developers become more efficient as a consequence. There is nothing (generally, depending on your work environment) to discourage you from experimentation. It’s often where the most interesting and forward-thinking projects come from.

Let’s contrast this with engineering and similar disciplines. Experiments are expensive, failed experiments even more so. Doing genetic research with mice involves long periods of breeding and behavioral observation. Designing an aircraft is a constant battle with constraints, a balancing act where weight can spiral out of control at any second[2]. This is not an environment in which a lone developer with a bottomless pot of coffee and a six-pack of fine ale can build an MVP and prove something in a single sitting. It is an environment in which an academic and intuitive understanding of the underlying principles of a problem is critical — there is a visible absence of the many layers of abstraction (frameworks, compiled languages) present in software engineering.

So what do we do, faced with a higher penalty for failed experiments? We design experiments that don’t fail. We put time, thought, and energy into examining what we’re building from every angle. We spend an enormous amount of time trying to find reasons that it won’t work. Our job is to discover the failure cases preemptively, because we don’t have the option of discovering them retroactively. In terms of learning, I think that you can get just as much out of this process — it gives you a certain mindfulness that, while present in many good developers, isn’t a prerequisite.

The premise that you learn faster in software than hardware only holds true as long as you accept that the rate of learning is a function only of the rate of experimentation. I would argue that while experimentation is one component of learning (and the primary way that I prefer to learn), it is not the only component. What in getting at is this: I don’t think that we are able to learn faster in either approach. One just has more of a bias towards rapid iteration and experimentation [2], and the other has a bias towards long-term thinking, and getting it right the first time.

I’m not claiming that either of these approaches are superior — they each thrive in their respective environments, and each has a lot to learn from the other. In addition, I don’t think that most environments are optimized for a radical application of either approach, so you should mix the two in interesting ways and see what comes out.

[1] I say long term to distinguish processor and aircraft design from things that you can accomplish with an Arduino and a 3D printer.
[2] Actually a thing. In the early stages of aircraft design, your weight estimates are mostly statistical and based on similar aircraft. When you add weight, several of your components (lift surfaces, landing gear, tail) increase in weight as well. In addition you must carry more fuel to meet the same payload/range requirements, so your weight increases further. This cycle tends to continue. More here.

[3] Although I don’t believe that fast iteration necessarily equates to fast learning, I think that it can be extremely useful in any design process. When we were designing a humanitarian aid UAV, we ran countless simulations to determine the structural, aerodynamic, and control characteristics of the aircraft. We modeled the aircraft in CAD software packages, and fed these models into finite element analysis software to model the airflow around (and deformation of) the airframe. Sure, running these simulations took a bit longer than, say, compiling coffeescript, but we were able to learn a lot about our design before we put it in a wind tunnel.