When looking into team productivity, i see a common pattern that has been happening with many development teams as described in the red line in the below chart
- It feels like coding velocity is good at the beginning. Unit tests are skipped
- Workload is often highest at the 2nd half or end of the cycle/sprint
- Last minute bugs fixing, critical bugs are fixed right away before release
- Fixing a bug introduces new bugs or back and forth multiple rounds for a bug
- Team is busier for investigating bugs once QC team starts testing and reporting bugs. Velocity is getting slow down
- Often need to stay late or delay. It is hard to plan or predict accordingly
- A long checklist and manual actions for deployment. Misconfigurations for large deployment
- Defer testing to later stage with manual tests. Lacking unit tests leads to more bugs at later stage. It often takes time to investigate bugs, thus reduce time for remaining tasks
- No system design: One of arguments, I often heard is that system design and unit tests are slow down productivity. It is true if we aim to have comprehensive design. Lacking of design is hard to distribute tasks evenly, bottleneck at the most senior members, also requires back and forth communication. At some point, no one knows why that decision was made
- No per code review: cannot utilize tech/domain knowledge of senior to support more juniors to foresee problems at coding phase
- No automation test: Not aware of breaking change existing features
- Low discipline: Everything is well setup at beginning, but not follow properly
- Don't think how to deploy at beginning, perform ad-hoc or manual configurations on testing environment without scripting or taking note
The blue line in the chart describes a better workload distribution (not high performing team yet)
- It is a bit slower at beginning, can adjust if necessary because team spends enough time for system design and writing unit tests
- Once code is marked as done, it must be properly reviewed and tested automatically
- Shift left as much as possible
- Spend enough time to discuss solution and interface before starting: able to foresee issues, reduce rework at later stage and able to work independently
- Write tests at development phase. Bugs are likely much lower at testing phase. It takes more time at implementation phase, but overall, it takes less time for you and team.
- Writing tests also helps to realize the unclear requirements sooner
- Invest time to setup supporting tools for automation(logs, lint, ci runner, ..)
- Scripting for deployment on dev and testing (migration, configurations)
- Code as document (Swagger) to assure it is always up to date with latest code
- Workload is highest at the middle of cycle or evenly after 1st phase (design, setup)
- Velocity is still good at the end since less time is required for bugs
These are my thoughts as view point of an engineer about one of common pattern and how to shift left workload. It is not a complete solution for how to increase productivity
Nice writing. I’d second the idea that testing should come as early as possible AND the need of a consistent CI/CD process. Even the most simple form of CI/CD & automation testing saves so much headache in the long run. I would also add that a way of monitoring the system on production is as important. Developing a software is just half of the work, there must be systems in place to monitor its “health”. This is sometimes neglected or take for granted by younger team, especially with ready, easier tools now like Datadog. But only those who have spend nights troubleshooting production issues would value the benefit of such platforms.
Thank you for sharing. I have one small question though, what's the minimum code coverages for your tests (unit test, integration test, etc) and how much effort of the team (in total) that's spent on the tooling system (logs, lint, ci runners, etc)?
Lacking of design is major culprit. No amount of testing will be enough when there is no clear and complete as possible design. If we fail to plan then we plan to fail.
Thank you for sharing