Some Thoughts on How to Commission Software

In the over two decades I have spent developing software for customers, I’ve taken note of a number of pitfalls and blockers to success when it comes to how we interact, and the expectations brought by them.

During that time, I have encountered the spectrum of experience when it comes to those commissioning new software - from the inexperienced with a great idea but no idea where to start, to the ultra-experienced entrepreneur on their fifth venture.

Condensing all of the lessons I have learned, as well as insights and observations, into a single blog post is rather an impossible task, but nevertheless I shall try; I have no doubt that as soon as I hit publish I will get several more thoughts that I feel I’ve missed - but such is the world of software development!

So, in no particular order, here are some thoughts to help you get the best out of commissioning your own custom solution.

Have a clear vision

This does seem like a bit of a no-brainer to begin, but ultimately having a clear vision for what you want to achieve with a software build will help guide the rest of the process, and help you keep focused on the important parts of your vision. You’ll find a lot of “side quests” along the way - tangents that seem like a good idea at the time, but ultimately end up distracting you from your purpose.

Software development - as with any business venture - is often littered with dead ends, “pivots” and lost opportunities. You’ll face any number of temptations along the way: aspects you hadn’t considered, sales that need custom work to get over the line, new shiny ideas that are kind of related to what you’re doing.

Having that clarity of vision - keeping a “north star” - allows you to validate these potential new paths against your core goals, as well as help you prioritize new work when it competes with the long-planned but as-yet not started tasks.

Deciding what is most important to you and your vision will also help you and your developers deliver value more quickly. Oftentimes the most important part of a software project is the initial launch - the sooner you get your product out there, the sooner you can understand its impact and reception. So deciding the most valuable aspects of your vision - do you want to prioritize revenue or users? - will help you to understand what to deliver first, and what can come later, once initial goals are met.

Embrace Minimum Viable Product

Having a solid vision is one thing, but where do you start?

You’ll hear a lot about “Minimum Viable Product” = probably too much - but it’s an incredibly useful concept to get to market quickly and test your assumptions. Oftentimes we spend so long trying to perfect our work that we spend countless more hours and money on it than necessary to get some value out of it. Or we dismiss relatively inexpensive solutions - business processes - for more complex technological solutions that, while effective, are probably over-engineered for the size of your existing business.

On top of this, software works best when we develop it from a stable foundation; we iterate on previous versions. This is great and all, but at some points you need to lay the first pieces out, without anything to build on. MVP helps us to keep our eyes on the prize, and establish that first foothold in delivering our vision.

I know this stage can be very tough, especially with the vision you’ve cultivated so strong and fresh in your mind, but as the saying goes “Mighty oaks from acorns grow.”

Communicate Early and Often

One of the biggest challenges in software development is communication.

It starts right at the beginning. As with any creative and technical workers, engineers are trying to deliver what they think you’re asking for. We have to reduce the requirements and specifications provided to us, and create a machine that is suitable to meet those. When we are only given a sketch, then we have to fill in the blanks with our own interpretation of what is wanted - and that’s before we take into account the numerous assumptions that we have to make when transferring from something nebulous and, well, analog to digital certainty.

We have to consider edge cases, failure modes, recovery, scalability, maintainability… details that plenty of customers just don’t build into their vision when passing it to us. And all of this is assuming that the vision has been communicated effectively to start. In order to facilitate this process, we either bring in a software architect or put the hat on ourselves; we have product managers and business analysts - people who can help talk to customers and interpret their wants and needs into specifications that are precise and clear.

But while these extra - and costly! - people are invariably helpful and conducive to a build, they are no real substitute for great communication with a customer. The best engineers will establish a rapport with those they are constructing for - partly because they develop empathy for their customers, and partly so they can ask “Why?” Such a small word, but the most powerful one we have in our toolkit - we can challenge those assumptions, we can separate needs from pre-conceived ideas of meeting them, and offer new ideas (often simpler, at least to start!)

Establishing a cadence of regular communication is also key to this - regular meetings to encourage collaboration and communication. While software engineers will be used to “stand ups” - short, daily meetings where progress, intention and challenges are highlighted to the team. Unless you’re working directly with the engineers, having hired/contracted them directly, I’m not suggesting that you do a daily call, but weekly meetings with product managers or lead engineers would work very well so you can gauge progress yourself without overwhelming the coders with requests.

This then allows you to help guide the project without being too hands-on, as well as make sure that there are “official” touchpoints for engineers to talk to you. It’s not about keeping comms to this one moment in time (although that’s a nice side-product for some engineering teams with over-zealous customers), but about providing a structure within which to work.

Manage your expectations

My final thought for today is more of a plea for understanding!

As hinted at earlier, software development can be a long process with a number of false starts, dead ends and cascading decisions. When we write code, we make our assumptions explicit, and we tell computers to make decisions based on information input into them. Each decision can be followed by more decisions; each time a decision is made after a previous one that doubles the number of “paths” through the code.

As a result, bugs are inevitable. There are ways to mitigate their impact and reduce their number, but these take time to implement and therefore cost more money. You might be tempted, as the purse-holder, to ask that these steps are skipped, but that is your prerogative and you must accept that you are adopting that risk. Oftentimes, this is an unwise choice as the earlier bugs are introduced into complex systems, the harder they are to rectify down the line when discovered. And they will be discovered, even if it’s years later.

Programming is an artistic as well as technical endeavor, and requires skilled practitioners in most cases to transform your needs into action. As such, the whole process takes time, and generally more than the layperson expects. So, while you do need to hold your provider to account when they set time expectations with you, please be aware that projects often slip, not only due to human factors such as illness and other delays, but also due to the need to codify your requirements into something that works, and works well.

Communicating early and often, as described above, helps in this regard, but also make sure that you work with the development team to get eyes on their work as soon as possible, with the proviso that you know it will not be ready for use just yet. Your feedback will always be valuable, but being laser-focused on detail before the coders are ready to receive that input will delay your project as a whole by polishing less important pieces at the cost of developing other more valuable pieces in broader strokes.

Your software should develop like a JPEG on a slow internet connection - whole but blurry at first, then the detail loads in.

The Last Word

I really hope this provides some food for thought - it’s been really tough to take such a broad topic and pick just a few points. This could well have been a novel rather than a pamphlet, but… baby steps!

Hopefully we can revisit this topic in future with more thoughts and advice; if you have anything you’d like me to expand upon, please do let me know by dropping us a line!