Broken Windows09 May 2017
If you have worked as a developer long enough to be beyond a junior then you should recognise both of the above. They relate to the ongoing care required to maintain a code base. They outline an expected behaviour of good developers. If you read the above links and Google the topics you will be a better developer creating better code.
While implementing a small change in a project today I opted to reuse an existing API for the task at hand. It provided a simple chunk of business logic with a simple method signature.
I coded up my change, fired up my local development environment and watched as a YSoD appeared on my screen. OK, I didn’t pass the right values. Nope, in checking the values I was passing the expected tenderId and the supplierId. 15 minutes later, once I had opened the code that provided the API I found the issue. A Linq query was using the supplierId parameter against the SupplierCompany entities. (The SupplierCompany entity has it’s own Id field.)
I trawled back through the commit history. I found that the changed occurred in a refactoring of this service class. The change was correct but the parameter had never been renamed.
This is frustrating and showed the mentality of the original development team. The developer refactoring the code didn’t show any care about the change he was making. The team’s review process was lacking or non-existing. When the developer and their team don’t care enough to review changes then small issues will creep in. Adherence to coding standards will be flouted and as time goes on the small issue build into bigger ones.
As Uncle Bob says “… it’s more than that. Caring for our own code is one thing. Caring for the team’s code is quite another. Teams help each other and clean up after each other. They follow the Boy Scout rule because it’s good for everyone, not just good for themselves.”