Maybe I’m just a bit of a perfectionist, maybe I’m not that different than the average person. I like things to work just right, usually by my definition of “right”.
So sometimes I feel compelled to spend time tweaking something to work just right. Sure, it worked good enough before, but it wasn’t perfect. So instead of moving on to something more productive I waste time trying to squeeze out that last level of perfection.
You may hear business people talking about ROI. It is Return On Investment, figuring out if what you are investing in is worth it, or if it would be smarter for your limited resources to be invested somewhere else that will give greater returns. Generally the ROI for “tweaking for perfection” is not worth it. There are times when “good enough” really is good enough, and it may be more frequent than you think. Yes, there are times when perfection is needed, but before you go for that you really need to think critically about the real requirements. There isn’t time to make everything perfect in every circumstance.
I was watching a few students on a development team. These two students had different opinions over how a piece of code should be done. But the assignment to write the code was given to one of the students. The student wrote it, it worked, and was checked in to the repository. Later, the other student analyzed the code that was written by the first student, changed it, and checked that in to the repository, all without talking to the first student. Of course, when the first student discovered what the second student had done, there was some friction between them that took a while to resolve.
There wasn’t anything wrong with the original code from the first student, it worked and met the specification. My objection with the second student was the time spent re-doing code which was already sufficient. That was time that could have been directed into something more productive that could have advanced the team. The first version of the code wasn’t done the way the second student wanted, but it met the needs of the project. There was a loss to the team both in terms of time and teamwork.
What it basically comes down to is trust. In a team you have to trust other people. Yes, you need to know if the other person is trustworthy. Assume they are unless proven otherwise. But if they are then you need to exercise that trust. If you don’t exercise that trust then you’ll need to do everything yourself. And you don’t have the time for that and that is not the definition of a team.