Posted on

The story behind EchoDek’s 7 day software

The trouble with getting a software project built is that they’re always late and they always go over budget.

Wouldn’t it be great if you could be sure that what you were getting was what you asked for and it was going to be delivered on time?

After 20 years working as a commercial software developer, I hit a rough point with an existing client whose project I had been working on for three years. We both knew why the system wasn’t working as it should (3rd parties involved with blame all round) and I wanted them to rewrite the whole thing; they were scared about the cost and potential for overruns, given the amount that they had already sunk into the project.

So I said “let me take Feature X and I’ll rebuild it in a week”. They agreed – because a week’s worth of work is practically no risk for them. I stripped the feature down to its pure essentials and by the next Monday they had something they could take to their customers and start selling. They immediately bought a second week to add some niceties and finishing touches to the administration side of things.

Since then I’ve followed the same pattern on other work that’s come my way – find out which part of the project will actually make money and concentrate on specifying, building and shipping that; no frills, no niceties, just the essential feature to get the job done.

It’s better for me and the developers, as we get to work on well-specified projects with a fixed scope but more importantly it’s low risk for the customer; they know what they are getting, what it’s going to cost and when it’s going to be delivered.

And so I thought I’d launch it as a standalone service.

Presenting 7-day Software from EchoDek
On-spec, on-budget and on-time.

Get free advice and tips on using IT to reduce your costs and increase your revenue – sign up here

Posted on

You know your problem? You do too much…

I’ve been a professional software developer for twenty years now.

There’s been one idea I’ve been reading about for about fifteen of those years, but it’s only in the last couple that it’s really come home to me how important it is.

And it’s really, really simple.

How can you make it smaller?

The feature that the client is asking for … what can you take away?

Does it look like a complex piece of work? Well, which pieces can we leave out?

Does it reduce the client’s costs? No? Then get rid.

Does it earn the client more money? No? Then drop it.

An example: we had an issue where we found a loophole in a piece of software – the customer could pay for a piece of work, use it, then cancel the work and they would be refunded their cost – even though they had already made use of it.

The client proposed a series of changes; notifications during use, tracking what the customer was doing, logs of exact times and usage levels.

I said “how about … we don’t let them cancel their own projects?”

The desired end result was to make sure that they didn’t get refunded for work they should have paid for.

The root cause was that if they cancelled the work we had no log of what they had actually used.

Instead of treating the symptom, we dealt with the cause. And suddenly, two weeks of work was reduced to less than an hour. A deadline that we were going to miss became easily achievable.

So, whenever a client proposes something, just think “what’s the problem here? And what’s the simplest solution to it?”

And how can I make it smaller?

Get free advice and tips on using IT to reduce your costs and increase your revenue – sign up here