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

The Art and Science of Ruby

You know your problem? You do too much…

Comments on this post are for paid subscribers