Do you trust your work? Do you trust your colleagues? Yes? Ok, I’ll rephrase - do you assume your work and that of your colleagues will be correct and bug free? I don’t - not even slightly. Every flaw I have seen appear in systems over the years has been due to an assumption. Usually someone assuming that they had gotten something right and not proving they had gotten it right. It usually got through because their colleagues assumed the person writing the code knew what they were doing and trusted them to not make mistakes.

I don’t trust code, not my own, not others’. If someone claims to have completed a task I don’t believe it, not until I can see the proof. Some might claim that it is not in the team spirit to have so little faith in the group. Seeing as I apply it to all (including myself) I think it is a fair policy. Require proof that something works. Insist on test coverage at all levels (unit, component, integration, regression, etc.). If something is said to be too simple to get wrong, guaranteed someone will mess it up.

The same is true of existing and legacy code. Just because it’s been in the system a while does not guarantee it is correct. The number of flaws my teams over the years have noticed in existing production code just by not assuming that existing code is correct code is shocking.

Think back (realistically) on the number of mistakes that have slipped through initial coding by you and your colleagues. How many only got caught at test? How many more may have slipped through because of a missing edge case test? Think about all the parts of your system that didn’t get tested at the development phase at all (usually environment specific components).

Now think about that code already in production. The developers coding that were in exactly the same situation; they were no more likely to get it right than you were. The only advantage (if it can be called that) production or legacy code has is that it has been stressed long enough that some of those bugs may have produced enough noticeable errors for the bugs to be found and hopefully corrected.

How do we mitigate this? Testing, obviously. Test everything (or everything possible). For the stuff that isn’t testable at development time (usually production specific configuration) do dry runs on paper. Prove that in theory the modification is safe and has no nasty side effects. Work through the scenarios where production deployments or configuration changes have to be rolled back. Again, prove on paper that it will work. It’s not perfect but it’s the best available at that point in time.

For the code and configuration that is testable at development time, test it! Preferably automated so that it will continue to be tested. For colleagues’ work you are reviewing, insist on test coverage. Both line/branch/condition coverage of unit tests, and all the test scenarios you can think of for component and integration tests. Don’t assume they got it right. On the receiving end, be grateful for this insistence - I’ve lost count of the number of times a particularly pedantic colleague has caught something I missed. If you’re pairing and navigating, this is your job. Find the flaws. Come up with the what if scenarios.

Do not assume. Do not trust. Require proof.

Shared at https://www.linkedin.com/pulse/trust-assumptions-code-donal-stewart