trading some consistency for availability can lead to dramatic improvements in scalability. - Dan Pritchett
via queue.acm.org
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...
Summary
Stefan Tilkov discusses SOA basic concepts by making a number of claims, such as “Application architecture is irrelevant for your SOA” or “An ESB should not be at the core of your SOA”, followed by explanations and related recommendations.
via infoq.com
Level headed discussion of REST vs. WS-*
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
In technology, once you have bad programmers, you're doomed. I can't think of an instance where a company has sunk into technical mediocrity and recovered. Good programmers want to work with other good programmers. So once the quality of programmers at your company starts to drop, you enter a death spiral from which there is no recovery. [2]
via paulgraham.com
[Sent from my iPhone 3GS]
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
There’s a complicated relationship between the two things. Sometimes flexibility may add to power — if I could just make these things green, my eye could pick them out more easily, and I’d get my work done more quickly.
But flexibility detracts from power just as often — or more often. Flexibility is an invitation. It says, “Hey, futz with this. And this. And this. You’re not getting anything done, but at least you kind of have the illusion of doing something.”
via inessential.com