What I’m listening to as I type this: Dead & Born & Grown
I’ve been putting off writing this post for half a year. Tying my tooth to a slamming door would hurt less.
This post is me saying, finally and publicly, that sweeble is over. My big publishing idea; the web-tech start-up I’ve led since 2008, is kaput. And probably always was.
Even the sign I’ve been driving around for three years is looking weary:
Sweeble was (and I’m pretty certain still would be) the UK’s only web to print self-publishing platform, built so anyone could create their own proper printed newsletters, magazines and booklets. Everything was done online in sweeble; from writing stories, to laying out pages, to ordering printing. More useful than Blurb. I wanted to build a WordPress for print.
Anyway, it turns out it never really worked. Worse its browser dependability meant it never really would work without being rebuilt every couple of months.
In a nutshell, I made three fatal errors.
1. I contracted the wrong developers.
2. I didn’t manage the development process forcefully enough.
3. I got distracted by new stuff instead of being a one-project entrepreneur.
There are other bits I could have done better – like getting more publicity, or focusing on one market channel at a time, but they didn’t kill sweeble, just slowed things down.
And if the funding we were offered had panned out, maybe I’d have been able to pay new developers to build me a stable version of sweeble.
- Your developers are not your friends. You don’t need them to like you.
- Contracts can help you think through the project responsibilities but are largely useless if it goes wrong.
- There are reasons why the thing you want to build doesn’t already exist and one will be that it’s really difficult to build. Expect problems.
- Concentrate on building the simplest, sharpest one-trick pony and don’t waste time and money adding every widget you dream up.
- The first time your developers miss a key deadline, stop the project (and payments) until you understand why and agree next steps.
- The second time they miss a deadline, start looking for other developers. Just in case.
- Have a cut-off point in your head (time and money) when you’d be willing to cut your losses. Don’t keep spending just because you won’t walk away from what you’ve already given.
- Don’t leave project management to the developer team’s manager. Get weekly reports, daily reports if things are going wrong; ask questions and talk to the developers. You’ll never wish you got less involved.
- It isn’t about just getting to beta release, it’s about launching a product lots of users can use without tearing their hair out – just ask MySpace.
- Allow at least one third of build time for field/user testing. You need to be sure the product works when the developers have gone.
Aside from lessons in what to do differently next time (if there is one, I’m still feeling a bit raw), what else have I learned from sweeble’s demise?
This: it’s time there was a registration authority overseeing and regulating the work of software/app developers and engineers.
In the UK we’ve got gazillions of trade bodies and quangos regulating work and standards on behalf of consumers.
There’s somewhere to go if you have a complaint against the bloke who laid your carpet or fitted your double glazing. You can check whether a dentist, solicitor or company director is OK or dodgy. You can get support if the firm that sold you your holiday goes bust or you were miss-sold a pension plan. You can find a certified gas fitter, engineer or electrician.
But you have no way of knowing, other than by word-of-mouth, whether the developer/s you’re about to spend thousands, or millions, of pounds with can do what they’re promising to do.
And, no matter how much you spend on lawyers and the contract, if the developers don’t deliver, you’re pretty much buggered.
Software project failures are difficult to prove in court (is it “goods” or “services”?) You’re looking at a lengthy process involving paying court costs, solicitor and barrister – and even if you win, the developer/s can opt for bankruptcy (or Chapter 11 protection in the US) and not pay you a penny.
It’s like me taking my car to a garage and not being able to do a thing about it if the mechanic decides square wheels would work better than the round ones I wanted.
There are trade bodies for software engineers and developers but these are member-centered – serving the interests of the developer, not his or her customer. There are no codes, standards or regulations that can tell me, the buyer, whether I can have any confidence in the supplier’s ability to deliver.
The global software industry is worth around $350bn (Lucintel). The ICT market in the UK alone is worth £140bn and software and IT services make up £58bn of that. For comparison, that’s almost three times what we spent in the UK on getting our cars fixed.
My point being that this is a big and growing industry on which other businesses are increasingly dependent for their own growth, so why is it unstandardised and unregulated?
We celebrate the scale of spend in the software industry but ignore the billions lost on sub-standard work or delayed delivery.
When the NHS scraps a £12bn software project that “never worked”, we blame the customer not the supplier. ComputerWorld’s ten biggest software failures in 2011 demonstrates even New York City and Idaho can’t get back the hundreds of millions of dollars the authorities lost on failed software projects.
We’ve known, even before Brooks’ seminal Mythical Man Month that most software projects go wrong because of poor project management but we continue to believe that can be corrected with a contract and sharing Excel reports. We need help to get what we’re paying for.
My losses were in the tens of thousands rather than the millions, but it isn’t the money that matters, it’s having to draw a line under a good idea that should have worked. That really hurts.