The 6 Critical Software Principles

Through my work as a software development consultant, I’ve defined a guiding set of principles that I advocate on any new projects. These have been forged from past observations, experiences and mistakes. They aren’t original or groundbreaking, but it’s surprising how often they are ignored!

The principles are:

  • Get regular feedback from users
  • Keep it simple
  • Minimise dependencies
  • Use open standards where possible (including dependent systems)
  • Think ‘Production Ready’ from the start
  • Don’t reinvent the wheel

ONE – Get regular feedback from users

Users are at the heart of all decisions and the highest value requirements should always be driven by user needs. I recommend spending a lot of time researching your users, speaking with them, and shadowing the work they currently do.

I place great value on the use of mock-ups, prototypes and proof-of-concepts because these really help users get engaged,  visualise, and (most importantly) challenge preconceptions.

I prefer to be involved on projects using an agile, lean delivery methodology that promotes regular communication with stakeholders. Through regular (at least bi-monthly) releases of working software, feedback comes quickly which is always better than slow or no feedback!

TWO – Keep it simple

I’m all for the latest technical design principles, practices & patterns. However a lot of systems are over-engineered to ‘tick all the boxes’ of so-called Enterprise Grade Systems. We believe that systems should be designed as simple as possible – not for the future, not for changes that may never happen – but for right now, to meet the user needs that have necessitated the project in the first place. Complex systems tend to become a hindrance rather than a help, because they become too complicated to change over a period of time and the business becomes less nimble as a result. Plus they’re more expensive to develop.

I find that most people don’t care about the code that powers their software (they leave that to the geeks like me). But size and readability of a custom product’s code-base are very important. So I always take create care to keep things simple. My code is always available for review and I actively encourage people to find issues so it can be improved and learnt from.

‘Keeping it simple’ is an important mantra of mine. A piece of code that solves a problem in a simple but elegant way is not only a thing of beauty (honestly), but also an indicator of true quality of a system.

THREE – Minimise dependencies

A typical enterprise organisation has multiple systems, of varying ages and technologies. Any enterprise system will have integrations with all manner of nasty systems…the trick is to minimise the dependencies between such systems.

This has 2 benefits – firstly you do not become dependent on any one system. This is commonly called ‘throttling’ – a technique that allows you to rely less on the systems that need replacing the most…until one day you do replace them and hardly anyone notices.

Secondly, minimising dependencies increases resilience. If a back-end system goes down, ideally it should not affect your customer-facing applications. If your order processing system blows up, customers should still be able to submit orders until it gets fixed.

FOUR – Use open standards

Open standards maximise compatibility between systems. This enables a flexible system design that can evolve over time. It also reduces the risk of lock-in to suppliers. Those peddling proprietary technology should be discounted altogether unless there are no alternatives.

So what constitutes a good open standard? Something that is freely and publicly available under royalty-free terms. It should be ubiquitous and have a big presence on the web, a lively user community and widespread adoption. The Open Source Initiative has published a useful set of criteria1 if you need more of a definition.

Make sure you consider the following when evaluating any off-the-shelf solutions:

  • Interoperability – How can data be shared with other applications?
  • Interface – What different ways can data be queried?
  • Format – Is data stored in a non-proprietary format?

And ideally ask for documentation on their API’s, because even open standards will not save you if the documentation (or support) is poor.

FIVE – Think ‘Production Ready’ from the start

Software projects tend to focus on the functional requirements that help your software pass quality assurance (QA). But ‘feature complete’ is totally different to
‘production ready’. This principle dictates that you build software for operation, not to pass QA.

I can’t produce any better advice than already given in Michael Nygard’s excellent book ‘Release It!’3. I certainly try and follow all the advice in this excellent publication.

The main aspects that commonly get missed when designing & building systems are stability, capacity and transparency.

Stability means realising how small errors can cause entire applications to fail and what can be done to mitigate the spread of such failures. It also means buying into the concept that at some point parts of your system WILL fail, and you need to be ready. NetFlix4 are famous for deliberately sabotaging their live system from time to time, to force them to build their service in a resilient way!

Capacity means making sure your system can cope with a production-level load. As a bare minimum you should be running performance tests as early in the development lifecycle as possible. Also don’t just consider ‘nice users’. If your system is accessible over the web (e.g. a customer-facing retail web site) then you’ll be plagued with automated bots and screen scrapers as well as standard user-based traffic.

Transparency means exposing the inner-workings of your system, so you can diagnose any issues quickly and easily. Functionality such as logging and detailed monitoring of both application and servers should (again) be considered early in the lifecycle, instead of shoe-horning it in at the end.

Making your system ‘production-ready’ from the start means that you won’t have any nasty suprises when it does go live, and you can sleep much easier at night.

SIX – Don’t reinvent the wheel

Why build something when it exists already, battle-proven and ready to go?

The amount and quality of free, open source software is amazing. You should always consider existing open-source solutions before electing to purchase commercial or develop in-house.

For example for Content Management Systems there are excellent open source solutions in Umbraco, Drupal or WordPress. For enterprise-standard databases you have for example PostgreSQL (or MongoDB if you go the NoSQL route). Linux (operating system) has open source flavours (CentOS, Ubuntu etc) and then you have a wide array of development frameworks such as .NET Core, Java, Node.js and Ruby.

If you do go the open-source route (and it’s perfectly normal to mix open source with commercial too) make sure you choose technologies that are ubiquitous and have a passionate user community.

Although I earn a living from developing bespoke software, I only advocate it where the business case is unique. If the problem has already been solved, then why do it all over again?

Do you agree with my principles? Are there any missing? I’d be really interested to hear any feedback you may have.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s