Boyd’s Law of Iteration: In implementing complex systems, it is better to act quickly than perfectly.

Boyd decided that the primary determinant to winning dogfights was not observing, orienting, planning, or acting better. The primary determinant to winning dogfights was observing, orienting, planning, and acting faster. In other words, how quickly one could iterate. Speed of iteration, Boyd suggested, beats quality of iteration.

The next question Boyd asked is this: why would the F-86 iterate faster? The reason, he concluded, was something that nobody had thought was particularly important. It was the fact that the F-86 had a hydraulic flight stick whereas the MiG-15 had a manual flight stick. 

Without hydraulics, it took slightly more physical energy to move the MiG-15 flight stick than it did the F-86 flight stick. Even though the MiG-15 would turn faster (or climb higher) once the stick was moved, the amount of energy it took to move the stick was slightly greater for the MiG-15 pilot. 

With each iteration, the MiG-15 pilot grew a little more fatigued than the F-86 pilot. And as he gets more fatigued, it took just a little bit longer to complete his OOPA loop. The MiG-15 pilot didn’t lose because he got outfought. He lost because he got out-OOPAed. 

I’ll state Boyd’s discovery as Boyd’s Law of Iteration: In implementing complex systems, it is better to act quickly than perfectly.

From Simple Architectures for Complex Enterprises (PRO-best Practices) (Best Practices (Microsoft))

I stumbled across this book in the local Barnes and Noble and opened it to a random page. This story. Interesting...

"How to recognize a good programmer" ☛ http://inter-sections.net

Positive indicators:

  • Passionate about technology
  • Programs as a hobby
  • Will talk your ear off on a technical subject if encouraged
  • Significant (and often numerous) personal side-projects over the years
  • Learns new technologies on his/her own
  • Opinionated about which technologies are better for various usages
  • Very uncomfortable about the idea of working with a technology he doesn’t believe to be “right”
  • Clearly smart, can have great conversations on a variety of topics
  • Started programming long before university/work
  • Has some hidden “icebergs”, large personal projects under the CV radar
  • Knowledge of a large variety of unrelated technologies (may not be on CV)

Negative indicators:

  • Programming is a day job
  • Don’t really want to “talk shop”, even when encouraged to
  • Learns new technologies in company-sponsored courses
  • Happy to work with whatever technology you’ve picked, “all technologies are good”
  • Doesn’t seem too smart
  • Started programming at university
  • All programming experience is on the CV
  • Focused mainly on one or two technology stacks (e.g. everything to do with developing a java application), with no experience outside of it
via inter-sections.net

"…most of the systems that people are building that are of any interest are ones where there’s always something that’s broken."

The issue of how does the network impact the design of a programming language is huge. As soon as you’ve got a network, you have to deal with diversity; you have to deal with communication; you really have to think about how failures affect things; you have to worry a lot more about reliability. In particular, you have to worry about how to build systems that can be robust and continue operating in the face of partial failures, because most of the systems that people are building that are of any interest are ones where there’s always something that’s broken. And the traditional view of software has been that it’s sort of an all-or-nothing thing; it’s working, or it’s not. And a lot of those sort of concerns feed into things like the Java exception mechanism, the strong type system, the garbage collector, the virtual machine, and on and on. I mean, the network had really profound effects on the design of Java, the language and the virtual machine.  - James Gosling