An experience very early in my career taught me a very valuable lesson about software development.

This was in the mid-aughts (2005 maybe?) and the existing reporting was using Lotus 1-2-3. Lotus 1-2-3. So it needed to go. We had to decide if we should build a totally new analytics suite or utilize the one we already had.

We were funded, but picking a technology path was more complicated than it sounds. This project was for our Canadian offices, and there was more than a little resistance to simply taking what we had and using it. The initial US implementation hadn’t gone well, so the reputation of the system I supported wasn’t great.

But it was reasonably good. A really important feature was that it worked. It cranked out reports. The calculations were correct. It had ways to get all of the data it needed. And it ran in a database, not a series of macros on Lotus 1-2-3. It had a team to support it, not one guy who was close to retiring.

So once we got the go-ahead to begin, we had to pick: start from scratch, or re-purpose the American system for the Canadians. We had to do a long series of cost benefit analyses, including feature comparisons.

About those feature comparisons: the new software didn’t exist, so it could do anything. Any feature the new suite needed, automatically existed, because it could be built. For example, if we said the existing system was slow, the designer would just put “Amazing performance” as a feature in the unbuilt thing. And who would disagree? He wasn’t wrong, because it was vaporware.

Software that merely exists as a PowerPoint deck will never have performance issues, or weird UI annoyances, or installation problems. But an existing system will, which makes true comparisons impossible.

The committee was clearly leaning towards starting over rather than use what was working. And this made me realize: Sofware that hasn’t been built can do anything.

Thus Sobolak’s First Law of Software was born.

Eventually the team go the go-ahead to build a brand new reporting solution. I was part of the team, and was responsible for making it a success. It failed dramatically – we build something that eventually shipped but it did 1/10th of what was already in production after months of hard work.

And it really never replaced the Lotus 1-2-3 macros. That didn’t happen for years. I had already moved on and they just bought something; everything was replaced.

I’m sure whatever they bought promised many great things before it was installed too.

It’s always easy to imagine great features and new problems when gathering requirements, and hard to go through the work to build something as great as it exists in the designer’s imagination. When looking at new things (esp. when considering buy vs build), this is a really important countenance to the perceived ‘shortcomings’ of something that actually exists. Software that hasn’t been built can do anything, so it’s critical to imagine what will fail or suck in the future, because something will.