Innovation in Software

Last week I was asked to comment for Crain’s article this morning on Yuuguu. I had to offer up a disclaimer, as I do now, that I have done a little bit of work for Yuuguu and I’m under NDA on what I know about the specifics of the internals of their technology.

Typically when asked to quote I give the journalist way more than they need in the knowledge they’ll pick out the one sentence that fits the story they want to tell. On this occasion what I said in full was:

“Yuuguu is interesting because they’ve executed a plan quite wisely. Rather than get overly clever about technology as many start-ups in the web sector do, they’ve used a suite of established technologies, understood user expectations and then combined them expertly. You don’t know how hard it is to do that right until you try.

They’re also very different to the other IM services out there – they’ve skirted around the problems people have with VoIP in a way that gives them a solid, proven business model.

They’ve taken on multiple markets at once in a way established players in those sectors are going to have a problem responding to quickly.

Even better, they haven’t spent years trying to come up with proprietary protocols and re-inventing the wheel, but instead cleverly blended together the best of what works and extended it to produce something greater than the sum of its parts.

They’re in a tough area and they’re competing on multiple fronts, but I think they’re in a strong position. The IM sector is not engaging with the audience Yuuguu is and uses technology that would scare most IT admins away from deploying it anyway, the web conferencing sector still don’t “get” the modern Web in my opinion, and the companies selling shared desktop solutions have just had Yuuguu chop their business model out from under them – but many have yet to realise it yet, so aren’t responding.

The only real threat might come from better SIP services threatening their revenue model and customers communicating on voice outside of the Yuuguu system. Having spoken to the guys at Yuuguu though, I wouldn’t be surprised if they don’t already have an answer to that.”

I think Yuuguu are a clever outfit that are doing something quite unique. They aren’t innovating in the madcap “let’s reinvent the wheel way”, nor are they jumping on a bandwagon and trying to use the words “social networking” in their business plan. They’ve looked at what does and doesn’t work, found a way to make something that works better and then established a set of technologies based on best industry practice to make those ideas happen. And all the while, the business model is sat right at the core of what they’re doing.

I hope Yuuguu does take off, and does make considerable profits in the long-term. It would be great to see a local tech start-up fly.

Excuse the self-indulgent nature of this post, but I think I’ve been quite restrained on this for the last 12 months and hey – it’s Christmas.

At this time of year, two things always happen to me:

1. I get a little bit melancholic. My playlist changes to have lots of big sweeping chords (think ‘Atmosphere’ by Joy Division, some Band of Horses, some Vaughan Williams). I watch films about people enjoying a simple life such as Harvey or El Perro last night, and think about de-cluttering my own.

2. I start thinking about why I do this for a living all over again.

2007 has been a pretty good year to me. I’ve written about 10,000 lines of commercially deployed code which is a lot. I’ve written several million words in blog posts, e-mails and essays which for me is average. I have about 40 business cards I didn’t have at the start of the year of people I will undoubtedly work with at some point. I’ve also undoubtedly upset, angered or annoyed people unwittingly (sorry!). I’ve almost certainly got things wrong.

Still, now we’re moving to the point where I ask what it is I do, why I do it, and how. Every 12 months I ask the question about whether I want to hire staff, whether I want to go big or stay small. Whether I need to start phoning some of the VCs in that little stack of business cards. Whether I should just go and get a job and not worry about money again for a while.

Getting rid of all the clutter and thinking about what it is I do, I realised whilst reading this article this morning that there is a vision out that there that is so pure in it’s concentrated common sense that at some point this year I once again stopped thinking about doing good stuff quickly and just started doing stuff that paid the bills.

Make it free. Make it simple. Make it open. That was the plan in 2005, so what happened to it?

I read Getting Real when it was first released. I advocate and often use agile methodologies, but there’s something I’m missing. All my projects seem bigger than they need to be. Sounds like I have an agenda for 2008 forming already.

And this is the point. I can make those changes because I don’t work for somebody else. I can take those risks and make those things happen if that’s what I want to do. I can just get on with it.

I never “got” code reviews. I never understood how sitting around talking about somebody else’s code would help them or you, beyond being able to weed out the obviously awful coders.

This week I’ve been doing some consultancy, in-sourced to help a firm evaluate what their developers have built for them. As part of that process I’ve had to review documentation, specifications and code. The process has been at times confusing and enlightening.

It’s one thing to be able to say “this is how it should be done” when you’re not a developer, but it’s another thing when you are a developer who hasn’t done some of those things yourself. This process has taught me as much about myself and my own code as it has about these guys’ code.

Interestingly, I now see things from a buyer’s perspective much more clearly, and I can see how frustrating this must be from the other side. I can see how things which we don’t consider important are to a buyer critical. I can see how clever solutions can sometimes be too clever. I can see how something simple you forget to do can make all the difference.

Last Sunday I trundled up to the local Apple store with company debit card in hand to grab a copy of OS X Leopard. I installed it that afternoon and have spent the last week on the road and at home living with it. I’ve now come to a conclusion:

Leopard is an excellent advertisement for switching to Ubuntu.

Seriously, it sucks. I’m not talking suckiness on a Windows Vista level, but compared to Tiger, it’s awful. Here’s some reasons.

Firstly, perhaps reasonably for a dot-zero release (but still annoyingly), it crashes and/or locks up quite often. In several years of using Panther and then Tiger, I don’t think I had to power-cycle my machine more than twice. I’ve done it five times this week. Sometimes when using an external keyboard on my Macbook Pro, the system “just forgets” it’s there and I’ll have to unplug the keyboard from USB and plug it in again, but sometimes nothing happens even then: Finder stops responding, the mouse stops moving, and then it’s time to hold down the power button for a few seconds and bring it back up.

Whilst we’re talking about peripherals, I grabbed myself a replacement Mighty Mouse whilst buying Leopard (note: the scroll ball clogs and breaks within months, you’ll be buying a lot of replacements for the improved productivity I accept it provides), this time a wireless version. This helped me discover that bluetooth support for mice in Leopard is rubbish. Whether’s it blued taking up 50%-60% of CPU for long stretches of time, to not being able to see the mouse at all on resume, it’s so bad it’s basically useless. I don’t think it’s reasonable load average should be > 0.7 just because I am moving my mouse around.

Then there’s the RAM issue. Sure, with each release of an OS you expect to see more RAM being gobbled up, but I swear, I’ve never seen an OS have a problem with 2Gb of RAM and six applications open, not even Windows. With Tiger I used to be able to do a lot more and have a lot more free space to move around in. Leopard swaps so hard in the same usage scenario that it reminds me of when I was using an iBook G4 with half a gig of RAM.

Let’s now move to the extra features Apple provide in Leopard.

I don’t care what people say, Safari 3.0 is not faster than Firefox – anybody who is saying so just isn’t doing any meaningful measurement. What’s more, Safari still doesn’t “get” the plugin thing, and on my system at least rendered pages like it was spitting out HTML in vomit-like chunks.

The other big upgrade, Mail, is more of a mixed bag. Whilst Mail.app version 3.0 fixes several bugs I had learned to “work around” in 2.0, it introduces a few more niggles. That’s not the big problem though. Quite frankly Mail.app 3.0 needs a stake driving through it’s cold dead heart for producing HTML e-mail that cruddy, insisting all “notes” have yellow ruled-line backgrounds and integrating with iCal as more of an after-thought than as a reasonable feature.

Spaces is worse than 3rd-party solutions I used wth Tiger in my opinion, and gobbles even more RAM – a scarce commodity as it is in Leopard-land.

I’ve not actually tried the new integrated back-up system, because I’ve heard that Time Machine breaks Leopard even more than Leopard does on its own time and you end up fighting reboot screens constantly. I’ll stick with SuperDuper and the odd s3sync

Meanwhile they’ve managed to make sure the Dock is harder to make sense of thanks to little, tiny, blue-ish orbs on a reflective background indicating app state instead of clear arrows. Whilst we’re down there, can somebody please tell me what good are Stacks given that they’re slow, only make sense in ‘grid mode’ and don’t help you find anything you don’t already roughly know the location of.

At least though, that’s a relatively sane way of finding files. Cover-flow in Finder is just slow and silly, although Finder in general is much better. I daren’t even go near Spotlight, fearing that I might accidentally send share prices in CPU fan and RAM manufacturers soaring.

Whilst we’re at it, can I just mention the integrated firewall isn’t a firewall apparently, so unless you’re comfortable with ipfw, you’re about as open as it’s possible to be.

I am not however a typical OS X user. I am a developer who approaches OS X as a Unix with a better GUI than X + your choice of window manager. Some people will be happy with Leopard, and won’t want the stability or flexibility I need. Many switching from Windows will find the random, sporadic instability perfectly normal behaviour. I do not.

For all my problems with Unix as a desktop in the past, after nearly 3 years away from that flock, Leopard has convinced me to start moving back to Open Source. This weekend I’m going to Bootcamp up and put a “proper” Unix on like FreeBSD or a GNU/Linux distro like Ubuntu. That will allow me to slowly transition my data and working environment over and keep OS X (and Windows w/parallels) available for development and testing work.

I’m sorry Apple, this time you blew it, and you blew it hard. I hoped Leopard was meant to be more than an eye-candy release, but ultimately it’s just worse than any other version of OS X. I’d recommend Panther over Leopard right now, never mind Tiger.

Yesterday I ordered a copy of iWork ‘08 from the Apple website. I got an order confirmation in my inbox by 12:23 estimating delivery sometime ‘on or before the 13th’. When I got shipping notification late last night it had become ‘on or before the 10th’. I had it in my hand, delivered by UPS, in time to play with it whilst eating my Cornflakes this morning.

First impressions are never really very useful, but some of the things they’ve done in Numbers are quite nice.

For example, whilst in Excel you have multiple sheets and each sheet has one huge grid/table, with Numbers you can have multiple tables per sheet. That means that you can move inter-acting grids around and keep them self-contained, put bar charts and graphics next to data, and so on. It’s subtle, but makes more sense than one ‘big grid’.

You also don’t need to remember that the C column is Quantity and the D column is Unit Price and you’re on row 6 – if the header of the columns are set to the right titles, you can simply type ‘Quantity*Unit Price’ in a cell and it “just works”.

They’ve realised that most people use spreadsheets as single-table databases and have made it as simple as possible to do that. They don’t expect it to be a fully-functional Excel replacement for the kind of person who uses Excel because they don’t know how to use SQL, but for 99% of use cases out there, Numbers shapes up to be a fair bit easier to use than Excel and for the SME is good fit. More templates might be nice, but not a deal-breaker.

Keynote has features for interactive presentations that mean it becomes much simpler to provide interactive brochures – basically, you can embed hyperlinks to slides, web pages or e-mail addresses within the presentation itself. It has also borrowed some of the image editing functionality from iPhoto so that within Keynote you can muck around with graphics: given the trend within the Apple and Web Design community for much more visual presentations (no bullet points allowed) this seems like a great direction to take it. I’m not quite convinced by the ability to add Web 2.0-style reflections, but time will tell…

Within Pages, the interface has had a tweak to make it feel more compact and they’ve supposedly made it easier to separate word processing from page layout, but at first glance I can’t see the major difference just yet. Change tracking and Address Book mail merge are items I don’t recall from previous versions and they might be quite useful in some contexts.

I intend to play with it all over the next week and update my invoices, proposal templates and presentation templates to the newer versions and work out what I can do with the new features that is of any real value. If I find anything uber-cool and innovative that hasn’t been mentioned yet, I’m sure I’ll be updating stuff here.

In the meantime, if you want to see what you can get up to, Apple have placed all their iWork tutorials online

There is no doubt that 37signals have had a deep effect on the web development community. Most people didn’t wake up to their antics until relatively recently, but the truth is that they’ve been dishing out design tips and hacks on their Signal vs. Noise blog for a while now. In the last couple of years though, things have become a little… ‘funky’.

First, there was Basecamp a.k.a. the ‘anti-MS Project’ for project management. It was cute, handy, useful and for the market it was designed for (web designers) almost perfect. From that, they extracted the undercarriage and realised they had a framework for not just producing project management applications, but almost any web application – Ruby on Rails – which has gone on to be one of the biggest growing development frameworks on the planet. Vagueware (as in, me) now codes exclusively in Ruby and specialises in Rails development.

The products kept on rolling out – Ta-da, Backpack, Writeboard, Campfire – and the fandom got more and more intense. As a result there are now people known simply as ’37signals fanboys’ because no matter what the guys produce, there is a queue of people ready to hand over the cash. Sometimes people asked what the hell was the fuss about. Writeboard, is after all, nothing more than a text box with version control.

As a result of all this attention, expectations for their first venture into online book publishing as a company were a little mixed. Some people were thinking ‘same old stuff, re-hashed’ whilst the fans… well, let’s just say they were ready to replace various holy texts with copies.

You won’t find Getting Real in any bookshop. It’s available online-only as a downloadable PDF. Every copy watermarked with a ‘Specially prepared for (your name here)’ at the bottom of every page. This is an unusual way to enter the mainstream book market, but as their July 20 update shows, a more than profitable one.

So is it worth the $19 to buy? Well, I bought a copy ages ago, skim-read it, and didn’t get a chance to sit down and give it a thorough reading until this last weekend. I thought as I had finally given it some love, to share what I found.

First things first – there are 16 sections, each having between two to nine chapters, with an average of about seven or eight. Each chapter is quite light, and generally tends to expand a little on the title. As a result you could, in theory, just read the list of chapter titles and get a good idea of the best ideas from the book. Most chapters are less than two full pages long, and include quotes from Kathy Sierra and Seth Godin, so the real ‘meat’ is in the concepts, not in the writing.

In fact, I am reminded here of a part of Zen and the Art of Motorcycle Maintenance where the principal character describes reading with his son. He suggests reading a sentence – just one – and then stopping and thinking about it. Talking about it. Dissecting, pulling, morphing it. At the end of it all, decide how you feel about it and then move onto the next sentence. After you’ve read that sentence, stop, and analyse that as you did the previous one.

I tried reading like this once and it was an extraordinarily hard process, however I got a real insight into the material I hadn’t thought possible before. If I’m honest, if you look at the list of chapter headings, do the above, and you’re probably going to be able to get the core concepts down in your head without spending $19. That said, that’s an option for the poor – it’s not a lot of money, and the lazy would do best to save their mental energy and just shell out for the book.

Project management theories are all alike in one sense: they are codified common sense. PRINCE2 is basically a book that could be re-titled “Common Sense for Idiots” whilst agile is a way of letting developers work their own way whilst keeping management happy – mainly because management don’t think programmers have any sense whatsoever.

Getting Real is no different in this respect. It’s an “Agile-light” that concentrates on user experience above all else. However, it also stretches the boundaries of project management and touches on how to run a web product company in general. Sections that wouldn’t normally belong in a straight PM book include staffing, pricing and signup strategy, and how to keep customers happy would not belong in a traditional book on development methods.

It is also a book that is not meant to teach, but rather help you evangelise. It comes in a site license version (which at $49 is quite reasonable) so that you may spread the word amongst your team and help get the company on the same page. And that’s what this book is about – getting your team pulled together and heading in the same direction.

Project methodologies often concentrate on how best to document a project and how best to present that documentation within the team so that all concepts are clearly understood. Getting Real sets fire to that concept and suggests there is only one thing the business needs to worry about at any point in time: code that does what the customer expects.

To get a team to the point where they no longer need the traditional software lifecycle can take time and energy, and in many ways Getting Real can help short-circuit that. Reading it through with real-life examples can help convince you and your team that it’s at least worth a go – and that’s the biggest obstacle in changing any working style.

Some of the concepts do feel a little strange in places. For example, they suggest you should always have three people on the team: one developer, one designer, one person who can straddle both. This is just arbitrary and doesn’t make much sense. One programmer with design skills (or the money to get some if he can’t use OSWD or similar) could easily pull a project together with hard work – I should know – and a programmer with a designer on their own could easily do it. Where the third person steps in, I don’t know, or why it would be so dangerous to have four people, I’m not sure, but I’m guessing this ‘three person’ set up is just the way 37signals handled things themselves internally.

Their staffing advice is also a little strange. How can you assess a designer based on a week’s work? I’d rather assess them on a lifetime of work. Same with a programmer, if I’m honest. I also understand the point they make in saying that good wordsmiths will be better communicators, but only if the primary form of commuication is written – if you’re spending most of your time coding in ‘alone time’ and it’s the pub conversations where the real team collaboration is worked out, the fact they can write in iambic pentameter isn’t going to help you one jot. I’d say: hire people who fit, regardless of wordsmith skills.

The overall push with this book is one of getting something out of the door as quickly as possible. Interestingly it suggests we develop simple solutions that work well instead of complex solutions that are in perpetual beta, and in this I find myself in wholesale agreement. We live in an age of Web 2.0 where getting anything that feels as though it might impress out of the door is seen as a greater acheivement than getting the right thing – just enough to get customers using the product and being surprised by it – out of the door.

Overall it’s a pleasant read, inspiring in places, and has practical knowledge that beginners could make use of if they’ve never worked on a software team before. For those of us who might be considered ‘old hands’ by now, I’d say it’s an interesting twist on how to get over the procrastination of starting your own software product line, and I intend to make use of a lot of the advice – but not all of it.

That said, you need everybody in your team to be signed up to it for it to work, and it will take time for people to adjust. For example, last week I had a discussion with somebody on a project who had read this book and wanted to work in the Getting Real style, but had to be held back from drawing an entity-relationship diagram as the first stage. It would seem that old habits die hard, and despite all the good intentions of Getting Real, might take some time to overcome even with the converts.

I’ve been a fan of Seth Godin for a couple of years, ever since I realised that if I was going to run my own business there was a whole bunch of skills I needed to pick up that spending my teenage years in front of a compiler didn’t prepare me for. Like, for example, marketing.

Seth is by no means unheard of, his name is now quite famous within marketing circles and he is definitely one of the few marketing geeks who the blogging crowd think “gets” what the Web is about. As a result, his books get widely read, widely commented on, and if you interested in the web as a marketing tool – and I’m talking blogs and user engagement here, not spamming – you should get familiar with his work.

Free Prize Inside is not a new book. It’s been published and in circulation since May 2004. So why am I reviewing it now? Well, because I only got around to reading it last weekend. :-)

As with nearly all business books, the amount of original thinking you’ll find in FPI depends on how widely read you are, how imaginative you are yourself, and how exposed you are to methods of innovative thinking as part of your daily work life. I can’t imagine many businesses embody innovation to the extent that I, or Seth Godin, would suggest it should be, but if you work for an ad agency you might find some of the content of this volume a little ‘beginner level’.

The core of Seth’s thesis is that soft innovation is an easier sell for everybody – your colleagues as much as your customers – compared to ‘hard’ innovation/blue-sky thinking. I’ve covered before how I think about innovation – push edges and boundaries, it’s quicker and easier and more productive – but what was startling when reading Free Prize Inside was that he had managed to put the time and effort into synthesising it into a series of basic tools.

The value for me in this book is this simple reduction to basic steps things I’ve always known – i.e. I now have a vocabulary I can share that explains what I’m talking about.

For example, the ‘fulcrum of innovation’ is basically a fancy way of asking yourself three questions before you take an innovation to colleagues, in order to determine how likely it is they’re going to support you:

• Is it going to work?
• Is it worth doing?
• Are you the one to get it done?

These are of course the questions running through people’s heads when you take them through any new idea you want to put in place, and by thinking through how to get a ‘yes’ to every one of those questions, you’re going to be in a better position to pitch your idea. You might be wrong, but at least you’ll have gone through a methodology before you start trying to pitch your idea. A simple technique, but worth learning.

In fact, pitching your idea is such an important aspect of innovation, Seth actually suggests you work out how to sell your idea before you actually come up with it. Selling your idea, he claims, is as important a step in making it happen as coming up with the idea itself. If you come up with an idea that isn’t going to work, isn’t worth doing, or nobody thinks you can do, there’s no point in trying to develop it past the scribble you just made on your whiteboard or notebook.

This is sensible advice, but I’m concerned this is going to stifle those people for whom self-doubt is the modus operandi of thought. Convinced that they can’t have an idea colleagues will think they can execute, they will refuse to actually try and create an idea at all.

That said, Seth’s methods of ‘edgecrafting’ (or as I called it in the past “evolutionary innovation”) lowers the barrier of resistance by allowing people to easily see how to improve a product so as to create an excitement in the customer. Seth specifically looks to try and give every customer a “free prize” or a bonus that they weren’t expecting. In actual fact, this isn’t about shoving a free plastic toy inside the box (well, not always), but rather is about finding the edge/boundary that you can push a product to. Doing more, doing less, treating people the same, treating people equally, whatever it is, find an edge and push your product there in a way your sector isn’t used to.

He also suggests brainstorming is the wrong way to innovate, but for different reasons I think it’s useless. He claims that within a group it’s too hard to get people to speak up and contribute ideas for fear of ridicule or that they’ll be asked to actually do some work. Instead, he claims, if you ask people to work individually on a problem the results will be better. I think the flaw with brainstorming is that you end up asking people to do the impossible: start with a blank piece of paper and re-invent from scratch. If instead you were to give people a set of constraints and asked them to push them around, it’s still perfectly possible in my opinion to come up with quality ideas as a team.

In general the book is filled with clever techniques, but I’m not sure whether it’s because I’ve read so much of Godin’s other work – and work by others – in recent years that it doesn’t feel particularly remarkable or original any more. That said, if you are struggling with innovation and how to make it happen within your own workplace, it’s an affordable shot in the arm that should get the creative juices flowing.