How often have you encountered issues with a delivery of your software supplier? It is rather the rule than the exception. Why? Because there are some technical rules or best practices your supplier should definitely comply with, if the supplier wants to be listed as a stress-free supplier in his customer base. We have put these rules as our top 10 best practices when developing software.
1. Use a Code Repository
There is no need to question this one. It is a necessity to organize the work and collaboration of developers or to create, reproduce and deliver releases and it is a mandatory practice in the software developers community.
2. Use an Issue Tracker
Issue trackers are much more than just bug tracking tools. It is a great way of breaking down the contractual requirements into traceable pieces and to track them transparently as tickets capturing functionality. Allow the supplier to use any functional issue type that you or the supplier deem appropriate like feature/user-story/improvement/whatever-functional-issue-types-you-want-to-use.
In addition, describing the respective work items of a functional ticket allows tracking the work progress as well.
Using an issue tracker is the only effective method to keep track of new functionalities that should be part of a new release. With an issue tracker the customer and the supplier have a mutual platform to share information on the contractual obligations and the detailed progress of the project.
3. Describe and specify functional tickets
Part of the supplier process is to specify functional tickets/change requests to remain aligned when deviations from the initial contract descriptions and agreements become inevitable or desirable. The process should be pragmatic, quick and clear and should answer the following questions (minimum):
- What is it about?
- What is its benefit? Why is the functionality needed from a user perspective, what does it improve, what limitation does it resolve or what initial requirement does it replace or make obsolete?
- Sketch any implementation ideas or design questions to make it understandable for those who should decide.
- Specify acceptance criteria as precisely as possible.
4. Link commits to issues or pull requests being linked to issues in turn
This is a necessity to get automated traceability from requirements to issues and down to code. It is the only way to let both sides know which functionality really made it into a release. Alternatively it is OK to specify a sub-task of a functional ticket or a bug.
Or link the commit to a pull request. But take care to link every pull request to a certain issue in turn (see point 5). At least 75% of commits should be explicitly or implicitly linked to an issue. And split the work to commit only for one specific issue and not two or even more.
5. Do not misuse pull requests for requirements engineering
Pull requests are meant to enable developers to collaborate effectively, e.g. reviewing work of colleagues before committing, organizing branch workflows and integration processes. Pull requests are definitely not meant to be a substitute of requirements engineering or an issue tracker.
Attaching labels to PRs to specify them as features/whatever-functional-ticket-type or bug is just a bad habit and counteracts all previously mentioned criteria. No developer is inclined to put much effort into describing a pull request in detail. This is what issues are good for with other roles (e.g. a product owner) spending effort on elaborating on them.
6. Put up Continuous Integration
This is the best and probably the only way to regularly build and test the software to be delivered, to measure the success rate of builds and figure out integration problems and errors at an early stage and thus improve the chance to meet the launch date. In addition, there is no other way to rebuild any previous release of the software in an efficient/automated way. Require your supplier to do it and control his efforts.
7. Handle bugs effectively
Bugs are the most annoying part of developing software. It takes time to reproduce the bug, to figure out the root cause and even worse, it keeps developers away from creative and value-added work on new features. Thus, the engineering team should collect in an automated way as much detail about the bug as possible as part of the ticket description (e.g. bug-traces, user/developer descriptions). Never fix bugs on the fly (e.g. as part of another feature implementation) and make sure to write at least one test case to detect any recurrence.
8. Budget 10-15% of the project capacity for improvements/refactorings
This is a criteria that should be well communicated and agreed upon between the customer and the supplier. Any software system needs constant improvement and refactoring due the technical reality and/or to non-considered aspects in the initial specifications. In addition, technology progress, pitfalls of programming languages and the constant need for developers to learn on-the-fly adds to all, absorbs project budget anyway and should be reflected in those 10-15%.
9. Monitor improvements and refactorings
To not create any mistrust between customer and supplier, transparency on how time is spent is utmost important. Any improvement/refactoring needs to be put up as a ticket of a dedicated type, the work and its necessity needs to be sketched and motivated (as part of the ticket) and traced down to code by the mechanisms described above. There are ways of monitoring the effort per ticket type (like improvements/refactoring, bugs or functional tickets) by certain tools like the DETANGLE Analysis Suite.
10. “Soft” criteria
A potential supplier might not comply with all proposed criteria. His willingness to get there is equally important. Agree on a plan and a schedule and give the supplier the opportunity to improve. Good software is a bit of a miraculous product, therefore it is also very important to establish a trustful relationship between all stakeholders in the project. If a project, despite all elaborate processes and metrics, gets in trouble, it is the trust between the involved people that can make this project still a success.