Rockheim -- how not to have an experience

A couple of weeks ago I went to visit "Rockheim" -- a museum of sorts, although I am told that it is more an "experience" than a museum.  In fact it is neither.  Just some mediocre waste of space and opportunity.  A manifestation of what happens when airy ideas take concrete form through the inept and unimaginative.  Before going there I had joked that "is rock really so dead we need to visit a museum to see it?".  After visiting the place I am not sure what to make of it.  It is not a museum.  And it is not an experience.  Not an experience you should spend money on anyway.  If you want an experience I would recommend a combination of wikipedia and going to a concert.  Both offer far more depth both in insight and emotion.

Apparently they had the idea that the "experience" should be interactive.  However, they completely missed the mark.  The interactivity on offer was for the most part various ways to trigger pre-recorded content.  In particularly flakey and annoying ways.

There were in two exhibits in particular that made me hoppingly mad.  One was a collection of various organs, electrical pianos, and synthesizers. Rather than giving the audience a chance to interact with these, they were behind plexiglass.  Like extinct specimens of rare species.  There was no interaction, no way to understand these devices, no way to understand why, for instance the ARP 2600 ended up being such a coveted instrument despite its limitations.  Sure, they are valuable items, but what value do they have if you cannot relate to them?  If you let people play with them, occasionally they will break -- but at least you will have given people something of value.

A brief, superficial video that goes into no useful detail is a poor substitute for, say, a knowledgeable guide who can play the instrument, show how it is used, take questions and perhaps let the audience interact with the instrument directly (though with some supervision for the rarer instruments).

The other exhibit was an old-fashioned mixing desk.  One of those huge studio desks with lots of automation and mixer strips that were packed with functionality.  I spent perhaps 20 minutes studying the various knobs and buttons -- trying to understand how the thing was designed and how it was meant to be operated.  I desperately wanted to try out some things.  To understand how this dinosaur could be brought to life.

I suppose they thought they were clever when they wired the channel faders to control the size of windows displayed on a wall.  The rest of the knobs and buttons did absolutely nothing.  Taking what used to be a fairly sophisticated piece of equipment and turning it into a stupid, primitive, pointless controller of a terribly dull display.  A display, mind you, that served no purpose since people would be more interested in constantly fiddling with the faders so it was completely impossible to actually absorb any of the content.  Not surprisingly.  People want to interact, but the only interaction on offer was insultingly stupid.

The information on offer I would rather consume on my computer.  Without kids constantly screwing with the window size of my browser.  But the mixing desk:  that was the real opportunity to give the audience something of value.  An experience.

Think of what they could have done instead.  They could have wired the desk up to sound sources. For not much money at all they could have wired it up to a computer with a 16 channel sound card and created some interface to allow the audience to play back multitrack recordings through the mixer.  (Or they could have gone even further and fired up that 24 channel (or so) Studer tape machine they had there).  Allowing people to actually learn something.  To learn how music used to be produced, how sounds are layered, how you can manipulate spatial placement, intensity, dynamics, and frequency content of a sound.  Let people understand that there is an art to turning individual performances into a greater whole.  Let people connect with what they can only hear on recordings and develop some intuitive idea of how it is done.

To top it off they had a tacky gift shop full of the sort of garbage nobody needs or wants.

I left frustrated and a bit angry.  As I always do when I see opportunities being wasted so carelessly.

If you want to interact with music I suggest you visit a instrument shop that sells guitars, drums, keyboards etc.  At the least they will let you interact, touch, and explore.  They can tell you about the instruments and the machines and they will often be more than happy to demonstrate and explain.
I suggest you go to a local concert, where you can stand close to the stage and see the band and feel the music physically assaulting your senses.
I suggest you buy a book that gives you more than the powerpoint bullets and some snippets of disconnected information.

Rockheim is possibly the worst waste of time I've been unfortunate enough to spend money on in a long time.

UPDATE: Magne from Rockheim took the trouble of responding to my blog posting.  Unfortunately there was some problem with blogger that prevented him from posting the comment to the blog, so I decided to add it to the bottom of the blog posting instead since his response was well thought out and insightful.  I'm a bit busy right now, so I'll comment on it when I can switch contexts and devote some quality time to it.  (There are a couple of other blog posts in the pipeline that need to be finished first).


Magne Gisvold, web editor of Rockheim writing.

Thank you for a thorough critique of Rockheim. We think that the effort and sincerity deserves a reply from us.

First of all: We do agree with many of your points.

For instance, we agree that the ideal situation would be to have all kinds of instruments available for exploration by our visitors. Also, to make a studio mixer accessible for the general audience, in order to experience real music production is an excellent idea. The same goes for making "real" interactive content that allows the user to freely navigate through content, further immersed in the subject matter.

None of these ideas are foreign to us, of course. All of these have been considered, and been reluctantly binned. Why? Well, the obvious: The resources (money and time) have been strictly limited.

To give an example: In our hiphop-room we have had a classic dj flight available for anyone to use. During the month and a half since we opened, we have got 20-some broken records, and have spent several thousand kroners on styluses.

To think that giving anyone and everyone access to any other kind of instrument is much less expensive per item, is erroneus.

Also, we'd need twice the manpower in the guide departement to supervise and facilitate such an experience for our visitors.

Hence, the solution is obvious (you said it yourself): Having proficient people using instruments in front of museum goers. This is, and has been, on our to do list (yet on the overlapping list of many things we have not yet initiated or implemented; we are currently using every man-hour on being able to cope with the massive flow of people wanting to experience Rockheim; we are a very young organisation, climbing a steady, steep yet exhausting learning slope).

That aside, you're actually missing the target somewhat:

Because our main mission is not that of Teknisk Museum (to show how technology works) - or that of Ringve Museum (to conserve and display musical instruments), but to collect, conserve and convey Norwegian pop and rock MUSIC. (And of course to contextualize said music among other cultural expressions and artefacts of our society.)

Hence your critique is somewhat an error of category, as your assessment of Rockheim should be contrasted to other (public) conservating bodies (museums, archives, libraries), and the critical issue at hand is: Do we conserve and convey the history of pop and rock thoroughly and deeply? (I.e., that you cannot assess Rockheim meaningfully in contrast to, say, a rock concert, a music studio, or a somewhat fuzzy notion of what a "good experience" is.)

Now. We don't want to get entangeled in polemics here. And as stated, we agree with you to a certain point when it comes to envisioning an "ultimate" experience. We welcome your constructive feedback - and look forward to years and years of trying, learning, and trying again (within the typical economical confines of the typical public museum).

Remember: age-wise, we are just teething ;)
- - - - -

mvh Magne G.


Craft vs science: thoughts on computer science education.

In a previous job, a large part of my duties was to interview people who applied for a job with us and then write an assessment of those people.  Among the people I interviewed there was a considerable proportion of people who were fresh out of graduate school.

One of the puzzling things about graduate school is that it doesn't really seem to prepare candidates all that well for a life in the tech industry.  It does more to prepare you for a continued career in academia.  I observed two main problems in newly graduated candidates:

  • Most of them can't program.
  • Most of them struggle to apply knowledge to real problems.
And just to be clear:  the people who made it to on-site interviews were the ones that were left after weeding out 90% of the candidates.

I would say that being interviewed by me was a fairly benign affair:  I wanted people to succeed.  Also, I gave people problems that anyone should be able to come up with a working solution for (to get a passing grade), but you would need to be a bit smarter than average to come up with an optimal solution.  But usually not by much.  Of course,  some problems did not have an obvious solution as such, but were designed to observe the thought process more than the final outcome. (I hope I managed to communicate this in most interviews to reduce the angst of the candidate).

In any case, a surprising number of newly graduated people were shockingly bad at writing code.  And what was even more shocking was the degree to which defenders of common academic goal-setting thought this was acceptable.  In fact, in some academic circles it is almost seen as a bit dirty to "waste" time writing code when you could be publishing papers.

I could go on for hours about academic papers and the limited value they have outside academia.  I've probably consumed more scientific papers than most doctoral students and at one point I even went back to school to take some extra math classes to better understand some of the more challenging papers.  (Math is one of those skills that quickly atrophies if not used and although I have some mathematical intuition, most of the mechanics of mathematics and encyclopedic knowledge is just gone).
Believe me:  I have spent a lot of time reading reams of academic papers to find solutions to hard problems and adapt them to the real world.  So much is just relatively trivial deltas in knowledge dressed up to look important and because of the sheer volume of mediocre to bad papers being published it can be really hard to find that one important needle in a haystack of papers.

But I digress.

I wish universities would recognize that not everyone is heading for a PhD.  Some people who choose a computer science degree are actually going to make stuff.  And it would be beneficial if their education would prepare them for this.  Possibly even allow some candidates to discover that they may have chosen a profession they are not suited for or won't enjoy at an earlier stage -- before they've racked up student loans.

After all, if you want to become a surgeon, they don't wait 10 years before they let you interact with a real human being.  You are not going to be hired as a surgeon and be allowed to actually go at people with scalpel, laser, hack-saw, drills and the like unless you have had some training in this first.  You do not go directly from reading about appendectomies or inter-cranial surgery in books to suddenly being handed a scalpel or a high speed saw and told to "figure it out".  Cutting people is a craft.  There are lots of practical skills you need to learn from practitioners,  there are differing local practices you won't find in literature etc.

Why is it that we accept that teaching aspiring surgeons practical skills is an integral part of their education, but that we accept less from, for instance developers?

There is no shortage of people with a computer science background.  There is, however, a shortage of people who are really good practitioners.  I think it is vital that universities start to take this into account and think harder about producing candidates that are better prepared for the real demands their careers will put on them.  Universities do a fairly good job of giving people a solid theoretical basis.  In general they do not seem to be where you go to learn excellence in actually practicing what is, to a larger degree than they would like to admit, a craft.


Copy protection madness.

A friend of mine recently related a story about how he was unable to make use of software he had paid for because of a screw-up on part of the company that makes and sells this software left him stranded with a piece of software that didn't work.  Outside normal business hours.

Since I am going to link to the self-congratulatory twaddle the company in question use to put a positive spin on their copy protection I might as well say that the company was Propellerheads -- the guys who make Reason.  Don't get me wrong, these people make a great product and they deserve admiration for it.  But their copy protection is misguided, stupid and annoying.

Reading their explanation of how their copy protection works makes me a bit angry.  Because they have so clearly missed the point: fiddly copy protections are cracked with frightening regularity and the only people who are truly affected are the legitimate users.  Pirates don't have to deal with this nonsense.

Being dependent on either having the hardware dongle available at all times or being connected to the Internet (lest the software will shed features) is fiddly, unnecessary and annoying.  No amount of spin changes that fact there is nothing even remotely convenient about this.

And it certainly not outside normal business hours.


Old dogs, new tricks.

With some regularity I bump into people who work for companies that need to evolve and reinvent the way they currently do business -- or at least how parts of their business operates.  Key words are: global reach, open APIs and much, much faster innovation cycles.  For companies that have been operating in mature sectors for a number of years there is usually no deep understanding how they need to respond to the changes in premises and expectations.

Quite the contrary, there is usually a lot of resistance to challenging basic assumptions and established "facts".

The first thing that strikes me about how a lot of well-established companies go about doing "new, exciting and wild stuff" is to apply all their normal, rigid, heavy processes.  Some places there is usually a lightweight process in place -- which still is far more rigid and heavy than what is the case at more, I dread to use the term, agile companies.

This leads to expensive failures.

My advice is: don't expect too much and don't plan too much.  Just start learning by doing.  If you are an old dog, you need to learn the new tricks first.  The things you need to learn are:
  • Fail
  • Fail fast
  • Fail cheaply
  • Get up and have another go
Most Internet successes you see are the result of dozens of failures, false starts and heads being banged against dead ends.  Most mature businesses are used to a better than 10% success rate for projects they do. It took Twitter 10 years and half a dozen false starts to become an overnight success.  And those people were adaptable and entrepreneurial.  Chances are you, or your company, are not.  You will fail a lot.  Get used to it and make the most of it.  Most failures still yield some valuable results.

Once you have learned how to fail properly (or at least become mentally prepared for it) you are ready to start learning.  Work fast, iterate over both ideas and solutions.  Be prepared to change your mind and re-evaluate your assumptions.  Don't do more work than strictly needed (following the You Aren't Gonna Need It principle), but take care to do the things that matter properly.  Quality always matters.  You will never go back and fix things that seemingly work so do it properly the first time around.

Having a plan for how you want to scale also matters a lot.  Actually being able to scale to infinity (and beyond, sorry, mental tic) in the demo version, or closed/limited beta doesn't.  Not really.

However, when you go live you should be able to handle the worst case scenario:  that your stuff actually takes off.  Nothing turns users against a service quicker than sluggish performance and downtime.  (Twitter could get away with it, but you might not.  In particular if your brand has certain expectations associated with it).

Once you do launch, congratulations, you are almost half way!  Those pesky users will not do what you intended them to do.  They will find their own uses for your neat new offering.  This is Part Two of the learning experience.  Now you have to iterate to converge towards what the user actually wants and needs. (Just look at Apple's Ping service.  It more or less fell flat on its nose when it was launched.  Which isn't too strange since it missed the mark by a mile. Unless they manage to iterate some sense into Ping, it will have to die).

If you were too lazy to read the entire post, let me summarize: learn by doing, don't expect quick returns and be prepared to change your mind often.

What I've written about here isn't about any one company in particular.  Incumbent companies running the risk of being de-throned and fading into irrelevance is an area of great interest to me and about 18 months ago I specificly set out to seek out challenges of this type.

This is what happens when people tell me that something "can't be done" :-).


Favorite Hammer

Not too long ago I had a discussion with someone about the choice of implementation language for a project.  He had chosen to implement the project in C++.  According to him because this was the "best possible way" to go about the job of writing something that could be compiled and run on any platform. 

And in principle he wasn't really all that wrong:  there are C++ compilers for nearly every imaginable platform out there. 

The problem is that it isn't really painless to write C++ in a portable manner, an even more importantly:  to have it build in a reasonably painless manner everywhere.  In particular not when you start depending on certain libraries and you start with the assumption that there will be an entire (up to date) GNU toolchain available.

Which is only the case on fairly up to date open source flavors of UNIX, but if you want this on OSX you have to fiddle around for a couple of hours.  And if you are on Windows...well, let's not go there. (Yes, it would have been easier to just order everyone on the project to drop Windows since it is a pain in the ass to have people running Windows on any development project).

In principle the result was portable.  In reality it wasn't.  Not unless you are willing to spend a lot of time fiddling about.

I couldn't be arsed to start a big fight over it.  Mostly because I don't feel like spending days lecturing someone who should know better and then ending up looking like a bad guy for doing so.  I need that like a bull needs tits.

*sigh* ... updating the GNU toolchain is really taking forever.  I should be in bed.


Software Architects

The question of what defines a good software architect came up in a recent conversation.  Well, several recent conversations, actually.

In the software world the title "{software,system} architect" is perhaps one of the more suspect titles there is.  It is one of those vague titles that doesn't really nail down what this person is supposed to be or do in a meaningful way.

Sure, if you work for a large consulting company there will no doubt be reams of paperwork defining the role of "architect" within some huge framework that your company markets as The Really Clever Way We Do Things[tm] -- but let's be honest: most reasonable people would rather stab themselves in the leg with a pencil than spend even two minutes reading what is mostly going to be the verbose and inane drivel of inarticulate morons.

I have yet to come up with a good answer to what positively identifies good candidates.   But there is at least one heuristic that can be applied to divide candidates into those more and less likely to be good architects.

My take, and it is important to note that I am expressing a subjective view here, is that at the very least a software architect needs to be a competent programmer.

If you can't program or you are a below average programmer, then the chances of you being great at thinking about architecture are going to be really slim.  It is like thinking that you have a future in theoretical physics without understanding one iota of mathematics.  It just isn't going to happen for you because you won't have adequate command of the fundamental language used to express and understand physics.

The only software architects I know whom I have found worth paying attention to are above average programmers as well as being good at thinking of architecture and system design.  Not only that, but they spend a significant amount of time maintaining these skills by participating in software development and keeping abreast of what goes on in their field.

The main danger of becoming too far removed from where the rubber meets the road is that it gradually changes your perception.  You start to think about complexity and sources of complexity in a more abstracted manner.  You tend to forget how hard the details can be,  which details are important and which are not.  You gradually lose language and intuition.  You become prone to base decisions on politics and vague, or unfounded, assumptions rather than deep understanding.  And when assumptions suddenly change you may not understand the implications in time, or at all.

It should also be noted that just because someone is a brilliant programmer does not automatically mean they will make great architects.  This is roughly equivalent to thinking that a good practitioner in some field will always make a good leader, or even capable of even vaguely normative works in that field.
Some do, most don't.

In fact, the software engineering industry is full of quacks and charlatans who have had some success as programmers, but who then shamelessly go on to peddle pseudoscience and feelgood easy fixes.  (I'll leave it up to the reader as an exercise to identify the more egregious offenders).

My main point is that being an architect takes deep, detailed and up to date working knowledge of technology to the point where you wouldn't be completely lost if you had to get your hands dirty.  If you are too far removed from the action you most likely won't be any good.