#10 – The build server always has a few failing tests
Unit tests are a valuable piece to a layered approach to quality. But unit tests only have value if people see them as needing to always pass. The moment people stop caring about failing unit tests, they have lost their value.
#9 – When did this code get in here?
Many environments don’t value code reviews. Code is just merged in and deployed. If there is one thing to add to any process, it would be adding code reviews. It could be the single best thing you can do. But it does mean you need to fail pull requests that don’t meet design / coding standards / requirements.
#8 – This new framework will fix it
As developers, we can fall into the trap of thinking some new technology will fix our problems. Often that isn’t the case. A new technology just comes with its own set of problems.
#7 – Only Bob understands that part of the system
A common problem in software systems is information silos. Each developer works on an individual part of a solution, but no one knows the big picture. Also, we often end up with a situation where only one developer understands a particular piece of the system, and no one feels comfortable diving into that piece. At Don’t Panic Labs, we focus on using the same patterns and practices in all of our solutions to maximize our ability to move developers around.
#6 – Deploys involve someone doing a copy/paste
Taking time to set up a good CI / CD environment is essential to building a quality system. If releases involve a developer doing copy / paste operations, you are often going to have problems. We want repeatable processes that don’t require developers to do anything. The moment we introduce a human into the process we have problems.
#5 – Don’t touch that code
Some systems have that dark corner where no developer will go. When we end up with those, we have a problem.
#4 – We are going to need another hotfix
Hotfixes happen. Hopefully not a lot of them. But if we find ourselves doing a ton of hotfixes, we probably have a problem.
#3 – I hate release days!
I worked at a company where each release started at 2 am and finished at 5 pm. We dreaded those releases. You shouldn’t dread releases. You should have confidence that your new bits will go out smoothly. Things such as automated tests, good CI / CD environments, and code reviews all help to get us there.
#2 – We need to rewrite it
After a few years, developers will start saying, “we just need to rewrite it”. This is compelling to everyone. Developers feel they can finally eliminate some pain they have been feeling.