I have an Arts degree (Liberal Arts degree to my American readers). I majored in Politics and Philosophy. My politics interests were largely around political theory and US politics and my philosophy major was in Cognitive Science. But somehow I ended up being a geek. And weirdly I found that I am not alone.

These companions of the road have prompted me to start thinking about how and why I ended up in IT. What makes we Arts graduates and students, who are obviously a minority in IT, attracted to the field at all? My musings are obviously highly subjective and your mileage may definitely vary but I thought I’d put a few thoughts down.

So how did I end up in IT? I’ve always had an interest in computers from an early age and can remember when I first discovered BBS’es and the sound of our first modem, a monstrously fast 1200 baud brick, featured heavily in my childhood. I never really considered actually working with computers though. I had some idea I might like be a lawyer, a journalist or perhaps work in government. Those are certainly fields many of my classmates at university ended up in.

I stumbled into IT through local government. I worked through university doing odd jobs but largely as a library assistant. Libraries were one of the environments that computerized early and, for all the jokes people make about matronly librarians, are often at the cutting edge of … well managing information. At the library they had an AS/400 that ran things. Or sometimes not as often happens. When that “not” happened they generally had to find someone to get it working again. Being one of the more computer literate people I wasn’t afraid to try to fix it. Throw in dumb terminals, PC, scanners, bar code readers and a myriad of other electronic devices and that quickly turned into a full time job. When I worked out that the full time job I had just acquired paid a hell of a lot better than stacking books I decided I’d give this IT thing a shot. That was twenty-something years ago.

As my career in IT continued I began to run across more and more people with Arts degrees. Before I worked in IT I had presumed everyone who worked with computers had computer science, mathematics or information technology degrees.¹ That turned out to be a somewhat erroneous assumption. Looking around the office today I can see three Philosophy majors, one Anthropology major and dog help us an English major. All cutting code.

So why did we all end up there? I could say money. That certainly played a factor for me. But I actually think it’s something more interesting. I think we’re wired right for IT. Arts students are generally good at three things²:

• Consuming information,
• Assimilating information, and
• Synthesizing information

And IT? It’s intrinsically about those three processes. Replace “information” with “data” and you’ve just described about 80% of the workflows I’ve built in the last twenty years. I’m good at taking the inputs, working out how to manipulate them and output them in some new, hopefully useful, way. I don’t claim to be a brilliant developer. I’m much more a hack’n’slash experimenter. But learning how to do this manipulation with code instead of prose actually wasn’t that hard.

Another reason I think a lot of Arts students are attracted to IT is that we’re good at Systems thinking. Good at seeing the big picture. You want to understand political, economic and social models? Welcome to Systems thinking 101. Perversely some IT graduates I’ve worked with seem wired to respond to specific outcomes or events in systems rather than see that those are components of a larger whole. Naturally they often then trip down the stairs of unintended consequence.

Finally, many of us are also quite articulate.³ Most Arts students can make a serious case for Marxism as a viable political system. Arguing vim versus emacs is kinda child’s play in comparison. We can produce documents, presentations, design specifications, cut code, and argue obscure points of German philosophy. Don’t get my started on one of my colleagues obsession with Saul Kripke.⁴ All of which means we’re people who can combine tech with talk. A winning combination for getting cool jobs and making good money.

And I never did become a lawyer. So I guess things can’t be all bad.

Initially I thought it was a bit silly: a bunch of office workers wandering around with knives. Then I started to notice another American phenomena: packaging from hell.¹ All of a sudden every time I got a package I had to go find a knife or scissors to open it (or have the three people near me nod knowingly and lend me their knives).

So whilst I don’t think I am ever going to need a Leatherman tool on a regular basis a simple clasp knife is actually quite useful. So I bought a nice and fairly cheap Gerber folding knife with a clip that I can tuck into my jeans. It’s proven quite practical so far.

Hackers

What a cast of off-beat and improbably handsome computer hackers: Crash Override AKA Zero Cool, Acid Burn, Lord Nikon (token black hacker!), The Phantom Phreak (token Puerto Rican hacker!), Cereal Killer and of course my personal favourite: Mr The Plague. In the classic “Damn you meddling kids” scenario famous since Enid Blyton and Scooby Doo our youthful hackers foil the evil plans of evil hacker The Plague to steal money and sink oil tankers?!? Add and stir rapidly a bumbling Secret Service agent, a lame romantic sub-plot, hip young folk on roller blades and a club scene soundtrack. Instant hot geek.

The Good: Social engineering at the start of the movie as Crash Override hacks the TV Network.

The Bad: The typically ridiculous depiction of the actual hacking. The appalling clothes. Matthew Lillard.

Swordfish

Oh my … where to start with Swordfish? We have the classic hand-wavey construction of a virus to hack 1024-bit DNA Binary SSL HiTek Security TM. We have “Axl” Torvalds - famous and bloodily assassinated Finnish hacker. And of course we have Hugh Jackman’s improbable hacker pentetrating a government system in 60 seconds with a gun held to his head and whilst getting blown. Oh please.

The Good: Ummm… Halle Berry?

The Bad: Pretty much everything technical AND non-technical in the film.

P.S. None of which compares to John Travolta’s massive piece of over-acting in a performance that would be truly hideous had Travolta not made Battlefield Earth.

Firewall

Another “blackmailed hero forced to do wrong” story has Harrison Ford as a corporate security expert forced to rob his own employer. Mayhem ensures, family kidnapped, lamest bank security ever and incredibly tenuous connection between the title of the movie and the plot.

The Good: Using his daughter’s iPhone as a USB drive…

The Bad: Using his daughter’s iPhone as a USB drive… Oh wait. Completely unrealistic security controls. Also firing his secretary on the spot? Yeah the script writers have never worked in a bank.

WarGames

Rogue AIs, war dialing hacker, cute teen romance, nukes and Cheyenne Mountain? What’s not to like about this movie? Computer hacker breaks into what he thinks is a game company but rather finds a back-end into a top secret NORAD system. From there whilst trying to play a war game he accidentally triggers the countdown to World War III and nuclear war. He then rushes to try to stop the AI launching it’s missiles and “winning” the game.

The Good: Actually resembling good depiction of social engineering, war dialing, and how a hacker compromised a system back in the day. Except the AI of course. Everyone knows the US government doesn’t have an AI running war games at NORAD…

The Bad: Actually there’s not much to hate about this film. I mean the AI theory (tic-tac-toe as learning tool) is kinda lame but generally it’s good fun AND has Ally Sheedy.

P.S. We don’t discuss the sequel - WarGames: The Dead Code. IT DID NOT HAPPEN. DID NOT HAPPEN.

Sneakers

What is it with buttons/ciphers/boxes that can magically hack through all encryption instantly? Yep here’s another. This time in a unique twist a mathematical genius comes up with a box that allows all encryption to be overcome. Naturally it also magically interfaces automatically with every system ever developed.

Throw in a quirky team of hackers lead by on-the-run super-hacker Robert Redford (BTW no one background checked this guy for 30 years? Really? Whatever…). The team’s line-up even sets the pattern for a number of future films: young kid looking to prove himself, cynical older operative, brilliant but disabled tech, conspiracy obsessed oddball, etc, etc.

Sneakers though does have some street cred. Despite the magic cypher box they use some nifty social engineering and much of the ‘tiger team’ hacking they perform at the start of the movie is reasonably feasible. They even hearken back to the glory days of phone phreaking with a Cap’n Crunch reference.

The Good: Cosmo on InfoWar - “There’s a war out there, old friend. A world war. And it’s not about who’s got the most bullets. It’s about who controls the information. What we see and hear, how we work, what we think… it’s all about the information!”

AntiTrust

Open source. Obviously most people know us because of the beaucoup bucks we make as rock-star developers but many people don’t realize it’s also mandatory to have our model-like good looks. This movie thankfully captures that and the purity of our code. Like some others in the list it’s not a true hacker film, more a glorified action movie/thriller, but some code is actually cut and they do introduce open source software.

The Good: Hmmm. Ummm. “Look! Over there! A large software company that really isn’t Microsoft… honest.” Probably vaguely raised public awareness that open source code exists.

The Bad: That anyone got paid for this film.

The Net

Reclusive but beautiful developer (giggles) discovers secret Internet conspiracy and is forced to go on the run. Against all odds do you think she’ll win through? Yeah I totally didn’t either. So apparently every website has a magic link (and you can bet about a thousand idiots added that icon to their sites right after the movie came out) that allows you to take control of it. Despite the magical decryption link this isn’t actually a hacking movie. The main character cuts code and the evil terrorists use the Internet to conduct their foul deeds but it’s largely a rather poor action movie.

The Good: Nothing.

The Bad: A little icon on every web page that unlocks the secrets of the Interwebs…

It requires the flowdock gem to be installed on your Puppet master:

$ sudo gem install flowdock

You can then install puppet-flowdock as a module in your Puppet master’s modulepath. Now update the flowdock_api_key variable in the /etc/puppet/flowdock.yaml with your Flowdock API key.

Then enable pluginsync and reports on your master and clients in puppet.conf including specifying the flowdock report processor.

[master]
report = true
reports = flowdock
pluginsync = true
[agent]
report = true
pluginsync = true

Finally, run the Puppet client and sync the report as a plugin and hey presto you’re logging failures to Flowdock.

Last week I finally got around to hammering something out and after some fighting with the Cloudkick API I’ve written up a module that handles agent installation and node creation (via the API). You can have a look at it here and I’ll pop it on the Forge here.

It’s very easy to use and documented etc. Patches, feedback, etc welcomed.

Well generally the bad posts aren’t product comparisons at all. Rather they document someone’s experiences with trying to find a solution to suit a specific organisation or set of needs. This is sometimes interesting and sometimes useful. But interesting only as a subjective point analysis. These posts are far from actual product comparisons.

It’s pretty easy to identify the two categories. Let’s examine these two statements:

"We needed to achieve x and Product Foo had a widget for doing x that we 
liked better than Product Bar's widget. This is how we implemented
th x widget."

And:

"When doing x with Product Foo and Product Bar we observed that:
  - Product Bar was y times faster than Product Foo
  - Product Foo works on platforms a, b, and c whilst Product Bar only
    supports platforms a and b.
  - Product Bar has a comprehensive API and documentation whilst Product
    Foo needs more work in this area and didn't cover how to do d, e, and f."

One of these is an organisation-centric analysis of a product and the other is a product comparison.

So why does the difference matter? It matters because it impacts how and why we choose new products. Selecting a product based on someone else’s selection criteria makes for a poor technology choice. To avoid this:

• Gather your requirements
• Find the quality product comparison posts, the ones that use objective criteria
• Use these posts to stock your short list of products
• Test the short list against your requirements and document
• If you do document your choice in a blog post then be clear about your selection criteria and document the sources of your information

Well it hasn’t turned out quite like that. I really, really wanted to like World of Warcraft. Really I did. I like computer games. I was a fan of a lot of role-playing games. I enjoyed years of playing level-based fantasy and science fiction games. I also find a quick session of senseless pixel destroying often relieves a lot of internal stress. I enjoy blowing away bad guys, zombies, aliens or post-apocalyptic beasties.

So what’s wrong? Well the key problem isn’t the graphics - it really is quite a beautiful game. One of my favourite things is flying through the various landscapes and looking at the scenery. But the game play. My word it is boring. And repetitive. And slow.

The same basic scenario, give or take a few minor variances, occurs over and over again. Kill x number of these things, so fetch that thing, collect x number of these things. Now before you all jump in and say “All computer games are like this…” Well they ain’t. There is a long tradition of amazingly interesting and plot-driven fantasy (and other genres) computer role-playing games. The early Fallout games (and their precursor Wasteland too) are excellent examples, as is early fantasy such as Darklands, much of the Might & Magic series and classics like the Elder Scrolls series.

The other part that bewilders me is the so-called social element of the game. I’ve discovered that almost all of the “Dungeon” maps require a party. A single player is quickly swarmed and overcome in most of these locations (although perhaps I just suck at it?). Now I like the idea of playing with others but most of the people I know in the game are based in Australia or New Zealand and time zones make cooperative gaming tricky. So a whole segment of the game is largely unavailable to me, which is somewhat annoying.

Sadly it seems I’ll skip any potential addiction to WoW and have to settle for maintaining my existing addictions to work and cigarettes.

P.S. And I did give it a good shot - I levelled a character up to about level 50 before I got frustrated and bored.

So since #monitoringsucks appeared I’ve been hoping that some people who take heart and start writing modular, scalable, and extensible monitoring components and tools.

The team at Sonian have kicked off things with the introduction of Sensu. Sensu is a new cloud monitoring framework with a Message Bus-based model. Sonian describes the concept as:

The idea behind Sensu is simple, schedule the remote execution of checks and collect their results. As mentioned above, Sensu uses RabbitMQ to route check requests and results, this is the secret sauce. Checks will always have an intended target; servers with certain responsibilities, such as serving web pages (webserver) or data storage (elasticsearch). A Sensu client has a set of subscriptions based on its server’s responsibilities, the client will execute checks that are published to these subscriptions. A Sensu server has a result subscription, this is where clients publish check results. Since each component only connects to RabbitMQ, there is no need for an external discovery mechanism, new servers are monitored immediately.

It’s an interesting concept and one I think merits some development. It’s not quite the direction I think is needed totally. It’s still heading towards a somewhat more monolithic framework than I feel is needed. I’d like to see things broken into a lot smaller components but it’s a really good start.

To make it a bit easier to try Sensu out I’ve added a Puppet module and Vagrant file to help you build it. Tim Sharpe of GitHub fame is also working on it and has developed his own module too. I’ve also added some plugins to monitor Puppet and an alerting handler to send check notifications to IRC.

If you’re lucky enough to be involved in the beta (or if you make use of the product after launch) then I’ve developed a Puppet module to deploy Boundary probes. It installs the required software and has a custom type and provider to deploy Boundary meter probes.

If you’re an iPhone user then there are lots of options available to you, like Boxcar for example, but Android users have a lot less choice. Especially since Notifo is going to shut down (it’s still running right now but apparently only for a little while longer).

After some searching I stumbled onto NotifyMyAndroid which provides exactly the service I was after. Using their excellent bindings I quickly added a simple Weechat plug-in to notify me when people private message me or my name is highlighted. You can find it here and instructions for deploying it are in the README file. You’ll also need the NotifyMyAndroid application installed on your phone.

Hope it helps someone!

This post was inspired by a question, possibly snarky, about why I bothered to publish things to GitHub. I publish a lot of little tools, plug-ins, add-ons and even small applications. The questioner’s sentiment was “why bother?”. Write the code, solve the problem, move on. Posting the code means writing documentation, maybe tests, cleaning it up. Then having people actually using it means you get bugs logged and people want help. All of which consumes time and is a “pain in the arse” to manage.

So why bother indeed? Well I’ll front up and say part of it is ego. I like showing off and publishing solutions, neat tricks or cool tools is the ultimate show-off material in the technical world. It’s also excellent career material. I rarely see a job advertised (at least ones I am interested in) that doesn’t ask for your GitHub user name. In some cases your GitHub account is as good as a cover letter AND a CV.

It’s also a personal development opportunity as well as a career enhancer. I love learning new languages, new frameworks and puzzling out how to make things work. Ironically often using snippets of code other people have puzzled out. Turtles all the way down.

Some part of it also overlaps with why I am involved in open source. If you write code that could help others then it just makes sense to apply an open source license to it and publish it. This is not just because other people should suffer through my code but because good open source citizens share.

Lastly, sysadmins spend their lives solving problems. Often painful and un-fun problems that occur at inopportune moments that mess with your life. Being a sysadmin is an awesome job but it can also be a job that sucks when things go wrong or when you have an annoying or labour intensive task. The way I solved a lot of those problems, automated a lot of those tasks or just generally made things better was by steali^H^H using other people’s code and tools. If others hadn’t made their cool solutions and tools available then my life as a sysadmin would have sucked a whole lot more. The fact that others went to the trouble of making things that made my life easier matters to me. So in turn helping solve other people’s problems or making their lives easier matters to me too. And that’s why I make tools.

• A simple binary
• Laid out so I can create a gem from it including a Gem specification
• Versioning
• A config.ru file so I can rackup if I need to
• A README file, license and the miscellaneous trappings
• Created as a Git repository

I was going to create a tool to generate my own Sinatra application templates but then I saw a Tweet from RubyGems about a Sinatra application generator called Mafia.

Naturally being a proper Rubyist I examined it disdainfully and then proceeded to write my own anyway because there can never be enough Ruby-based tools that do the same thing. Oh wait. No I didn’t.

I did, however, add some new code:

• Addition of a simple binary
• A default action for the application. I like things to work out of the box.

I’ll also add basic RSpec testing to the template when I get a chance. I struggle with testing for Sinatra still. I’m still learning RSpec and am not sure yet what the best framework is to test simple Sinatra applications with. If anyone has recommendations or suggests alternatives to RSpec or has some good examples of how to test applications (especially DataMapper) I’d welcome the input. Every example I’ve seen online is subtly and annoyingly different.

So when we started talking about running some public triages of tickets at Puppet Labs I decided we must have a tally board to score who changes the most tickets (or at least who games the system fastest to achieve the highest score).

So I set out to write a very quick and dirty tally board. I rather unimaginatively called it Tally. It’s written in Sinatra and uses DataMapper and an Sqlite3 database back-end. It takes a feed from a Redmine plug-in that generates events when tickets are updated. You can see a sample:

The reason for this is two-fold:

• I don’t have space to buy and keep books as we’re living overseas in a small apartment.
• I buy a lot of books I just want to read but not keep. Previously this meant every few months I’d cart piles of books to Powells to sell. This was/is annoying.

Obviously not everything I read is available on the Kindle but a lot of it is and the other stuff I don’t mind buying because it’s low volume and I do still like the feel of paper when I’m reading. Although I’ve been pleasantly surprised to discover I do find reading on the Kindle quite satisfactory as an experience. Indeed I’ll probably even buy one of the new Kindle Touch 3Gs when they are released because I find the keyboard and page change buttons annoying and painful (I see no need for the full color bells and whistles Kindle Fire).

One of the side-effects of buying Kindle books is that I noticed the “People who bought this book also bought/liked…” page at the end of Kindle titles and I started browsing the Kindle store a lot more. There are a lot of books in the store, actually far more than I was expecting for the sometimes backward publishing industry. Then I realized that a hell of a lot of them were self-published titles with quite reasonable price tags: $0.99 - $2.99 on average.

The self-published material greatly varies in quality. Some of them are best described as simply awful. An old adage about behind every good author is a depressed and inebriated editor sprang to mind but in many cases not even good editing could save these books. I’ve mostly been looking at genre fiction and every bad example of pulp horror, thriller, science fiction and fantasy is present. Every space marine, post-apocalyptic nuclear wasteland dwelling, mutant killing, psychic-powered zombie barbarian warrior overlord is present. Often with a buxom blond sidekick, a lost throne and/or a deadly secret. Oh my!

And my word are some of these people terrible writers. Wooden dialog, transparent characters, plot holes you could drive the Death Star through and some truly, hilarious by its badness, prose. I was reminded of the writing contest in Sharyn McCrumb’s iconic Bimbos of the Death Sun (ironically named in rather a similar manner to some of the books available in the Kindle store). I tried to put some of these on a scale against some of the more dire things I’ve read (I collect post-apocalyptic fiction as a hobby and I’ve read some appallingly bad books, for example almost all of William Johnstone’s “Ashes” series which should frighten anyone who knows the genre).

And to be fair in the process of finding out that many of them were crap I did buy many of the books involved hence lessening the sting of the insult by paying for the right to insult them although tragically also potentially validating the author’s belief in their writing being good… :)

Amongst the dross though there is a gem or two. Some talented writers who clearly haven’t found any other avenue to publication. Or perhaps who have not wanted to jump through the many hoops and annoying idiosyncrasies of the publishing industry. I’ve found two or three reasonably solid sci-fi writers and a couple of excellent crime/thriller authors. I don’t know yet of any writers who have started as purely Amazon self-published authors although I know of some who have entered the industry via the self-publishing route (I have some vague memory that Matthew Reilly self-published his first book but think there was more to the story) but I expect if it hasn’t happened already it’ll happen soon.

Of course, that assumes that publishers are looking at any of the material that is published or that some of these more successful writers have any interest in being published in print. For many I suspect the potential deal they will get from a print publisher simply won’t be worth it - Amazon pays 35% to 70% royalties (70% on titles priced from $2.99 to $9.99!). When I read that I nearly fell off my chair. It beats every one of my contracts with publishers previously by a huge margin. Of course a traditional publisher would also be highly reluctant to touch most of these titles because they know they can’t match the sell price and they are unlikely to find an audience at the higher price point.

So what do traditional publishers bring to the table that might entice one of these authors or allow publishers to compete? Publishers traditionally bring three (maybe four?) capabilities:

• Marketing,
• Quality control,
• Distribution, and
• Credibility?

Marketing in traditional publishing covers a broad spectrum of potential channels both electronic and physical. These include promotional activities in media, book sellers, libraries, advertising, and tours. Of course, the investment publishers make into each of these activities is directly correlated to potential revenue the publisher perceives from the title. And in an increasingly tight market … well the resources are slim and hard to extract from publisher’s marketing departments. BTW In the case of most technical books the investment is close to zero.

The quality control publishers offer is a valuable service. A good editor alone is an awesome advantage that can make a book far more polished. A lot of the Kindle titles I looked at would have greatly benefited from an aggressive edit. Of course it’s also to hire one of the numerous (and often recently unemployed) editors on the market. It’s a relatively cheap commodity service usually priced per page or on word count.

Publishers also get books onto shelves in bookstores, have warehouses, ship titles, etc. All of which is moot with e-books or largely moot with print-on-demand because of Amazon’s immense economies of scale in procurement, warehousing and distribution.

And finally there is the credibility issue. For literary books, certainly anything for example that might win a Booker or similar literary prize, being published on paper seems to be the only way to go. That being said the I don’t know what the volume of book sales is generated by the demographic of literary readership: older, educated, likely to shop in a bookstore, my parents. Interestingly I think the death knell of the paper publishing industry will be when a pure e-book wins a major literary prize.

All in all if you’re publishing a Kindle title and making money the print publishing industry doesn’t seem to hold a lot of attractions. And unless the mainstream publishers somehow make themselves more attractive to those authors or seize the ground by publishing themselves (including offering comparable royalty rates - laughs) they are going to go out of business. Leaving these new self-published Kindle authors and Amazon to steal away the entire genre market if not beyond.

(And yes here I’ve largely ignored the non-Kindle self-publishing market, not because I see any problems with it. Certainly in that model 100% of the price of the book is yours rather than some royalty arrangement. My interest in this article is largely the ease of purchase of these titles via a medium like the Kindle because it clearly drives volume in a way that I am not sure self-published titles available via PDF or the like does yet.)

We’re going to fly into Oaxaca, spend a few days there, doing some things that I am as yet a little vague about but will probably involve eating and drinking lots. Then we’re going to fly to Mexico City.

(Anyone ever flown AeroMexico? Am I taking life into hands? I guess I’ve flown Air Southern China and a bunch of tiny, weeny light planes in the Pacific and South East Asia so it can’t be all that bad - stops myself Googling their safety record).

In Mexico City we have pretty limited plans with only Trotsky’s house/museum and Frida Karlo’s ‘Casa Azul’ (“The Blue House”) on our list of things to see but there seems a long list of other possible things.

Feel free to suggest stuff in the comments anyways.

Oh and then I am in NOLA for a week including taking a day off to go visit New Iberia (I am apparently just going to miss the “World Championship Gumbo Cook-Off” too!) and see where all the James Lee Burke books are set. That should be cool fun albeit I will probably be the youngest person on the damn tour as per every literary tour I’ve ever taken.

Done right the MVP model is dynamic, iterative, fast to deploy, gets quick feedback and fearless. The best MVP comes out from a tightly run and managed product management process. Each feature of your MVP product emerges from a user scenario/script, good UX/UI design and pragmatic architecture and design decisions.

Sadly, done wrong and it can be a disaster. This post highlights some of the key things that can potentially go wrong with an MVP and provides some suggestions on how to avoid those land mines.

So how does an MVP go wrong? Well in my humble and recent experience there are three principal failure modes for an MVP:

1. Shipping

2. “Ostrich Syndrome”

3. Quality

Shipping

The first failure mode, shipping, is pretty simple. It happens when you don’t get off your arse and ship the damn product. The idea and the true value behind a minimum viable product is that you iterate, ship fast and iterate again based on customer feedback. Holding onto the product for “just one more feature” not only keeps you from the market but it also potentially digs any architectural, technical or UX/UI holes you’ve made for yourself deeper. Or potentially allow your whole product to fall off a cliff.

Failing to actually get code out and product in front of customers can be recognized when you hear comments like:

“We just need to close these feature tickets out and…”

“I know it’s the third time the ship date has slipped but…”

“At our burn we have three months of money left and we’re going to ship two weeks before that… It’ll be fine.”

The only solution to shipping failure is discipline. Smooth out rough edges by all means but don’t be tempted by feature creep. Set deadlines and met them. Not only does it get your product out into the world but it teaches your Engineering team the discipline they’re going to need to ship regular and solid product.

“Ostrich Syndrome”

One of the key points of an MVP is to seek feedback from customers. Get a product out there that customers can use and see if this triggers interest or causes the market to poke back and validate all your hard spent Engineering and Product hours. Failing to seek that feedback constitutes a failure of the MVP as does failing to seek the right sort of feedback. Seeking but failing to heed that feedback also constitutes a failure of the MVP and makes you an idiot as well.

Ostrich Syndrome can be detected when you hear comments like:

“I know our real customers will want to use it like.”

“She’s definitely not our target demographic.”

“I think we can assume.”

The solution to Ostrich Syndrome is simple: build feedback systems with your product, actually gather the relevant data and then use it make decisions. Building feedback systems is pretty easy:

• Embed feedback mechanisms in the product. The easier, simpler and lowest barrier to use the mechanism is then the more likely someone will actually give you feedback.
• Like/Dislike buttons
• Links to feedback forms
• Tweet/Re-tweet shortcuts
• Inbuilt diagnostic/anonymized data output if feasible
• Use electronic surveys and customer calls/interviews to gather more detailed data
• Monitor social networking, media and blog channels for people’s feedback. This is the hardest sort of feedback to deal with as a lot of it is heavily opinion-orientated. But detect a trend of opinions and you may have tapped a vein of useful feedback.

Then actually devote the time to reviewing and interpreting the data. Divide the feedback into types or categories and track it. To do this you can use a ticketing system or a tool like Pivotal Tracker. A spreadsheet or document can be suitable too or if it suits better a visual representation such as file cards pinned to a wall or stuck to a whiteboard.

Finally, be honest with yourselves about the product and the feedback. And if ultimately you do choose to discard some data make sure you document why so you avoid future rabbit holes.

P.S. Of note is the correlated problem: striking the balance between listening to customers and having one or two vocal customers dictate your product strategy. Obviously if you have some highly engaged customers then that’s awesome but you need to temper their input against a wider pool if you don’t want your product potentially pigeon-holed or a bespoke solution that suits those customers and not the wider market. Favor feedback mechanisms that generate pattern, trend or themed data as well as point information. Patterns, trends, and themes help validate point opinions.

Quality

The last failure mode comes from a misunderstood conception of the MVP:

Liquid error: undefined method `join’ for “\n MVP != Quality\n”:String

Ensuring quality before you release might potentially seem like an inherent contradiction with the first failure mode of an MVP, a lack of shipping. It’s really not. There is a clear difference between shipping something usable and something crap. If a user can’t consume your MVP product because it’s buggy, unusable or fragile then you’re either going to get zero feedback or feedback that highlights its flaws rather than feedback on its capabilities. And naturally people who can’t get your product to work at all or find it too hard to use are unlikely to be persuaded to try it again even if you do fix it.

You’ll see the harbingers of a poor quality MVP if you overhear:

“We’ll fix the UI bugs next release.”

“Don’t worry! It only crashes under load.”

“We don’t have time to test the upload capability.”

So how do you fix enough bugs to ensure people test but not so much that you’re spending more time fixing bugs than actually releasing product? Testing the right things. Especially getting acceptance and scenario based testing right. You know those product plans you have for your MVP? The user scenarios you used to create each feature of your MVP? They are your test scripts. You used your product management process to generate user scenarios and develop features from them. Use them again to generate and execute test plans for each of the portions of the scenarios you’ve developed.

This isn’t rocket science and it’s more than just writing unit tests. Take the user scenarios you’ve developed and execute them: if the feature calls for uploading a file then upload file(s). Treat the product like you’re expecting the user to use it and then test it. If there are bugs fix them. There’s no excuse for writing any feature and then not using that feature internally exactly as you think the end user is going to use it.

Summary

So is this advice worth anything? Well perhaps. I’m not a developer by trade but I’ve played product manager, release manager and hack-n-slash developer over the last few years. It’s based on my experiences over that period and what I’ve learnt. Mostly from stuffing up. Hopefully you’ll avoid some of the mistakes I’ve made.

This means the Wordpress model didn’t overly suit me anymore and I decided I’d finally get around to converting my site to use Jekyll. The process was pretty simple:

• A new layout which I thought was in line with my new workflow
• Converted posts (yes I know some early posts have some crap formatting in places)
• Added some plugins for creating tags, categories, ordinal dates and some other tweaks
• Added Disqus to handle the comments and converted my existing comments

The only gotcha is that my sitemap and RSS feeds will have probably been reconstructed so you might see some older posts as new posts. Apologies for that. :(

Overall though it’ll hopefully mean I write more. Well that’s the theory anyway.

• Added /node/detail/node_id screen that shows details from the specific run (linked as a click-thru from the specific run on main pages (see picture).

• Added /node/node.example.com screen that shows all runs from that node
• Now uses Redis hashes instead of storing JSON - The overall code has been refactored and cleaned up in a lot of places
• The report processor is much cleaned up and simpler to understand

The unfortunate piece is that to upgrade you’ll need to flush your existing Redis data (I promise I won’t do this to you again … the refactor to make this a lot better involved me slapping my head at my previously stupid approach) and start again. As always hope it’s useful to someone and patches and input welcomed.

I hope it proves a useful example for someone and improvements and patches most welcome to it. I have some ideas on how to extend it beyond the very MVP v0.0.1 prototype it is now.