HMS Bounty RIP

It's not been easy to find a lot of hard news about the HMS Bounty incident.

Early on, there was some good coverage in the Washington Post:

• HMS Bounty: A tall ship’s final hours in hurricane-ravaged seas
• Search continues for HMS Bounty’s captain after an encounter wth Hurricane Sandy

In the last 36 hours, though, there hasn't been an awful lot to go on. There's been a bit of information in the Christian Science Monitor:

• HMS Bounty: the inside story of its final days (+video)
• HMS Bounty: Search for missing captain continues (+video)

Apparently, from what I've read, the ocean temperature in the area, dead smack in the middle of the Gulf Stream, is an unbelievably warm 77 degrees Fahrenheit, so the hope is that Captain Walbridge may still somehow be alive out there.

Godspeed and best luck to the SAR teams and their personnel; they did wonderful work on Monday and may they have another success yet to come.

Meanwhile, the final hours of the Bounty remain confusing. As the Monitor notes, lots of questions are unanswered:

The ship’s course out of Connecticut took it due east to try to avoid the oncoming hurricane Sandy. Early on Sunday, the crew felt it had skirted the danger: A Facebook post showed the ship’s position on a map well to the east of the storm’s fiercest winds.

They were mistaken. The ship was close to the tail end of the hurricane as it whipped up the Atlantic coast.

Details about the ship’s final hours remain sketchy. Apparently at least one generator failed, and the Bounty began taking on more water than it could safely handle.

Hundreds of miles from shore, in hurricane conditions, what navigational tools and techniques apply? Were they receiving GPS signals? Were they simply dead reckoning? What caused them to be off by dozens or hundreds of miles?

Reading between the lines, it sounds like they made a navigational error, which placed them in peril, and then suffered a power plant fault, which probably left them simultaneously unable to flee the storm, unable to orient themselves tactically to waves and wind, and unable to operate the pumps which are crucial in removing water faster than it can arrive.

I'm interested in reading more about the story; if you spot good information about what happened on the Bounty during those final 48 hours, do drop me a line and let me know...

Programmers and Paparazzi

You may not have heard of a little company named Cloudera, but that may change soon. Cloudera is one of the hottest startups in one of the hottest parts of the computer industry, the so-called "Big Data" space.

The management team at Cloudera at times looks like one of those 'dream team' assemblages that people put together in their fantasy football leagues; they've recruited top talent from places like Oracle, Yahoo, VMWare, Facebook, etc.

For a company like Cloudera, desparate to attract attention in a rapidly-growing, hotly-contested market, having big names is sure to help, and it's no surprise that many of Cloudera's competitors are assembling similar power-house talent pools, backed by vast sums of investment funds.

But it was somewhat of a surprise to me to see a new page turned in these talent wars over the last few years: companies now trumpet their personnel acquisitions like professional sports franchises advertise their latest trades, and so it's interesting to see Cloudera's Press Center touting this breathless love-fest article about their latest hire: World's Most Wired Software Engineer.

There's some sort of transition going on here, and I'm not quite sure what it means when publications like Wired are running articles that contain things like:

For Charles Zedlewski — Cloudera’s vice president of products — Impala shows off not only Marcel Kornacker the software engineer, but Marcel Kornacker the man. When Kornacker builds software, he builds it with an eye for the tiniest of details — and he’s intent to take it as far as he can. It’s the same way in his kitchen, on the other side of San Francisco Bay. Kornacker’s Epicurean exploits extend well beyond bread baking. “If you walked into his kitchen, you would think you walked into the set of Top Chef,” says Zedlewski.

Well, I don't watch Top Chef very much, either, so maybe I'm missing the whole point.

This whole topic is much in the light right now due to a long and fascinating essay by John Allspaw: On Being A Senior Engineer. Allspaw's well-thought-out, well-sourced, and well-presented essay has a lot to recommend it, even if I find myself agreeing with only about half of it.

But what I find most striking about Allspaw's essay, and even more so about the things that swirl around it, like the Wired programmer celebrity series, is the absence of humility.

Consider, for example, this follow-on from Adrian Cockcroft: What's a Distinguished Engineer?, advising people that the things that matter most are:

"how many of these people know who you are?". ... "how many DE and Fellows are hanging around your cube on a regular basis waiting to talk to you?"... "Do the top conferences invite you to speak?" ... "How many of the other invited speakers and conference organizers do you know?" and "how many know you?"

Well, pardon me, but all this name-dropping and publicity-grabbing is, to put it bluntly, a load of manure.

In my 30+ years in the software industry, I've known hundreds of superb, stellar engineers: people who taught me how to approach problems, how to encourage and take advantage of feedback, how to build software that lasts for decades.

And I've known my share of attention-hungry, limelight-seeking engineers: people who thrive on taking credit and being known.

And I can tell you, from long experience, that the intersection of these two groups is empty.

So please, young engineer, consider carefully the advice you're receiving from the Paparazzi; follow not the course of celebrity; strive instead for the immense pleasure and satisfaction that you will find in building software so solid, so clear, so reliable, and so robust that it lasts for years and forms the foundation of systems that make the world as we know it possible.

24 hours with the "17"

Oracle Team USA have posted a stunning 10 minute short feature about the capsize and recovery of their AC 72 "17".

The video includes the only footage I've seen of the actual collapse (wow, it happens so fast!), and then covers the recovery of the crew, the stabilization of the boat, and its eventual recovery back to dock.

We went out in the helicopter at daybreak, to see what else we could recover. Pieces were strewn everywhere, too small and moving too fast to note their coordinates. There were pieces inside the bay, under the bridge, and we saw the last piece more than six miles outside of the bridge.

Wonderful video, and it took guts for them to put it online, so big props to the team and the management.

ORACLE TEAM USA "17" Capsize - The Whole Story.

The slow maturation of C++

As the C++ programming language prepares to begin its fourth decade (Stroustrup apparently first called it "C++" in 1983), it continues to slowly stabilize.

For one thing, compilers are starting to support significant subsets of the recently standardized "C++ 11" version of the language, as these notes from David Simmons describe. Another good source of such information is this page from Scott Meyers: Summary of C++11 Feature Availability in gcc and MSVC.

Of course, it's more than just the language and its compilers; you have to have a complete "ecosystem" in order to have a complete programming language. Over at the Google Testing Blog, Zhanyong Wan describes the various reasons why Google decided to build their own C++ unit testing framework: Why Are There So Many C++ Testing Frameworks?

You might wonder, when a language like Java was able to reach this level of maturity in half the time, why is C++ still struggling with these sorts of issues after more than 30 years of development? As the Google team point out, the comparison is somewhat unfair, since Java was in some ways created as a response to exactly this question:

Unlike Java, which has the famous slogan "Write once, run anywhere," C++ code is being written in a much more diverse environment. Due to the complexity of the language and the need to do low-level tasks, compatibility between different C++ compilers and even different versions of the same compiler is poor. There is a C++ standard, but it's not well supported by compiler vendors. For many tasks you have to rely on unportable extensions or platform-specific functionality. This makes it hard to write a reasonably complex system that can be built using many different compilers and works on many platforms.

And as the Google team point out, it's fundamentally much easier to write a testing framework for Java than for C++, for a variety of reasons, including:

Another reason is that some limitations of C++ make it impossible to implement certain features really well, and different people chose different ways to workaround the limitations. One notable example is that C++ is a statically-typed language and doesn't support reflection. Most Java testing frameworks use reflection to automatically discover tests you've written such that you don't have to register them one-by-one. This is a good thing as manually registering tests is tedious and you can easily write a test and forget to register it. Since C++ has no reflection, we have to do it differently.

I regularly write in both Java and C++. It is vastly easier to write in Java, but with care I can be quite productive in C++. Tools like testing harnesses and high quality compilers are a big part of whatever language ecosystem you're part of, so it's good to see that the C++ versions continue to move along, however slowly.

I mean, after all, it could be worse: apparently, the second most popular programming language in Japan is COBOL!!

Kinda quiet recently...

I haven't been blogging very much recently.

Why, you wonder?

• Well, the weather has just been beautiful since that storm blew through last weekend.
• And, the Giants are in the World Series!
• And I've been whiling away a few too many hours watching and playing games over at RedHotPawn
• And when it's not chess, I've been absorbed by XCOM Enemy Unknown. Unsure if it's the game for you? Try this fun review over at Rock Paper Shotgun, couched as the diary of a player:
  • XCOM: Diary Of A Wimpy Squad #1 – Meet The Team
  • XCOM: Diary Of A Wimpy Squad #2 – First Blood
  • XCOM: Diary of a Wimpy Squad #3 – Coinky-Dink
  • XCOM: Diary Of A Wimpy Squad #4: The Grilling
  • XCOM: Diary Of Wimpy Squad #5 – Bucket List
  • XCOM: Diary Of A Wimpy Squad #6 – Deacon Gray
• And when I'm not playing games, we've been mesmerized by Justified, the great new series on FX (written and produced by Elmore Leonard) about a modern-day U.S. Marshall with 19th century sensibilities
• And when I can barely keep my eyes open, I've been glued to Noah Gordon's The Physician, a story set a thousand years ago, with a passion that's fresh and vivid.

A random collection of random stuff

Wandering the Internet, reading all sorts of things...

• A delightful examination of last week's Rotterdam art theft from the perspective of art history: The Art of the Art Heist

  Hilton Kramer called de Haan's “Self-Portrait” — the painting that was recently stolen — "one of his most beautifully painted pictures," and complimented de Haan's "remarkably successful attempts to paint in a Gauguinesque style." The thieves of Rotterdam seem to agree. Yet the look on the face of Meyer de Haan in his self-portrait is more than just Gauguinesque. De Haan is just barely meeting our gaze. He is troubled and self-assured at the same time. Or you could say that he is both absent and present. He is just about to look away, to have another thought. Behind him are painted splotches of red and yellow, a kind of dreamscape. It is so very Symbolist.

• Wired Magazine brings us up to date on the life and times of the incredibly talented Peter Molyneux, the creator of Populous, perhaps my favorite computer game ever: How a Videogame God Inspired a Twitter Doppelgänger — and Resurrected His Career. Perhaps the most interesting part of the story involves how Molyneux reacted when one of his more passionate fans created a fake alter-identity on Twitter:

  Journalists like Gamasutra’s Leigh Alexander and GiantBomb’s Alex Navarro began retweeting some of his posts. Sites like Kotaku and GameSetWatch also ran coverage of the mysterious online figure, who maintained his anonymity in the press. The exposure helped @PeterMolydeux hit 23,000 followers by the end of 2011. And gamer cognoscenti weren’t reading it just as a cruel joke at Molyneux’s expense; @PeterMolydeux was becoming an outlet for the widespread dissatisfaction within the industry, a voice for the thousands of developers who had grown tired of the limitations of mainstream gaming. If anything, the Twitter feed gave some followers more respect for Molyneux.

• Surely by now everyone has read the New York Post article about the tremendous power of a simple set of master keys: Key set available for $150 on eBay provides an all-access pass to NYC, shrieking headline and all. For a more nuanced take, try Bruce Schneier: Master Keys

  The current bit of sensationalism aside, this is fundamentally a hard problem. Master keys are only useful if they're widely applicable -- and if they're widely applicable, they need to be distributed widely. This means that 1) they can't be kept secret, and 2) they're very expensive to update.

  Or, for a view just slightly farther into the future, consider Geoff Manaugh's essay: Keys to the City

  This cinematographic duo would thus pose there looking at each other, under the control of hackers huddling in a van somewhere wearing Stadium Pals, long enough that they could 3D-map the keys from the ensuing image feed and then have accurate copies produced. Thus would your house be robbed by robot.

• Going back to Wired Magazin, do not miss this epic article about reliability engineering, and the emerging discipline of failure analysis: Why Things Fail: From Tires to Helicopter Blades, Everything Breaks Eventually.

  Product failure is deceptively difficult to understand. It depends not just on how customers use a product but on the intrinsic properties of each part—what it’s made of and how those materials respond to wildly varying conditions. Estimating a product’s lifespan is an art that even the most sophisticated manufacturers still struggle with. And it’s getting harder. In our Moore’s law-driven age, we expect devices to continuously be getting smaller, lighter, more powerful, and more efficient. This thinking has seeped into our expectations about lots of product categories: Cars must get better gas mileage. Bicycles must get lighter. Washing machines need to get clothes cleaner with less water. Almost every industry is expected to make major advances every year. To do this they are constantly reaching for new materials and design techniques. All this is great for innovation, but it’s terrible for reliability.

  This article is so good, it's hard not to quote every bit of it. If you think you ever might want to be an engineer, or if you are an engineer and you want to learn how to be a great engineer, stop what you are doing and read this article, and then read it again, and again.

  Part of the revolution in reliability engineering comes from better tools, such as this tool from Vextec:

  The result is essentially an image of the component’s microstructure. Vextec’s algorithms then assess this microstructure: What are the grain sizes and orientations? How often do voids appear and in what shape? How frequently do particles of dust or other contaminants appear? The algorithms create a set of rules for the material—a statistical model of every aspect of the microstructure. The rules are used to create multiple virtual versions of the material whose microstructures vary within the rough range that the client could expect to see in manufacturing.

  But it's interesting that another part of the field comes from a side-effect of some of the government regulations put into effect after Enron famously collapsed:

  In the wake of the scandal that took down the energy juggernaut, the Financial Accounting Standards Board made changes to the Generally Accepted Accounting Principals—the rules that, among other things, govern how companies write financial statements. As of November 2002, companies were required to provide a detailed reckoning of their guarantees, including their warranty reserves and payments, in quarterly and yearly filings. The result was that, for the first time in history, someone could look at, and compare, how US public companies handle claims—how much they pay out, how much they hold aside for future payments.

  It's all there in the article: expect failure, design for failure, plan for failure, test to expose failure, test to evaluate the handling of failure, test your tests. Yes, this article is all about the building of cars and trucks and door hinges, but it really about what makes things reliable.

  My, perhaps it's time for me to go read the book again? I'm feeling like it's been too long...

• Out of the ashes of Newsweek Magazine's collapse, one possible phoenix is the return from oblivion of Dan Lyons.

  We have a platform where we can do some of the things we did on Fake Steve, like create a sense of community and add a touch of irreverence to the world of tech. Now more than ever the Valley is in need of a bracing, no-bullshit shot of truth, and we are the ones to deliver it.

  Read more about Lyons's hope for the e-zine once known as ReadWriteWeb in his first editorial on the new site

  We want to turn our writers loose and let them write from the heart, in ways that are more personal, passionate, provocative and fun than ever before. We want ReadWrite to be a lively place filled with wit and energy, a place where you find great stories told in a convincing, engaging way, with brains and a point of view.

  I've always enjoyed Lyons's work, and I hope he does somehow find a way to at least partly return to the zing and verve he brought to Fake Steve.

• Had enough of all of this? Practice arming your cubicle for the coming armageddon

IPv6 Summit in Slovenia

Ivan Pepelnak has a nice post summarizing his take on the highlights of a recent IPv6 conference: The Best of Last Week’s IPv6 Summit

Big thanks to the organizers of the conference, for making their videos available for the rest of us!