me.andering – Willem van den Ende

I’m live blogging from the uk government IT meeting on agile at the SPA conference. Nothing beats a blogpost fired off in anger

Here are some tweets I would like to elaborate on:

Me: “Offshoring government it is stupid”

Eric Lefevre (@elefevre): “why? on paper, if there is any way to commoditize software for government, it would sound like a win, wouldn’t it?”

Me: “Software is executable knowledge. Offshoring software is giving a potential enemy exclusive posession of that knowledge.”

Imagine, if you will, the UK code breakers in the 1920’s outsourcing some of their work to Germany, because labour there in the crisis after the first world war was cheap. Manual computations, but nevertheless. What would have happened by 1938?

This is a bit of a straw man of course. However, the problem with outsourcing and/or offshoring is that you put executable knowledge, plus the expertise to grow that knowledge and build knew software from it in the hands of one party. That leads to a dependency on that party. As long as things go fine, that is swell. When things go bad, not so much.

If you think that documentation is going to help. It might, if you are lucky. Most of the knowledge that goes into software is tacit, and very difficult and costly to transfer.

So if you are a government agency (or a company for that matter), don’t be stupid. Keep some good technical people on permanent staff, who know how your crucial systems work, and can make modifications. If you add some external staff to that to be flexible in capacity or bring in specialist knowledge, great!

Just don’t forget to let them work side by side with your permanent staff on a daily basis, so your organisation does not leak knowledge that it can’t recover on its own.

Just remember, knowledge is power. If you’re not careful, you will learn that lesson the hard way.

Have you ever thought about the Maximum Marketable Featureset for your product? You may be familiar with a Minimum Marketable Featureset, which is the minimal set of features where someone wants to buy your product.

The underlying assumption is that adding more features after the minimal set will make your product more valuable.

At some point adding features makes a product less valuable to users. Less features are easier to understand for users and for developers, which in turn can help improve the value of each feature.

So next time you build a product, think about it. When will more features diminish the value of your product to its users? Why not on your current one? Are you there yet? How far still to go? Past the point already? Could I make this post more valuable by asking less questions or using fewer words?