How do I know the code is going to be of a high quality?

As Product Owners we tend to focus on the shiny and overlook the mundane. This isn’t necessarily a bad thing as we want the best experience for our end users, and we might say “they are never going to see” or interact with the code directly. This may leave you wondering “how do I know the code is going to be high quality and support my product both now and in the future?”. This question often arises when discussing outsourcing and offshore development. This question is closely followed by another “I’m paying a third of the cost, does that mean I am getting a third of the quality?”

Unfortunately, 10+ years ago this was a fact; the less a user paid for their software development, the lesser the quality. This was born from a significant barrier to entry on most development stacks. For example, to develop on the Microsoft stack there were significant licensing and equipment costs involved. Whilst most offshore providers were learning and providing the C# language, they were unable to develop in the context of the associated Tooling and Frameworks. Since then, major players such as Apple, Microsoft, Oracle etc., have been working very diligently on removing those barriers to entry by providing free tooling, documentation, and training.

Without these barriers keen developers with access to the internet can self-learn; and education providers can access platforms and resources without having to negotiate complex deals with vendors or make long term commitments to certain eco systems. As such, today it is much easier to find well trained, experienced, and enthusiastic developers across most modern development stacks.

So, what should I look for and why should I care?

Known Frameworks

Most core back-end languages (C#, Visual Basic, Java, PHP) have evolved to a point where they have well-known, supported, and documented frameworks built around them. These frameworks include .NET Framework and Laravel. These can sometimes be referred to as patterns and practices. Similarly, companies like Google and Facebook have pioneered the development of front-end frameworks like React and Vue.JS that also define and provide the same from for User Interface development.

Before starting a development project ask your development company to explain their Framework (technology) decisions, what other options they considered (and why they were rejected), what the expected lifetime of the technology is and how easy is it to upgrade.

Avoid where possible, custom development “Frameworks” or ones that abstract Known Frameworks. While these can serve to get your product to market quicker, consider your products lifetime and make sure that the developer will support their Framework for the life of your product with no hidden maintenance fees. It’s easy to find a React developer, but it’s hard to find an Automated-React-Fusion-Buzzword developer.

Readability

Code should always be written in such a way that is clear and unambiguous, and where practical, well commented. Fortunately, as discussed above, most modern Front End and Back End development Frameworks now define structure and connections around how code should be written. Throughout the development of your project, occasionally ask someone on your project team to show and explain to you how something was written and works. You may not understand all of it, but you should be able to understand the basic flow. If you want to be sneaky, ask a developer to explain another developer’s code. Alternatively have a look for yourself. If you don’t have access to see the code, well you should. It’s your code.

Portability

Ultimately the goal of using Known Frameworks and making sure the code is Readable is so that your application should be portable. That is, if you take it to another development company, regardless of their geographic location, they should be able to get your product running, maintain it (fix bugs) and further develop it (implement features). For everyone involved in migrating new versions of software between environments, portability saves time and mental effort. Portability can be a little harder to test and unfortunately isn’t generally considered until it’s too late. Make sure portability is openly discussed with your development team before signing a development agreement. This saves you from a ton of headaches in the future as once your code is portable it can be easily deployed anywhere.

Regression Testing

Make sure your team includes a QA “Tester” and clearly defined regression testing. This means after every development cycle, a tester not only tests the newly developed features and fixed bugs, but also check on what has been previously developed to make sure no new bugs (regressions) have been introduced. If you have numerous regressions after every development cycle, then the code is likely poorly architected and there should be cause for concern. A benefit of Regression Testing is that it allows for retesting of existing software after application changes which is great for future upgrades.

Summary

When choosing a development company for your project chose a development company that uses well established Frameworks and common patterns and practices. Make sure you have an in-depth discussion with your developer about the Frameworks available to you before you begin the project. Don’t be afraid or apprehensive about asking to see code and have it explained to you. Be open when discussing the future of your product and make sure there is scope for changing developers for any reason. Ensure that a QA / tester is included in your project team and keep an eye on their output to detect potential issues early on.