HMK's Spurious Thoughts

This blog has moved...

Sun, 25 Oct 2009 18:58:38 +0100

I moved this blog onto its own domain: http://www.spuriousthoughts.com/.

You can subscribe here.

A rant about (enterprise) software in the cloud

Wed, 21 Oct 2009 10:49:56 +0100

Disclaimer I'm a huge fan of yammer. Fantastic service. Clean UI. Love it. iPhone and desktop clients. We use it everyday in our little corner of the universe. If you're not using it within your enterprise, make sure to check it out. It's fantastic. As far as our set-up and user count is concerned, yes, I know that I'm arguing from the point of a rather small business. Internalized the disclaimer? No? Read it again. Did you get it? Good. Confession Todays outage of yammer pushed me over the edge. I have to confess: I ~~hate~~ strongly dislike enterprise software in the cloud. There are hundreds of thousands (if not millions) of users hammering the system at all time. Don't tell me that this is improving the odds of a stable system. If you're paranoid (I'm not), you smell privacy issues. If the system goes down, you're hosed. You can't do anything except frantically pressing "Refresh" in your browser of choice. Or check Twitter. Or blog. Generally speaking: Do anything but get work done. It will get even worse if your external internet connection goes down the drain because the caterpillar driver from the construction site next door had a bad hair day. Compare this with our internal installation of JIRA. Enterprise software. Quite pricey (as far as I am concerned). We plunked down $2000+ for the license plus $2000 / year for a support/update contract (which I can cancel at any time and still run the software as is). But worth every penny (or cent, depending on where you live). And it's running within our firewall. On a mac mini. It is running flawlessly with about 10 users on-site and 15 users on two external sites accessing it basically 24/7 (plus 120+ not-so-frequent users), 18500+ issues. Our software development group lives within JIRA. Did I mention it's running within our firewall? And it's fast. Plus, it's backing up the database three times a day. Plus backing up the whole system to a bootable disk at night. In four years, the system was down once for about 4 hours, because we somehow managed to insert a 4MB unparsable piece of crap into an issue which caused memory overflows on the server. Lesson learned. Don't insert crap into an issue comment. If the server (yup, it's a mac mini) goes down in flames, I will get hit with a rolled-up newspaper immediately because nobody will be able to get any work done. I will run into the server room, murmur a few expletives of my choice, take the nightly backup disk, put the latest database backup on it, confiscate any mac in our office, plug in the backup disk, boot from it and JIRA is back up for all our users. Net time for this stunt? About 10 minutes. If I refrain from cursing, it's more like 7 minutes. I then trash the faulty mac mini, get a new one from the store nearby for $500, do the same stunt again, and we're fine again. Summary Traditional IT isn't that bad. If we f$%& up, it's our fault. If we messed up the set-up, it's our fault. But we're in control. If I have a bad hair day, I can do something about it. Tune in next week when you'll hear Dr. Bob say "I feel a rant about software as a service pricing coming on...". Thanks for listening. Ah, I feel better now. I should try to get some work done.

Avoid Alert Dialogs / Messages...

Thu, 15 Oct 2009 13:12:32 +0100

Yammer 2.0 for iPhone is a huge improvement over 1.0. Local caching. Improved performance. Way better usability. Excellent. One gripe. After composing and sending a new message to yammer, I am greeted with the following alert:

Which requires me to press "OK" in order to proceed with my quest of wading through a morning's list of messages while waiting for the car in front of me to move another inch through morning traffic jam. In order to avoid the alert dialog / message, I would suggest to insert the new message into my list of messages, probably marked with a special badge or color in order to let the user know that the message was sent. Lesson to be learned: Avoid alerts at all cost. They get in the way of the user. Most of the time, users don't read them, anyway. There's almost always a way to achieve same goal without an alert dialog. (...stepping down from soapbox)

HelfRecht Zeitplanbuch und iPhone

Sat, 10 Oct 2009 14:35:04 +0100

Nach Jahren der Abstinenz habe ich neuesten HelfRecht-Katalog eine iPhone-Tasche entdeckt, die sich in ein Zeitplanbuch Topline-S mit 17mm Ringmechank einheften läßt. Konnte nicht widerstehen. Perfekt Sache, wenn man das iPhone mal nicht in der Hosentasche transportieren will.

The Atlassian Dragons Exercise

Fri, 09 Oct 2009 19:02:29 +0100

The installation process for the Atlassian Starter suite - Crowd, Bamboo, Fisheye, JIRA, Greenhopper and Confluence - is quite daunting and takes about 5 hours+ (way more on my Parallels VM setup, but I did expect that). It's obvious that the different Atlassian products have been built by different teams, at different times and sometimes even different companies. Although, AFAIK, all products are built with basically the same base technology (J2EE), each product has some minor differences in * Installation * Configuration * Directory set-up * Starting up / Stopping products (e.g. there's no shutdown command for Crowd, Bamboo automatically installs as a service) * Configuration files If the suite has to be installed manually, consistency in the setup process trumps everything. This is even more relevant if the suite is installed by a non-IT, non-Java plain old-fashioned C++ hacker like me. Generally, editing the configuration files was no big deal, although the sheer number of changes necessary induced cross-eyes at times. Including Crowd into the installation process made the setup process quite involved and complicated. Although single sign-on is quite a feature, I wouldn't consider it crucial for a 10 user set-up. I would've preferred to make integration with Crowd an optional exercise. Plus, removing Crowd from the standard equation would have enabled more detailed feedback on setting up the different applications's integration features. Kudos to the Atlassian documentation team responsible for the detailed step-by-step descriptions. It was close to perfect, just very very minor errata in terms of version numbers. A few more screenshots would have been helpful, but would have made the endeavour of documenting the suite's installation process not only daunting, but outright impossible to maintain over time. I was very disappointed that Crucible was neither part of the exercise nor part of the $10 offer. Atlassian, please make Crucible part of the Dragons exercise and part of the $10 / 10 users offer. I'm sure there were very good technical and/or business reasons not to include it, but if the Atlassian team can pull of a stunt like the Dragons exercise, I know they can pull off including Crucible, too. It just takes a few more beers, I suppose. German beer, of course. :-)

Work ethic

Wed, 23 Sep 2009 16:25:37 +0100

After experiencing the "Magic" tour concert of Bruce Springsteen & The E-Street Band in 2008, I felt inclined to draft a blog post on "Bruce Springsteen and Work Ethic". However, I never finished because I couldn't quite find the right words. Luckily, I stalled. Today, I found an excellent blog post by Craig Peters which sums up the topic quite nicely:

Work ethic is just one of many reasons why the Springsteen canon has become the soundtrack of a generation and why he continues to create five-star albums while so many of his contemporaries have drifted off into the nooks and crannies of retirement and classic rock radio. The energy, passion and dedication he brings to his work is unmatched in the entertainment world. We'd all love to bring the same kind of energy, passion and dedication to our own work, whatever it might be.

You can always argue about music, taste or if a certain artist / kind of music resonates with you - but you can't argue about the work ethic, energy & dedication you should bring to your job. Make sure to read Craig's complete post.

Cutting down on RSS feeds?

Sat, 11 Jul 2009 22:08:17 +0100

Brent Simmons makes the case for a News Diet. RSS no longer delivers news to me. Twitter delivers news. And if I miss some, I don't care that much. It's quite easy to ignore a tweet as it scrolls by. RSS delivers longer essays on certain topics to me. I've unsubscribed most of the standard "news" sites and focus on "meatier" sites. That said, I should probably weed out some of my 1200+ feeds :-)

English as a second language

Sun, 05 Apr 2009 19:13:09 +0100

Jeff Attwood - The Ugly American Programmer:

Advocating the adoption of English as the de-facto standard language of software development is simple pragmatism, the most virtuous of all hacker traits.

Let's face it: If you aren't able to read & write English in a reasonably fluent fashion, you're in trouble - you won't be able to participate in any discussion or project on a global scale. Plus, you'll be late to every party - and you like the latest fad as everyone else, don't you? Yup, this requires some work on your behalf. Get over it and start working on it. Right now.

On Functional Specifications

Sun, 15 Mar 2009 16:50:17 +0100

Reading through Christoph's take on Joel's latest "How to be a Program Manager", I stumbled across the term "Functional spec". Coming from a C.S. background (admittedly, a sin of my youth), I continue to struggle with the term "specification", as I associate it with * using a formal language, e.g. predicate logic * formal verification of programs * defining the complete input, output and behaviour of the software using these tools. I don't think you can fully understand the problem domain, the software to be written and it's interaction with users or other systems by creating a text document in plain English (or any natural language of your choice) deliberately sprinkled with some graphics - of course you can't do it with predicate logic either. The main reason is that while creating your "specification" you will lack the feedback you get from actually implementing the system and from putting your code in front of users. This is way more valuable than sitting in an ivory tower waxing eloquently about a system's intended features. So I suggest to put another label on the document Joel is talking about - "Functional Overview", "Functional Description" or "Functional Outline". Don't burden a useful document and its intended purpose with putting an inappropriate and misleading label on it. Now that we this issue out of our way, we can start having a more useful discussion about what to put in the "Functional spec", err, "Functional Overview". Here's my take on it:

Here's what we know now. This is what we have to be aware of when starting out. This is how the interaction with the user might work out. Here are the external dependencies on other systems.

Just write enough "Functional Overview" that you are confident in your ability to move through the problem domain and take turns as you learn new things implementing the system and putting it in from of customers. You will be way better off investing your energy in defining the expected inputs & outputs of the system (and its components) as automated functional, acceptance and unit tests. And getting the system out to users & testers in order to get real feedback of a real system and learn about the shortcomings of your initial specification. There. I said it.

Effective C++ - Third Editon

Sun, 15 Mar 2009 11:35:10 +0100

Re-Read Effective C++, Third Edition by Scott Meyers over the weekend - a fantastic book about the intricacies of C++. The very existence of such a book is a testament to the many things which are wrong with C++. [Update: As I'm writing this, Burce Eckel has posted a thoughtful article about The Positive Legacy of C++ and Java - which approaches the topic of C++ being a complex & convoluted language from a different angle] [Update: John D. Cook mentions another interesting post (dating back from 2007) on this very topic] [Update: The C++ FQA Lite sums up the main intricacies quite nicely]

Is Quality Dead?

Thu, 05 Mar 2009 12:30:40 +0100

This looks like the start of an extremely interesting series: Quality is Dead #1: The Hypothesis. Another factor contributing to this crisis are insanely short release cycles (even for desktop software) and the expectation that each major update has to introduce substantial new features. Lot's of them. There's no more time to polish & deepen existing features.

Sr. Ken Robinson

Thu, 15 Jan 2009 12:04:18 +0100

If you haven't listened to this talk (which is both deep and hilarious at the same time), you should at least read this.

Be liberal on what you accept...

Fri, 09 Jan 2009 09:00:55 +0100

In stackoverflow podcast #36, Joel & Eric are waxing eloquently about how adhering to the principle

Be liberal on what you accept and conservative in what you send.

causes massives problems for Web browser developers. While I understand that having a strict HTML / Javascript parser would ease our pain as engineers tremendously, I would argue that this very principle actually caused the explosive growth of the web in the first place. It opened up building web pages to thousands, if not millions of people whose brains aren't wired in the strange ways tradional programmers' brains are wired. A strict HTML parser spitting out cryptic error messages (and that's all you get from a strict compiler, trust me, I've seen them all) would have stopped them dead in the tracks. Jeff Atwood has a slightly different, but interesting angle on the topic. Just to beat an already dead horse into the ground... :-)

Upgrading my blog to the latest MT 4.23 templates

Tue, 30 Dec 2008 16:36:21 +0100

...let's see if this entry makes it to the main index.

Why Unicode isn't enough

Tue, 09 Dec 2008 12:17:38 +0100

A birds-eye (but nevertheless important) view of why "Just use Unicode" isn't the solution to all i18n problems: Pet Peeves - Unicode.

(Via Sam Ruby.)