IT management can often succumb to repeated patterns of behavior. One of those repeated patterns is accusing developers of being “perfectionists.” The developer or developers in question will be told that they should not strive for perfection, because perfection is not needed for the circumstance, and, more importantly, attempts at perfection take too long. Is the developer a closet perfectionist? Maybe, maybe not.
The accusation is often simply the manager’s internal rationalization for why things are taking longer than the manager believes is necessary. If the developer is new, or for some other reason not trusted, then the accusation may impugn the developer’s skills. Certainly, everyone wants to get things done quickly and effectively, but many people believe they are skilled at estimating development efforts when they are not. And if the manager starts with the firm belief of being right on a number, something else must be impacting the lack of a proper result. How quick is quick for a given issue?
Feast or Famine
Similar situations result when an issue arises that everyone can acknowledge requires a significant effort to handle—properly. But then management gets it into its head there must exist a shorter path to a reasonable workaround. Management may have no idea what that workaround is, but decides it must exist and that the team will certainly find this said workaround. Or it may decide that the team is populated with perfectionists, is lacking in the right skills, or both. Obviously, when those same engineers actually deliver on time, then they are heroes. Feast or famine seems to be life in many a scrum.
Being managed by people with such attitudes can have consequences. Engineers may fall into a constant crisis mode, where workarounds only enter their minds at the occurrence of each new requirement. Solutions with a proper foundation don’t happen because a proper foundational approach is never even considered. Or worse, engineers may devolve to a point where no one cares about a job well done. Development is done blindly, in that it may work, or it may only appear to work, but either solution is acceptable.
A Matter of Perspective
For any task, determining how much effort is enough for a given situation can be a matter of perspective. When engaged in development, how does one survive the slings and arrows of outrageous management practices? Stop, take a deep breath, and think the situation through. Consider the reality of the circumstances. If you know that the proper/more costly correction will ultimately be necessary, then a more complex set of factors must be balanced. If the short-term fix is to be done now, then when will the long-term fix be able to be addressed? If everyone agrees that a later phase/effort will likely be done and such refactoring can be worked in, document it and move on. If the likely answer is that never will this be touched again, then ask yourself whether it is OK for the proper long-term fix to never be done? If the answer to that question is, “No,” then you either need to bite the bullet and present the case for the larger fix to the powers that be, or let the same powers that be accept that they are choosing an inferior solution. (Try to get such decisions in writing.)
Unless you own the company, you may sometimes have to accept such inferior solution decisions. But at the same time, you should not leave such decisions unacknowledged and with the potential power to blow back on the wrong people. Make sure things are documented. Many times, engineers do not like documentation. It is not necessary to document everything all the time, but recognition needs to be made on important decisions that may be suboptimal. And, if there are times when managers start seeming to be bullies, documenting decisions made against recommendations will be useful if things fall apart later, and helpful for achieving a little piece of mind as projects move ahead.