I know, 21 is a lot of keys. Software development is 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 software project. They’re just as applicable whether the team you decide to use is internal or outsourced. should follow process, not the other way around 💡 1. Software Obviously! This is the benefit of bespoke or custom software. major 2. Build what works Always try new processes manually before automating them. Don't use (relatively) expensive software to confirm that processes you imagined would work actually don’t. 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 developer would have a reasonable understanding of: project goals user’s issues solution architecture APIs dependencies integrations database 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. 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, , 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. IDC recently predicted worldwide IT spending will decline 2.7% in 2020 due to the impact of COVID-19 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 ( ), 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. see 🔑 6 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 . If you haven’t embraced Agile already, the right team should be able to help your organisation understand and reap the benefits. have been growing rapidly in popularity across organisations 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. 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 of the background processes manual at this stage ( ). This means you can reduce the project risk and the costs of failed assumptions or hypotheses. see 🔑 2 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 be bugs 🐛 always 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 reduce bugs, which can be costly to diagnose and fix later on. significantly 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... 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 £3.1m (£124 per lost record) and increasing, so you can't afford to get it wrong. 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. In summary... As you can see, there's a lot to consider. Finding, or building, the right team, a team you can trust and that trusts you is essential. JDLT At , we create custom business software for SMEs and large organisations. Please get in touch at if you'd like to talk about how we can help. JDLT hi@jdlt.co.uk Previously published here .
