article

Building business software - 21 keys to success

Why you need a great software development team

10 mins read

I know, 21 is a lot of keys. Building successful custom business software is extremely complex, don't let anyone tell you different.

I imagine some of these points will resonate with you and hopefully some will be new and enlightening.

I believe it's worth bearing them all in mind when considering embarking on a new custom software project. They’re just as applicable whether the team you decide to use is internal or outsourced.

1. Business software should follow business process, not the other way around 💡

Obviously! This is the primary benefit of custom software development.

2. Build what works

Always use operational teams to manually test new processes before attempting software-based process automation.

Once a digital transformation project gets started it's common to want to tweak processes as you automate them. Try to resist using (relatively) expensive software development resource to confirm that processes you imagined would work actually don’t. It's much simpler and cheaper to continue to improve processes once they've been at least partially automated.

Use multi-skilled development teams where multiple individuals have full understanding and there’s no single point of failure

3. Skills ≥ talent

Controversial I realise, I’ll go into a bit more detail on this one...

Where possible, use multi-skilled development teams where multiple individuals have full understanding and there’s no single point of failure.

Ideally, each development team member would have a reasonable understanding of:

project goals
user’s issues
solution architecture
APIs
dependencies
integrations
database/s
back-end
UI
...you get the picture

There are hundreds of decisions that need to be taken throughout the development process. The best results come from individuals understanding the consequences of the decisions they take from top to bottom and having the freedom to challenge each other.

Highly talented individuals working in silos can’t achieve that.

Building a simple system takes a huge amount of thought, understanding and consideration

4. Complicated is easy, simple is harder

The best user interfaces are simple, the same goes for the code, APIs and databases that make them work.

Building a simple system takes a huge amount of thought, understanding and consideration.

Building a complicated one is relatively easy. However, you may find it’s not flexible or scalable, it generates duplicate (or worse, conflicting) data or users simply don’t want to use it.

5. Allow access, at all levels

Replacing existing software takes a willingness to question the status quo and ask why a process, some UI or some data is the way it is. Those on the ground are not always best placed to ask those questions but are often best placed to answer them.

Give your development team the freedom and access to be able to ask those questions of appropriate people. Don’t be afraid to give them access to your employees, partners, customers or suppliers if they will be users of the system. You won’t regret it.

6. Maximum dev, minimum ops

Successful development teams should always be finding, evaluating and embracing new technologies to improve productivity and reduce costs.

For example, the highest performing DevOps practitioners release code over 200 times more frequently than low performers, they’re also over 2,600 times faster to recover from incidents.

Another example, IDC recently predicted worldwide IT spending will decline 2.7% in 2020 due to the impact of COVID-19, it may be more in your industry. Taking advantage of Serverless technologies brings combined benefits of significantly reducing development time (hence cost), and ongoing hosting costs.

You need a team that you can work with not just now but in the future

7. Change is inevitable, embrace it

Software systems, like business processes are never complete, with very few exceptions they can be (and should be), continuously improved. You need a team that you can work with not just now but in the future - the right team may even outlast you as you inevitably get promoted 🤩, or retire 🏖️

8. "A bad workman..." 🛠️

While new technology should be embraced (see 🔑 6), it should never be tested in your production environment. Ensure your development team are not using you as a guinea pig and they’ve already tested all their tech, ideally within their own systems.

9. You can't predict the future 🔮

6 months is a long time in business, longer in technology and even longer in software. In software, Agile is 28% more successful than waterfall.

The Agile methodology is not just for software development, the core concepts have taken on a life of their own and have been growing rapidly in popularity across organisations. If you haven’t embraced Agile already, the right team should be able to help your organisation understand and reap the benefits.

Find a partner you can trust will build it right and not take expensive and inflexible architectural shortcuts

10. Good architecture trumps a fancy UI

This is more true in business software than in public facing websites for a few reasons:

business software is (with a few exceptions), more complex than public-facing websites
it’s likely to be more functional than a public-facing site
users often have no choice but to use it

The point I’m making is that just because you can't see it, doesn't mean it's not there. Clearly great UX is important, but don't get carried away with snazzy UIs. Good software is built to embrace change; architecture is important.

Find a partner you can trust will build it right and not take expensive and inflexible architectural shortcuts. It'll cost you less in the long run.

11. A little planning goes a long way

Software development is complex and unpredictable. Building good software is a process of refinement; you can't always take decisions up-front. The better the team, the more you can trust them to take the right decisions as they go, the less you need to (and should), plan up-front.

The right team should suggest new features, systems integrations and workflow automation options you haven't yet spotted

12. 🤔 Think about the problem, not the solution 💭

You need a dev team who will ask the right questions and guide you towards an appropriate solution. It may sound counter-intuitive, but don't trust a team that asks what you want but doesn’t challenge your answer. I get that politically challenging your ideas may be easier with an outsourced team than an internal one, but let’s not get started on business politics!

Your development team shouldn't just be providing solutions to problems you've already identified. The right team should have enough insight to suggest useful new features, potential systems integrations and workflow automation options you haven't yet spotted.

After all, they're the experts.

13. Then de-risk the solution

Building a Minimum Viable Product (MVP) requires building only the core features that make your product work in order to learn from user feedback. It’s usually best to keep at least some background processes manual at this stage (see 🔑 2). This means you can reduce the project risk and the costs of failed assumptions or hypotheses.

Take the time to test in the real world, with real users, just not with all of them at once

14. Big bang roll-outs can be just that 💥

If you have the option (which you always should), roll out new systems cautiously. Take the time to test in the real world, with real users, just not with all of them at once.

15. Testing is hard, but essential 📋

Part of your responsibility as the customer (whether using an internal or outsourced team), is to test what's been built. It's your chance to check the trust you've put in your dev team was well-placed. Don't skimp on it.

There shouldn't be any surprises as your team should have collaborated and communicated throughout but there will always be bugs…

16. There will always be bugs 🐛

It's a fact, deal with it. It was estimated (admittedly a while ago), that there are between 15 and 50 bugs per 1000 lines of code (“Code Complete” by Steve McConnell). However, modern practices have helped to significantly reduce that figure. Some modern practices are more effective than others in this area...

17. ...so insist on automated tests 🤖

Automated testing during development has been around for some time. It takes time but it works to significantly reduce bugs, which can be costly to diagnose and fix later on.

It’s also recognised by Forrester as a differentiator between Devops leaders and laggards.

Speaking of fixing bugs...

18. Better to have support and not need it

Ideally, your system has been rolled out, all bugs have been squashed, your users are overjoyed and you’re reaping the RoI. However, there will inevitably be

edge cases that need considering
user questions that need answering
potential issues that need diagnosing
security patches that need applying
library updates you want to take advantage of, and
infrastructure that needs managing

You may have an IT support team that can take care of some of these scenarios but it’s highly unlikely they’ll be able to (or want to) cover them all, especially when creating bespoke business software.

You’ll need a specialised team that will work with you to support your users and your software on an ongoing basis.

However, bear in mind that...

Don't be palmed off with a support team that don't actually understand the software

19. All support teams are not created equal

Make sure that the same team that built your bespoke software can support it, at least for the time it takes to bed in.

Don't be palmed off with a support team that don't actually understand the software or your issues.

Consider what it used to be like getting in touch with your bank, then imagine the issue you need solving is one stopping your customers accessing your products or services. You want the right person on the job, now!

20. Security is fundamental 🔒

You only get one chance at this. The average cost of a data breach in the UK is £3m according to the IBM Security Cost of a Data Breach Report 2020 and increasing (up 4.3% since last year). In 23% of those UK breaches, the root cause was identified as a system glitch. So, not only can you not afford to get security wrong, you need a software development team you can rely on to get it right.

If your team doesn't understand application security inside out, find a partner that does.

There are plenty of providers out there with solutions to simplify authentication and authorisation. Ignorance is no excuse.

And finally...

21. Communication, communication, communication 💬

This is hard to get right but critical. No-one wants a team that constantly needs guidance, but you should always be kept up to date. Finding the right collaborative balance is immensely important and it's your responsibility as much as theirs.

Let your team know when and how you want them to communicate with you. Think about whether you want verbal updates or written, whether it’s important to have real-time information or if retrospective updates work better. They will advise what sort of access to stakeholders works for them.

Facilitate ad-hoc communications, set up regular meetings and don't let these slip.