I have been a part of a number of software delivery projects, note emphasis on delivery not development, projects over the years and I thought I would share my checklist for projects as well as myths that need to be removed from teams for success.

An interesting quote from a delivery manager I have worked with and admire “We need to remove the notion that software products are successful because of hero developers, it is teams that consistently produce quality software”.

With teams and the fact that not everything can be gotten in place from day 1 of the project here is what I think

Must Have

These practices/processes must be in place on day 1 otherwise you run the risk of paying for them later

1. Version control process – I have seen many a project with a version control system, but without a process for managing how the developers in the team commit code for features. I personally recommend
   • Trunk based development, master always has the latest version of working code
   • Version branches: when there are major version changes maintain a separate line for bug fixes. However this leads to overhead for back-porting (from master to the version branch) or fore-porting from the version branch to master, so must be used very carefully
   • Pull Requests for code review and feature tracking – each developer must have their own version of the code, and issue pull request for code review and merging.
   • Each developer works on feature in its own branch so does not slow down during code review cycles
   • Regular developer commits
   • Pull request guides I like this one from OpenMRS open source project where I contribute https://wiki.openmrs.org/display/docs/Pull+Request+Tips
2. Unit Testing Framework – pragmatic usage of unit tests for business rules, and multiple paths through code
3. Automated building of deployment packages – manual builds are error prone not repeatable
4. Automated configuration switching between environments
   • external configuration of databases, web service calls etc
   • separation of development and staging environment configurations
5. CI pipeline – shows status of builds on code commits to the repository, requires unit testing to be in place
6. Ticketing and Task Tracking – what features are to be built when, and what is their relationship? Also helps track work across sprints as well as communicate to stakeholders
7. Security – The Open Web Application Security Project (OWASP) top 10 are a minimum standard to be followed
8. Architecture decisions:
   • Configuration over customization
   • Pragmatic use of external libraries that solve some part of the problem space

Important

May not be in place at project start, but must remain front of mind and put in place when opportunity arises

1. Coding styles – at project level or even at different layers
2. Documentation – usually an afterthought, leading to gaps later due to additional pressures. Once project stability is reached, then it is important for different stakeholders. I love Markdown and the excellent GitBook (http://gitbook.com) editor and toolchain
3. Integration Testing framework – includes UI testing of flows, however is usually brittle so has to be done in a pragmatic manner for critical and complex paths
4. Automated deployment of builds to staging server – this is a great step as it does not break the developer flows for show cases and demonstrations to stakeholders.
5. Integration, load, security testing – leave out at your peril as it will come to bite you later. Set some assumptions and test them out to your heart’s content in an automated manner

Myths to be quashed in teams

1. Developers do not write documentation – it is the responsibility for every member of the team to contribute to the documentation writing and review
2. Back end, database and front end developers – large projects may provide flexibility for isolation of developers, however it is important for developers to cross cut across the “application layers” to reduce rework and enable evolution as knowledge of the product increases.
3. Testing is a waste of time – a stitch in time saves nine. Pragmatic testing saves time since it provides more confidence in code reducing stress before showcases and production deployments.
4. Developers should leave testing to QA staff – testing is multi-layered, so developers should play their part to support testing and quality assurance efforts. QA staff have a different mindset which helps poke holes and find gaps in developed software
5. All the developers must use the same IDEs – the best tool for a developer is the one they know how to use. If the workflow is IDE specific then the project setup and configuration needs to be looked at to remove this dependency what will constrain the team later
6. I can build my code faster and better than a framework out there – advice from my mentor “Each problem you are solving is a special case of a more general problem”, “There is no new problem under the sun”. Building new code to solve a special case may be faster today, but you will pay for it in maintenance and evolution

Looking forward to hearing your thoughts and what I may have missed