Hardware.

Recently a friend of mine asked me what I thought of a new server product that her company is launching.  The friend in question is Yvonne Fosser  the company is Hewlett Packard and the product is HP Moonshot.

What struck me is that although I have at times been a huge consumer of computing power I am spectacularly unqualified to answer that question.  Perhaps precisely because I have had access to the largest non-classified computing resources in the world.  When you deal with massive computing systems, the nature of your interaction with them must necessarily be somewhat abstract.

The last time I fiddled with production hardware directly must have been some time around 1995-1996 or so. Back then I worked part-time for the local university to support myself while starting a company with a few friends.   That was the last time I took a machine out of its box and put it into a rack.

After that hardware has largely been about numbers for me.

Quite early on in the game while I was at FAST, we moved our servers to the US.  So from mid 1999 on I have rarely been on the same continent as the production resources I've been using.  Back then I worked on software that ran on tens of machines.  A few years later, at Yahoo,  I worked on software that ran on thousands of machines.  And finally, at Google,  on "an undisclosed number of machines" (I said non-classified -- not non-secret ;-)).

Nowadays, at Comoyo, we run on a very modest (well, relatively speaking) number of EC2 instances from Amazon Web Services, but there are a few things that have not changed:

• I never physically see the machines.  They are just numbers to me;  in order of importance: RAM, CPU, bandwidth and storage.
• I am not on the same continent as the machines.
• I can provision whatever I need within minutes and ditch it when it is no longer needed
• The machines are extremely basic (no RAID, no expensive complicating bullshit)

Actually, the precursor of Comoyo did purchase a few servers about 3 years ago.  It was an eye-opening experience.  I was only peripherally involved in setting them up, but we burned an amazing amount of man-hours on dicking around with those servers.  I think all of us had forgotten how much work it is to own physical hardware.

HP Moonshot looks like the right thing to do in many ways: packing lots of computing power into a small space and caring about things like energy-efficiency etc.  But I actually think the bean-counters will be more qualified to say whether the machine is good or not.

That being said, I certainly would not mind having one for use at home or at work.  I know precisely what I'd use it for (an OpenStack-based private cloud for experimenting).

Then vs Now

The picture on the right has been floating around the Intertubes lately and it seems to make the point that we have not improved space flight.

Huh?

True enough, the space shuttle has been retired.  But for good reason: it is not only obsolete -- it wasn't a terribly good idea to begin with.   Don't get me wrong.  The shuttles did get the job done, but for the amount of money NASA spent on keeping them operational for 135 missions, they could probably have developed a much, much, much more cost effective alternative.

What belongs on the lower right square is probably the Dragon spacecraft (however, there are other initiatives that are worthy of mention as well).  Compared to the space shuttle it is every bit as big a leap as brick phones to iPhones.  It is simpler, cheaper, and it is made from materials that are ridiculously efficient.

However the graphic is right in one respect: we have stopped caring.  And that is a sad commentary on our society.  When Dragon flew last year it was the biggest event in space technology since Armstrong landed on the moon -- yet the media was barely interested.

Millions of people watched Felix Baumgartner jump from 39.000 meters. A fairly unimportant advertising and penis-stroking exercise repeating something that had been done 50 years earlier with slightly fancier gear and a bunch of webcams.

The white square mostly represents our lack of interest in things that take more than 10 seconds to explain.

Because we sure as shit have spacecraft that makes the space shuttle look like something ... out of the cold war era.

What if C# and .NET had targeted all platforms?

Imagine if Microsoft had not been so dead set on using C# to push their operating system, but instead had spent significant resources on making C# available on Linux in a manner that wasn't upsetting to the open source community.

Rather than the "fan fiction"-variant of the platform that is Mono (which is forever condemned to be the poor-man's alternative), there could have been a viable .NET platform on Linux today -- and other Unixen.

If Microsoft hadn't seen C# and .NET as a tool for securing an audience for their OS they could have owned software development.  People like to malign .NET but I don't think they don't do this because there is anything inherently bad about C# and .NET -- they do it because .NET implies Windows and Windows isn't exactly the favorite OS of open source developers.  Or closed source developers for that matter.

It is easy to speculate that Java would have atrophied and died if Microsoft had targeted Unixen. It is certainly hard to imagine there'd be meaningful collaboration between Sun and Microsoft (thanks to stupid IPR laws, companies are encouraged to waste their time bickering over meaningless trivialities).

Perhaps both would have matured at an accelerated rate? Perhaps not.

In any case, Microsoft committed a strategic blunder by not ensuring they own the developers.  I think might have been a mistake that is best measured in hundreds of billions of dollars.

Gorging on Java frameworks and dependencies

v. gorged, gorg·ing, gorg·es

v.tr.

1. To stuff with food; glut: gorged themselves with candy.

2. To devour greedily.

v.intr.

To eat gluttonously.

I'll admit it.  I'm an odd sort of Java programmer.  I've been programming Java since it first came out and I wasn't terribly enthusiastic about it for many years.  In part because there were features lacking, but also because Java needed to settle and mature and all of us needed to learn how to deal with object orientation. OO in the 90s sucked.  Sadly some of that suckage is still with us.

When I finally started using Java as my primary language it was because it had finally grown some features I had been missing.  The 1.4 release was, to me,  the first really useful release (although it can be argued that much of what made 1.4 useful didn't really work until 1.5 or so).

(Update: some people asked "what features".  Mainly asynchronous socket interfaces in the shape of NIO -- though truth be told, the NIO implementation in 1.4 was so buggy it almost didn't work and I remember spending a lot of time figuring out workarounds so that our production code would hum along happily.  NIO also had some subtle design quirks one has to be aware of and design around).

For the first 5-6 years of using Java as my primary language I managed to write code that had, by today's standards, exceptionally few third party dependencies.  For years I used JUnit, Jetty and a few dependencies that I think Jetty demanded I include.

I also quickly figured out that in order to be able to deploy applications without turning life into a miserable easter-egg hunt for everyone else I had to package my applications into single JAR apps.  It amazes me that people still deploy Java web applications into stand-alone containers rather than embedding everything and saving users from whole classes of headaches.

I'm still careful about adding dependencies on third party frameworks because it isn't nice to other developers.  Whenever you add a non-trivial framework to your codebase, you are increasing the amount of knowledge you demand from people who need to understand your code.  It is no longer enough to just know Java -- you have to know about the framework in question as well.

And most Java programmers don't even know Java all that well.

For badly designed frameworks the amount of confusion and frustration you get quickly overshadows any gain -- real or imaginary.  Lots and lots of frameworks are badly designed in that they create more work and more frustration.  This ranges from libraries that represent just really bad design (like OpenSAML) to entire ideas that are just bad (OR mapping frameworks -- seriously, do you really think trading a bit of typing for a lifetime of wondering what the heck is actually taking place under the hood is really worth it?)

Also, even though Maven will happily download half the Internet for you in order to resolve dependencies, things tend to break more easily the more third party code you depend on.

I can't remember who said it, but I think one of my colleagues at Comoyo said something along the lines of: "we obsess over our own code with code reviews and such, but we happily depend on any piece of shit some crazy monkey on the net has cobbled together in his spare time".

Think about that.  Because it is true.

Right now your Java application probably contains a dozen version conflicts that you have not noticed.  The more common variety being the same library occurring in your transitive dependency graph more than once and in different versions.  It is sheer dumb luck that your application works at all.  If you don't know what I am talking about I suggest you have a close look at your transitive dependency graph.

Here are a few rules I try to live by:

• Be nice to your fellow programmer.  Do not assume that they are interested in spending time replicating your development and runtime environment.  If you assume more than the JRE/JDK and perhaps Maven or Ant you are being a bit of a dick.  It should be possible to check out, build and run your project without reading a manual and going on an easter egg hunt.
• Try not to add frameworks that fundamentally changes the programming model. IOC, AOP and such are good fodder for conferences and provide consultants with a great market for wrangling out-of-control code.  But it isn't nice to take over a project that is infested with all manner of confusing shit that will go out of fashion at some point anyway.
• Try not to add dependencies that come with huge dependency graphs themselves if you can help it.  Much of that code will have been written by "crazy monkeys".
• Look in the Java standard library first.
• Have a lower threshold for dropping dependencies than for adding them.

Clever kitchen implements

Over the years I have gotten various "cleverly designed" kitchen implements.  I have a clever pizza cutter, a clever tin opener (that costs more than my first motorized vehicle(*)), a clever tea infusion ... thing.  The list goes on.  All of them gifts from well-meaning individuals.   None of which appear to cut pizza, open tins or make tea.

Of course: none of these implements work.

The pizza cutter is an awkward design that makes it hard to not hurt yourself -- let alone cut pizza.

Nobody knows how the tin opener works.  Probably by some form of black magic, because making it work invariably involves generous amounts of loud blaspheming and some measure of gesticulating angrily.

Finally, there is the tea infusion ... thing. While looking somewhat promising, the opening to facilitate contact between tea and water is so narrow your tea is in no danger of becoming even the least bit damp.  By the time your water has taken on observable coloration, the water is cold and most of it has evaporated.

I have drawers more of clever kitchen implements.

If I may I'd like to make two suggestions:

1. Don't buy me clever kitchen implements.   Please.  They'll just end up at the back of a drawer and jam when I try to close the drawer.  Buy me battle-hardened stuff that actually works.
2. If you are an industrial designer and you feel like designing something for the kitchen: please don't.  It is extremely unlikely that you'll manage to design something that is significantly more useful than a sharpened stick.

Next week we will discuss the Audi 1.8 litre inline-4 petrol engine versus the 2 litre, inline-4 Alfa Romeo Nord engine and ask the question why Audi allowed a village idiot to design such an unsightly lump of misery and why this miserable ode to impotence was ever fitted to a car.  Stay tuned.

(*) Okay, so my first motorized vehicle only cost NOK 25.  It was a 50cc Vespa scooter that was stuck in first gear and I could pedal my bicycle faster than this thing would move at max rpm.  I bought this off the village idiot.

I am unsure if he went on to a career in the german automotive industry.