Working with External Developers
Are you thinking about working with an external developer for your software project?
It's a good consideration. There are many advantages to working with an external development team. For one, they can have access to skills that are lacking within your business. An outside perspective will also challenge internalised assumptions. Ultimately, this leads to a more thought-out product.
When making PayReview, and various other products, we have worked with various developers. We'd like to share some of the lessons we've learned along the way.
Run a simple project first
A common adage is that you don’t really know someone until you have lived with them. If you were to apply this to business, it would be: “you don’t really know a company until you’ve worked with them”. No matter how good your vetting process is, you’re never going to get the full picture of what it’s like to work with a company until you actually do.
“You don’t really know a company until you’ve worked with them.”
Running a simple project first can be a great way to break the ice. You can get a sense for each other’s strengths and weaknesses. You can hone in on the best way to collaborate. And most importantly, you can assess the quality of the developer’s final product without committing all of your resources. This information will be invaluable when it comes to a major project. Whether it’s problems you want to address or you’re reconsidering working with them at all.
Use an internal project manager
Good news! The test project went great. You’re now confident that you’ve chosen the best developers for the job. So now you can give the project and leave them to it, right?
Well, don’t be too hasty to take a hand’s off approach. One thing you don’t get when you outsource is consistent oversight of the project. You’ll be relying on the project manager of the team that you’ve hired to keep you updated. And what you want to know and what they’ll contact you about doesn’t always align.
This can lead to issues such as:
The developers making assumptions about features that aren’t accurate
Long periods of time where you’re not getting progress updates
Reduced visibility of the issues that the developers are facing
This is where an internal project manager comes in. They can keep tabs on everything going on and make sure communication is free and open. You need someone who can keep the external team accountable and on the path that you expect them to be. This project manager should ideally be someone who has experience in software development already.
Without this, you risk the external developers doing what they assume you want, rather than what you actually want. Even if you have thorough, waterfall-based specification, the language itself can be interpreted in different ways. That’s why it’s best to maintain constant oversight.
Perform thorough in-house testing
So, your internal project manager has the main project under control and things are going well. Now the developers want you to test what they’ve built.
It can be tempting at this point to assume that everything is fine and skimp out on this. The developers have their own quality assurance team anyway, so they’ve already tested it, right?
Yes and no. QA teams will sometimes only test software against limited criteria. Or they won’t try to break it on purpose. This can leave you with feature sets that only work in a specific way or that are easy to break if used ‘incorrectly’. And if there’s one thing users are good at, it’s using software in a way that you didn’t intend them to.
“Software never was perfect and won’t get perfect. But is that a license to create garbage? The missing ingredient is our reluctance to quantify quality.” –
Boris Beizer, software engineer and author
So this testing phase is crucial for you. Most importantly, it’s required so that you can sign-off functionality. And if you miss something, it can cost you time and money to fix it if you’ve previously given it a thumbs up.
As such, you should have a robust test plan in place that checks the functionality from all angles. You should be testing against the specification as this is what the external developers will use as their ‘bible’. If a feature has been implemented incorrectly, you will need to be able to point to a place the proves this is the case.
It's good idea to write out some tests you can run many times. This will also allow multiple people to run the same test in the same way. Some things to bear in mind when testing:
Does the functionality work as specified?
Is it easy to break?
Has new functionality caused any problems with existing functionality?
In Summary
Running a major software development project can seem like a daunting task. The key is to treat it with the same care and attention that you would for any major investment. You may be outsourcing the project, but this does not mean you’re outsourcing the responsibility.
Failing to put the necessary checks in place may result in an external team losing their way. And once they start making assumptions about your intentions, you’re on a slippery slope.
So make sure you’re on top of any external team you’re working with. The alternative is wasted time, money, and sanity.