Build to Suit Conditions Build to Suit Conditions
The best summary of all of our best practices is: ⚠️ Build to Suit Conditions. That is, pick whatever is the most appropriate tool or process for the job you’re doing.
Generally speaking, be pragmatic. Being agile in your processes means you should focus on building what’s needed right now, rather than some sort of theoretically-perfect solution, allowing you to iterate and improve in the future. But, that means sometimes you need to invest and lay the groundwork today. Every situation is different, and you should adapt to the conditions.
Be Consistent Be Consistent
When working with existing projects (such as retainer projects), you should always aim to fit into the style of the existing project, even if best practices have evolved since. Unless it is truly advantageous to switch the project to a different style (which it rarely is), avoid doing so, as it’s unnecessary work. This applies to the codebase as well as the tooling around it.
Some of our long-running projects have through many standards iterations, and may follow older design patterns. Additionally, project tech leads may make different decisions for projects for many reasons, including experimentation, fitting with a client’s team, or integrating with legacy code. You should aim to be consistent with these deviations to ensure the codebase exists as a whole piece of work, rather than disjointed updates.
For entirely new subsystems within a project, you need to gauge whether deviating from the rest of the project is worth it. If the new code is expected to be significant, and is essentially the future of the project, it may be worth using newer processes to allow you to move faster.
Inconsistencies affect many things, including internal onboarding, project velocity, and client handover. Any inconsistencies should be vary carefully considered against all factors.