Credit to Crucial and a rant about the OSX Finder

A bit of a departure, but given my temporary World Cup induced break I thought I’d try to remember to give a little bit of credit where it was due.

Back in November last year I bought a Macbook Pro, and upgraded the ram via Crucial to 4Gb.  The machine never really ran properly, however: it always felt very sluggish when swapping between applications and even simple things like Dashboard or even accessing menu items resulted in the ‘spinning beachball of despair’ for a few seconds.  I tried everything – reinstalling OSX and all apps was the final straw, but even that didn’t cure things.  I really had no clue what was up, but a chance loan of a friend’s Macbook (with 2Gb ram) made me curious about whether I had some defective memory.  Inspired by how fast a contemporary Macbook was, and how sluggish my (theoretically faster) Macbook Pro was in comparison, I decided to dig out the original Apple ram, and re-installed it.

Bingo: instant zippiness.  For sure, there was something wrong with the Crucial ram.

So, this is where I want to thank Crucial for a totally no-fuss replacement.  They handled my warranty claim with great efficiency and professionalism.  I don’t know what the actual problem with the ram was (it had always tested fine in various hardware tests that I tried) but it was no longer my problem: a new pair of 2Gb chips arrived within a few days and since then the Macbook Pro has got its mojo back!

On the subject of Apple, I’d like to take a pop at the Finder.  How is it that, in 2010, following ten years of iterative enhancement to OSX, we are still saddled with a buggy and inconsistently designed file manager.  The Finder, quite frankly, is the elephant in the room where the Apple system is concerned.  It’s prone to crashing when accessing SMB based network shares and when it goes, you’ve often no choice but to power down (software restarts frequently don’t work).  This is not a good thing in an otherwise class-leading operating system.  I simply don’t get why Apple don’t look to what’s going on in the third party file manager market and learn a few lessons.

Case point: Path Finder, an affordable and really well put together file manager, offers so much more, with tabs, a drop-stack and loads of useful features.  Ordinarily, I prefer to stick with the supplied ‘core’ applications, but I thoroughly recommend any Mac user to try to minimise their use of the ‘Flaky Finder’ and give Path Finder a try.  No ties to Cocoatech, who make the app, apart from being a very satisfied (paid up) customer.  Go try it!

Prototyping and Minimal Viable Product

Historically, the software industry has been plagued by spectacular failures: massive enterprise developments which fail to meet even the most basic requirements; applications whose feature sets are over-complex and confusing; web portals promising the earth but delivering very little – the list goes on and on.  Countless budgets have been swallowed in the pursuit of the ‘next big thing’, the ‘killer app’ which will change everything.

It’s a tough industry at the best of times, but sometimes we make it tougher by simply aiming to do too much.  We put our heads together around our funky meeting tables and let rip, resulting in huge, complex lists of possible features and requirements.

The sad truth is, though, that we’re not always that great at getting the basics right.  In fact, scrub that, we don’t even know what the basics are.  Why?  Because in our rush to please, we forgot to really work with our users to identify what they really need.  We thought we knew best, and acted accordingly.

Wrong.

In the world of the micro ISV, there’s a strong trend toward keeping things simple and offering limited feature sets which work and serve the majority of users, rather than extended ones which aim to please everyone.  We call this ‘minimal viable product’ (MVP) and in essence it’s all about getting to market quickly at a minimal cost and maximum return on that cost.  It’s typically geared toward getting the first version of a product out there to effectively ‘test’ a marketplace.  And it works.  Rather than commit huge budgets toward building every little feature, a company can save time and money and concentrate on fine-tuning a product and its positioning within a specific market.

So, how does this fit into the software prototyping ecosystem?

That’s an easy one.  MVP is as viable an approach to test the acceptance and suitabililty of a prototyped solution design within an organisation as it is to a commercial product out in the big bad world.  The same rules apply; designers can focus their efforts on creating smaller, simpler prototypes to stimulate discussion with end users.  ‘Edge-case’ functionality is conveniently out of scope, and everyone turns their attention to the core, minimum feature set.  When this happens, we spend much more time really working out how those core features should work.  We quickly identify those features that users need the most.  Need, not want.

In conventional MVP, there is an emphasis on measuring what users do when they use a system.  The real power of MVP is collecting and interpreting this data and feeding it back into the refinement of the system’s design.  Sound familiar?  Of course – it’s simply an ‘in-the-field’ version of what we use software prototypes for: gathering contextual information about what works and what doesn’t before committing to particular aspects of a design.

MVP is, in a way, both a compliment and an alternative to conventional software prototyping – both have their uses and there’s a strong argument to think of MVP as simply ‘live prototyping’.  Either approach can deliver real benefits by saving time and avoiding unnecessary design of flawed or non-viable features.