Five things to consider when choosing a new IT development partner

There are many nuances to consider when deciding which company to pick as your new partner for your next project. I'll try to bring to your attention some things you might not think about and explain why it is necessary to consider those details.

1. Is your project the right size for your partner?

Whenever I hear about different problems which companies have with their clients, one that often comes up is - they rarely speak to me. Or - It seems like they don't care enough. Or - It looks like they are not trying any more.

There are only so many projects one project manager can successfully handle, which means they are the real limiting factor for the dev shop, not the programmers. The project managers also face pressure from the company to do the things that bring in the most money. The result is that you do not receive the attention you deserve.

There are, however, ways to overcome this kind of problems:

• Pick the developer for whom you are the big client. Look at what they have done before and if your project seems to be a big one (but not too big) compared to what they have in their portfolio, then choose them. Do not pick a development partner for whom your project is small.
• Develop project in phases. Accept that we are not infallible and make mistakes - bugs happen. If you gather all your issues into one extensive list and present the list in one email or call, you'll likely get more attention. Not because you brought a long list of issues to their attention, but because you saved their time and gave them work for a more extended period. If you add the following development phase requirements to the list of issues, then you'll receive even more attention.

2. Pick a team with up-to-date and proven technologies

One of the problems which some clients face is that they cannot find another development partner to continue the work of the previous one. Sometimes, the problem stems from the fact that the last partner's code is poor, and no new partner wants to pick it up because it is challenging to estimate the number of hidden problems in the code. Which in turn might result in loss of turnover for your new partner.

How you can overcome this problem is simple if you have a technical background but quite tricky if you don't. One way to estimate if the technologies your potential partners offer is to look at popular surveys like Stack Overflows yearly overviews. If the tools your partner wants to use are popular, then it is likely that they have plenty of support from the community and are easy to use. Popular tools also mean that you potentially can easily continue the current work with a new partner, should the need arise.

3. Does your new partner plan for quality or failure?

Look for code quality in the estimate. Does your partner plan to spend time on writing automated tests or user testing? Do you, after reading the quote, understand who is responsible for the code quality. If you don't, then this very likely means that discovering bugs might be your problem.

The problems with the code, mostly known as bugs, result from our inability to hold the complete picture of complex systems in our mind. While programmers are often very systematical thinkers, none can bear the whole complex system in their mind and consider how potential changes affect the entire ecosystem. Bugs happen when different moving parts of the project don't work well together. It's nobody's fault. Most people can't follow relatively simple recipes without mistakes - or assemble IKEA furniture. So why should we think that bugs mean bad programmers?

We know that the bugs WILL happen. What you, as a customer, need to pay attention to is if your new partner has a plan in place for handling them. What to look for in the quote:

• Look for automated testing. Automated testing means that you will periodically test the essential bits of your project against code to make sure that your functionality remains intact. Thus automated makes noticing breaking changes quite simple.
• Look for CI/CD (Continuous Integration / Continuous Delivery), QA (Quality Assurance). Lines like these in your quote means that the development team has a history of ensuring project quality. CI means automated procedures to ensure project quality. CD means that the deploys of new code are automatic and save you time and money down the line, and QA implies that they have set some resources by for different things like code reviews, user testing and so on.

In this book, "The Black Swan", Nassim Nicholas Taleb describes this example. What if a hypothetical politician had pushed for safety doors for plane cockpits in 2000? And what if all planes had safety doors installed before September 2001? The 9/11 would not have happened, but all plane manufacturers would have blamed the previous hypothetical politician for wasting their time and money. It's the same with tests. We, as customers ordering the service, have no idea how many catastrophes quality assurance prevents. We look at the numbers of money spent and often think - is it even necessary. It is. If it's not present in the quote given to you, then expect trouble in the future.

The actual amount of tests per project varies from project to project. Like implementing a Content Management System to your design, some projects might not even need custom automated testing as CMS comes with their internal tests.

4. Do they offer to monitor website issues?

Every web project will have problems. There are just so many moving parts out of the control of you and the development partner. Services might fail and break etc.

It is not possible to ensure that some third party service is up and running. But you can control, how your project will behave if that service breaks down. What they can control is who finds the bugs and problems - you, your customers or them? There are plenty of automatic tools out there, which notify developers of errors in the website. Make sure your development partner is using them on your project. You want to make sure the errors are found as fast as possible, right?

5. Do they have a plan for handling technical debt?

First, it is essential to understand what is technical debt. Everything degrades, right? You have mileage or time-based service intervals for your car. Your Windows or Mac computer receives updates now and then. Why would you think your project needs no updates?

Web projects have become so complex these days. Fifteen years ago, everybody was still developing their own CMS's, and when they built a website, the website consisted of only one or two pieces of software. These days things are very different. This straightforward website here is made with NextJS (plus Strapi, TailwindCSS and many more tools) and consists of more than 50 third-party projects. Somebody needs to keep them all up to date. Because if nobody updates the software, then adding new features or fixing issues will become increasingly difficult. It is much cheaper and easier to update project gradually than once per year. If you have automatic tests in place (see previous point #4), then updating is even easier - another point into the long list of why ensuring project quality is essential.

So the bottom line - if you gradually spend time and money on keeping your project up-to-date, then adding new features or handling the project over to another partner will become much cheaper and easier in the long run. It is potentially saving you from having to re-write the whole project in 3 to 5 years.

All this is hard

Technology changes these days rapidly. It is challenging to keep up, and it is even more challenging to keep up for people who do not deal with project ownership daily.

When you assign the project owner role to a person in your company, you might be setting yourself up for failure. All these points, and many more, are pretty easy to explain to management if you know about them. Project owners, whose prominent role is not project owner, often do not have this ability. Your company and project will be missing out on all the benefits your partners may want to offer to you. To get more out of your project and your development partner contact me or someone like me.