A couple of months ago, I needed to use a laptop of one of my co-workers. When I opened the computer I was baffled by the behavior of the mouse pad. Apparently the mouse direction were inverted – when you go up, the cursor moved down. When you go left the cursor moved right. When I asked him what happened he said there is a malfunction in the pad and he doesn't have time to fix, so instead of fixing it he just got used to it…
How many times you heard a programmer in your team cries out to the havens about some ugly UI/code/design? What happens usually? Nothing! the code/UI/design stays the same and the next programmer who bumps this will again cry out, complain and do nothing.
Complaining is actually dropping the blame/responsibility to fix it to someone else, which makes you feel good to forget about it. It is used as venting for the developer so he can move on.
This is a bad habit in any team – When something seams wrong – it should be fixed. When these things are not fixed, no one wants to touch them, and the circle continues until there is someone brave enough to break the chain.
This type of behavior also manifests when doing manual testing of the app the team develops. Because of the fear to find bugs or to see things that aren't working, team members treat the application very gently.
My former team leader, noticing this behavior, made a list in our team portal call "annoying things to fix". He told us to enter anything we think needs to be fixed so we can map these kind of things and fix them one sprint at a time. After a couple of sprints we actually ran out of thing to fix including some big design issues. Other things simply entered the dev cycle as a User Story to be fixed later.
On my team I encourage the developers from the training stage to look on every mission, every line of code, every design decision critically. To fix these thing or at least report them, insert the fix as a task or a user story for the next sprint. When they are investigating user issues, to look at the system, and don't assume that everything works. To try to find the underlying problem and not accept that it happens.
I want a developer to look at the system, to map what's wrong and try to fix it. This raises the developers to a whole new level in which they do not complain anymore, they are not afraid to maintain legacy code. They can analyze a feature and tell you what needs to be done to fix it.
When the developers learn to change the ignoring instinct within him, the atmosphere in team is better – atmosphere that encourage healthy criticism, cleaner code and clean air without complaints.
Last week I was passing in the hallway and I heard an annoying scratching sound. I followed that noise into the office of my department head. I saw him there with another team leader trying to draw a sketch of some sort, on a whiteboard, with a marker that barely working. I walked back to my office, took a marker, returned to my department head, gave him the marker, took the old one and throw it to the trash.
On my way out I said to him: "don't adopt the symptom"