In my early days as a software engineer, back in 1988, this book (“Principles of Software Engineering Management” by Tom Gilb) was my bible.

We’d just acquired a new client, who’d been told that the networked point of sale software they’d just ordered would be ready in 3 months.

The trouble was, what they’d seen was a mock-up. We hadn’t even begun to think about designing or building it.

So, having found this new book a few weeks earlier, I decided to follow its principles.

Having mapped out a high-level architecture for the system, we put ourselves in the shoes of the customer – a large department store – to work out which elements we should deliver first.

Next we worked out which parts of the standard software development approach we could ditch, without compromising maintainability (I learned to code with the MOD, so maintainability was key).

Having stripped our development process back to just what would support the things we really cared about – software that did what the customer wanted reliably, delivered in business-useful chunks and in code that could and would be easily maintained in future – we were rigorous in sticking to it.

Everything else was low-tech and informal. We were a small team in one room with a whiteboard, and could communicate well enough to keep things on track and under control.

We were helped by a fantastic boss, who believed in us, and defended us from the traditionalists outside our team.

It worked. We didn’t deliver the whole system in 3 months, but the client was more than happy.

They got what they needed when they needed it. As they populated products, we built the departments piece, and so on, each delivery fully tested and working properly, building on the previous one until the system was complete.

And we were the first to market with this kind of product.

The point of this little nostalgia trip?

The right level of discipline makes daring possible.