Working With a Technical Partner (Part 2)
Regardless of which company you choose to be your software development partner, we want your project to be a success. In this, the second of two posts, we suggest some points to keep in mind both before choosing a partner and during the project. In Part 1, we looked at some factors to consider when evaluating potential partners.
Feel Free to Challenge Technology Choices
Unless you have a very specific need, we recommend you don’t dictate the technology used for the solutions. On the other hand, you shouldn’t blindly accept the technical decisions of your technical partners. Feel free to ask the developers to justify their decisions, which they should be able to do in clear, unambiguous terms.
Developers typically have a couple of blind spots when it comes to choosing technology:
They may choose the same technology, regardless of the problem they are solving.
They want to use the technology with the most “buzz” in the technology community.
There is nothing wrong per-se with developers choosing technology in part because of the above drivers, but if they are the only reasons they can offer for their choices then be concerned. What you generally want from the technologies used to build your solution are:
Fit for purpose now, in terms of cost of development, performance, security, etc.
Likely to be supported by a company or active open-source community into the future.
Is not so niche that you are locked into choosing from a small pool of developers. This drives up the ongoing cost of ownership of your solution.
A good place to start sanity checking the proposed technologies for your solution is the stackoverflow developer survey, an annual look into the trends in the programming community, from the perspective of developers themselves.
Insist on a Regular Delivery Schedule
This is closely related to the previous tip on flexible terms. Make sure you are regularly given a demonstration of the features that have been developed to date and that those features are fully functional. A common experience in working with software developers is that a project is quickly reported as being 90% complete, but the remaining 10% seems to never get to completion. The solution to this is that features are either done, or not done. There are no “almost” or “yes it’s done but you can’t see it yet” conversations to be entered into.
Potential technical partners should make the delivery schedule clear in the proposal or the contract. Insist upon a delivery at least every 4 weeks. This also means that the amount of testing and validation of what has been delivered is always of a manageable amount.
Each delivery should also include handing over the source code to date (provided your payments are up to date of course!)
Stay Engaged Throughout the Project
It is essential that you remain engaged throughout the development process. If you are working on a personal project, then you will need to be engaged with the development team on an almost day-to-day basis. If you are working for a company, it is important that you identify all the stakeholders of the project and then nominate a single person to act as the point of contact with the development team. That person will then need to be engaged with the development team. This is primarily to ensure that communication channels remain open. As we’ve already covered, poor communication and incorrect assumptions are the bane of many development projects.
The involvement of the key contact cuts both ways. They need to be able to facilitate the answering of questions from the development team, making calls on relative priorities of features, identifying new requirements, etc. They also need to be holding the development team to account, through regular testing, reviewing feedback from the development team and so on.
A good technical partner will put a structure in place that allows the primary contact to easily fulfil their role, through clearly defined project roles, a published meeting and delivery agenda, access to the team’s work management and communication tools, an always available testing environment and a contact within the team that you will deal with. Look for evidence of this in any proposal that is submitted.
When in Doubt, Seek an Independent Opinion
Never lose sight of the fact that this is your project, not that of the technical partner. If at any point you have concerns over how the development is proceeding, you should feel free to seek the opinion of a third party. This could take the form of:
Getting a security company to perform a security audit and/or a penetration test;
Asking another development company or consultant to review the code and/or project process to date and suggest improvements;
Engaging a third-party to perform regular testing of the system on your behalf (especially useful if the project is complex and your time is limited).
Some reviews, such as those related to security or quality, are going to produce objective findings and should not prove contentious when raising them with your technical partner. A code, architecture or project review on the other hand, is going to be more subjective. You will need to keep in mind that these reviews give you another developer’s opinion and it will be up to you to decide which findings are reasonable and which can be ignored.
Don’t expect your technical partner to necessarily like having a review performed, but it is important that you maintain visibility of all parts of the project, not just the delivered features. As we’ve touched on more than once in this document, there is much more to a software solution than what you see as a user.