We think software is soft, but that isn’t always true.

I was speaking recently to a friend with a large system he was struggling to scale. I was saying while the Guardian does have to spend tangible time (and sometimes money) to ensure its systems scale, we do tend to deal with the issues successfully. But that wasn’t his experience, to the extent he was considering tearing his system down and starting again.

We often think we can reconfigure and rework software, to adapt it to new circumstances. And often we’re correct. This is even the essence of agile development: get something useful out there, learn, and make it better.

But we need to think slightly differently when we’re dealing with proprietary software, as was at the heart of my friend’s system. It may be configurable, but it’s never as malleable as something open source or self-made. We’ll be working with the soft squishy stuff, then suddenly come to a hard black box which won’t flex. It’s like finding a piece of Lego while rolling out a ball of plasticine.

So there are different risks around using proprietary systems compared to more open ones. Proprietary systems allow us to do some things faster, and other things not at all. This doesn’t mean we should avoid them but it does mean we need to manage our projects accordingly. Activities need to be prioritised accordingly, and that may involve addressing earlier potential requirements which would lead to impossible changes. Thus it can have implications for project planning and (if it may mean changing our business-level expectations) governance.