Software isn't complicated

Humans make software

Humans make software and humans make it complicated but it really doesn't have to be. Embracing constraints can be a wonderful tool to building simple, easy to run and supported software.

Without bubble wrap

I am here to give you facts and knowledge, not tell you what you want to hear. We won't always agree, and that's okay. It's important to recognise when to disagree and get on with the job.

Build what matters

Build features that solve real problems, not the ones nobody asked for. If you want something later, build it later. The same is true for data; unless you need it now, don't store it now. Nice to haves, visions, predictions are all guesswork. Eliminate guesses.

Run great code without the fancy hardware

Good software should run on modest machinery. Don't let hardware compensate for poor performance; you will increase costs and reduce your flexibility. Optimise your code instead. Engineer for the highest performance at the cheapest cost.

Avoid the details

The details of a product make a great product, but it's also where you're most likely to get stuck. If you find yourself arranging a meeting or getting into a disagreement over a feature or a detail, you're probably focusing on an area where it doesn't matter.

Ship quicker

Software isn't static; it is dynamic, moves, and requires feeding and attention. People can get stuck in the mindset of "it's got to be perfect". It doesn't. Aim for progress over perfection.

Build slower

Building software too quickly increases cost and eventually reduces productivity. The quicker you build, the more bugs and fragility are introduced because less time is spent architecting the best solution. This means more time is spent on fixing problems, and productivity declines. Build slower, think more. If you must, build less. Fix the time and reduce the features.

Say no

Saying no ends the discussion. Saying yes means saying yes to long-term commitment, support, development, and investment. Sometimes, saying no is just the better option.

Avoid the big client trap

They're a huge client, and they pay a lot. Businesses don't often grow stronger from big clients; they grow weaker. Your big client drains and diverts resources away from the smaller clients, making the smaller clients seem less significant.

Are you building the best product?

Are you building the best product you can because you want to solve a problem, or is your hope to sell to someone? There is a difference, and while both are valid tactics, if you and your team are not clear, you'll run into issues.

You don't control your product

You think you control your product, but you don't. The sooner you realise that, the sooner you can start building a great product. Your customers tell you what they want, and you need to listen. Sure, you shouldn't take on feature creep or build everything your customers want, but the obvious things will make themselves known.

Do the right thing

Sometimes, you don't want to do what you should, so you'll have to make a call you don't want to make. Do it early and quickly. You wouldn't delay a root canal.

The cloud is a tool, not a platform

I am a big cloud advocate, and I've supported many clients on AWS. But they all needed it. I've supported many more that just needed a dedicated server, a fixed cost. If you don't need cloud features, why be there?

AI isn't always the answer

AI isn't a magical unicorn. It's a tool. If the use case isn't apparent, shoehorning it into your business weakens it. It s expensive and prone to errors. But it does have its place. AI can be helpful for suggestions and offering hints, but asking it to make decisions is risky.