Symphonious

I’ve had this article by Seth Gottlieb open for a while now but quite frankly don’t have much I could add except to say go read it. The idea that content is more than just data because of how real people perceive and work with it leads to a huge difference in how you design user interfaces for content management systems. A content management system should be more than just a web interface to some great big database, it shouldn’t make users think the way the database is laid out, it should let them focus on the content and the true messages that it conveys.

In other words, content management systems shouldn’t just manage content, they should enable people to create and evolve content.

For the first few years that I worked at Ephox there was a regularly recurring problem: how to let our clients know exactly what’s changed between versions. We were good at showing off the new features but never had an accurate list of which bugs were fixed and every so often a client would ask for that. It seems simple enough - just keep a changelog - but there were some challenges.

• Our support system is separate to our bug tracking system so fixes can come from either source (the support cases are always fixed immediately so they don’t need tracking). You therefore can’t just pull a report from the bug tracking system to see what’s been fixed.
• If you had to manually update a change log developers kept forgetting to do it and it would be inaccurate.
• Going back through the subversion commits at the end of the release worked but took way too long and was the kind of job you wouldn’t wish on your worst enemy.

Today though, we’ve got a very accurate changelog that’s published out for every release and kept up to date enough that it’s published along with every nightly build. So what changed?

We put a checklist on the wall to make sure that a story was really “done done” before developers could move it over to the completed side of the planning board. That checklist included updating the changelog. From there it became habit and if someone forgets to update the changelog it’s generally noticed by someone else pretty quickly.

What makes checklists so powerful is that they scale so well with the user. If you’re a beginner the checklist provides a set of steps you need to go through to get the job done. If you generally know what you’re doing but it’s still not routine, the checklist provides a handy reminder. If you’re an expert it only takes a moment to flick through the checklist and ensure that everything was done, and it’s still there to remind you if you forget something or are interrupted part way through.

It’s amazing how many lives checklists can save. Dr Peter Pronovost set up a checklist for basic hygiene practices at Johns Hopkins Hospital and it “slashed Michigan's central intravenous line infection rate by 66% and quarterly infection rate to zero”. Similarly, every time you fly you put your life in the hands of a great big checklist that the pilots, ground crew, maintenance teams, flight attendants and everyone else involved go through to make sure that the plane is ready to fly, that the passengers are safely on board and have been screened correctly for security etc.

So, next time you need to get your team into a good habit, find out what process that habit should be part of and create a checklist that includes it. Not only will it get people into a good habit, it will provide an essential training guide for your next new employee.

Around the time of the iPhone’s initial release, I wrote:

It's this popularity of Java in the mobile phone world that makes the lack of Java on the iPhone seem so odd to me. I can understand Apple wanting to have complete control over the iPhone interface, and I'll concede that most of the existing games for mobile phones probably wouldn't translate very well to the keypadless iPhone, but it will be interesting to see if Apple can satisfy the great desire for cool little mobile games that today's teenagers, a key market segment for the iPhone, without leveraging the existing knowledge mobile games developers have in Java.

Turns out I was completely wrong. Teenagers don’t give a damn about those gimmicky little games on their mobile phones, they just use them because they’re there. The iPhone’s coolness factor and the built in iPod is all that matters. Even wandering around Australia (where iPhone’s aren’t yet available) with my iPhone, lots of people asked about browsing the web, the iPod etc but not a single person asked about games (and yes, I do know quite a few teenagers who were doing the asking but still nothing about games).

There’s two other aspects of that post that are quite interesting in hindsight:

If the iPhone takes off it won't be a problem, similar to how there are a huge range of iPod specific accessories, there will be - if and when Apple make it possible - a huge range of iPhone specific games and add-ons.

This one is panning out exactly as expected. People will make a lot of money selling games for iPhones - not because they’re essential things to have, but just because they’re there. It should follow roughly the same pattern as the rest of the market for mobile phone stuff where people make a killing selling high volumes of little stuff. That said, the iPhone application store should change the market place a lot - suddenly it will be easy to find the good stuff. It will avoid the scams where they advertise one game for $1 but it really signs you up to a subscription that adds up to $50/month.

Turns out I was also dead wrong about ring tones:

The other part that may be interesting is what happens to the ring tone market as more and more phones use standard MP3s for the ring tone and make it easy to load them onto the phone. The iPhone should nail this and Nokia and Sony-Ericsson are pushing their MP3 player capabilities. Nokia's even going so far as to note how easy it is to get music onto the phone in their Australian marketing.

Turns out the iPhone has the worst ring tone capabilities of any phone I’ve used in the past 2-3 years mostly because it doesn’t allow you to use any old MP3 you happen to have (and because the volume is way too quiet). The saving grace is that the iPhone happens to have the best default ring tones of any phone I’ve used - but still way too quiet. I’d be quite interested to find out how many ring tone sales Apple is doing through the iTunes Music Store given that it also avoids the subscription scam that most ring tones are sold through.

Doug’s discovered a way to improve the effectiveness of simian to avoid adding more duplication to a code base:

The solution is very simple. The simian-report is a an xml file, so I wrote a SAX2 DefaultHandler that was able to parse the number of duplications at the different threshold levels. Putting this into a trivial ant task then gave us a task to help make things no worse even at levels below what the simian-check was doing! Within the first week, the new legacy-check was breaking the build (where the simian-check would never have) and focusing the teams attention on how to make things better.

The solution is simple and really cool. I have no doubt that it will have a big impact on the amount of duplication and the overall quality of our code. The trouble is, Simian’s normal reporting is really, really lousy and Doug’s extra check highlights just how useless Simian is at telling you where the duplication is instead of just detecting that there is duplication.

I discovered this new check when the build broke after a simple commit I made that fixed an annoying bug and removed some duplication. Unfortunately, it happened to change the distribution of duplication so that it triggered a simian-legacy failure. I can, after the use of a few choice words, handle failures like that because it shows I could have and probably should have done more to improve the code around the change I made. Someone’s got to go in a clean things up - it might as well be me.

That’s when I encountered Simian’s report. It’s one great big long HTML page listing pretty much every bit of duplication it found broken down into sections of numbers of lines duplicated and it has a pretty useless index at the top. Over VPN it took 15 minutes to download and render. It hung Safari and FireFox for about 5 minutes trying to render it locally. Once it loads you have to sort through the thousands of duplication matches it’s found (matching as little as 2 lines duplicated and with quite liberal settings on what constitutes a match - again, a good thing) to try and find the one new duplication that caused the build failure.

Eventually I discovered the easiest way was divide and conquer. Simian can run even if the code doesn’t compile, so I rolled back each file individually until Simian passed again. Then I patched my changes back in, searched the report for that file name and eliminated as much of the duplication involving that file as I could and reran Simian.

I’m still in two minds as to whether or not the new check is worth the pain it causes. I really like the idea of it, I just really wish there was an Eclipse plugin for Simian that highlighted duplication right there in the code, or at least a HTML report that showed the actual code marked up with duplication. Then again, if you just have to guess at what duplication to remove the code base will get better faster…

There are a lot of articles around the place giving generally good advice on how to be a better blogger and get noticed. Alastair Rankine highlights one of the key problems with slavishly following this advice - you become boring:

I was initially attracted to Atwood’s blog for its relatively simple premise and smart delivery. With startling regularity over an extended time he managed to deliver bite-sized morsels relating to the stated domain of programming and human factors. He writes well and generally illustrates his point in a clear and easy to digest style. It’s quite engaging.

…

It seems quite apparent that Jeff Atwood has stepped outside his expertise recently, and that this is something he did comparatively rarely in the past. I haven’t gone groveling through his past posts, but from my recollection I’m pretty sure his hit rate used to be better.

What I think has gone wrong is that Jeff, like most bloggers who go pro, is trying to keep to a regular posting schedule even when he’s too busy to do it well or has nothing good to post about. Regular posting scheduled is a universal recommendation on how to blog lists and it’s got a lot of merit. If you blog more often, you’ll get better at it. The more content on your site the more likely searches will lead people to your site. The more you comment in response to other people’s sites the more likely they’ll notice you and respond, including linking back to you.

The problem is that life and inspiration don’t work on regular schedules, they fluctuate. If you quit your day job just to blog you can probably keep life under control enough to post every day but inspiration still isn’t guaranteed. If you’re trying to start a new company or maintain a day job, your life probably fluctuates so that some weeks or even months you just don’t have time to sit down and write a good blog post. Similarly with inspiration, sometimes you’re doing something so interesting great blog topics just keep popping up and sometimes you’re doing stuff that’s fairly mundane and you don’t have anything too interesting to contribute to the conversations going on in the blogosphere. That’s ok, just don’t post anything for a while or simply point to the interesting stuff that’s going on without comment.

It’s a fairly common process which probably should be named after Robert Scoble since he seems to go through the process over and over again. For most people it’s a one way process where they get stuck being boring, but Robert seems to have turned it into a cycle:

1. Blog based on what you know and are passionate about
2. Become popular
3. Feel an obligation to your audience to blog a certain way or blog regularly. Sometimes this is trying to please everyone, sometimes it’s trying to go pro and others it’s just getting caught up in the hype of being a celebrity.
4. Become boring or lose credibility.
5. Reflect, refocus and go back to blogging about what you’re passionate about.
6. Become popular again…

I think this process is why I read so few blogs from people who make their living from writing/publishing. The interest I have in blogs is to hear from people on the front lines doing the interesting stuff, not the ones that are just writing about it and it’s really hard to be an A-List blogger and get much else done. When I do read full time bloggers it’s usually because they make good filters for the great torrent of information that flows around the internet, allowing me to read the good stuff and skip the rest.

Finally, to provide something constructive, let me point to Planet Intertwingly. Since subscribing to it my list of articles to consider more carefully and/or blog about has started overflowing. Sam Ruby hosts it and it’s full of seriously smart people with a strong tech focus. I’m pretty sure it picks up all the Planet Apache blogs (also good quality), but I take it as a huge compliment that my name appears in that list anyway.