Perfection v/s. Getting Things Done
Tanmay Vora
I had an interesting experience recently with one of my team members. We were to submit an important project document to client and we decided that we will first freeze the table of contents (ToC) and then move on to filling up content.
Almost a day went by and I had no update on ToC. When inquired, I found that team member was aiming at creating a perfect ToC by referring to all possible external references – without realizing that we had lost a day in pursuit of perfection when we could have done it in less time and could have perfected it as we go along documenting. In pursuit of perfection, you become your own worst critic!
There are situations on project when progress is important in right direction – in my experience, perfection is an ongoing process that actually starts after you set a right direction and make some progress therein. That is the starting point of perfection as a process. When you repeat this process over and over again, perfection gets ingrained in whatever you do – leading to excellence.
Some of the important lessons for me and my team member from this experience were:
- More you try to perfect something, more time it will take. (and you never know whether it will be perfect at the end!)
- It does not have to be perfect – just good enough will do.
- Perfection has to be a process – rather than a one-time-attempt. Perfect Incrementally.
- Sometimes a quick 90% solution is better than a 100% perfect solution that comes in when it is no longer needed.
- Focus on a few vital things – and set priorities looking at purpose and time available.
- Perfection cannot pursued be at the cost of taking actions at right time.
- Get it done once – then perfect it. Do this over and over again and perfection becomes a way of work.
I think – following two quotes aptly sum up the lessons above:
“Aim at perfection in everything, though in most things it is unattainable. However, they who aim at it, and persevere, will come much nearer to it than those whose laziness and despondency make them give it up as unattainable. – Lord Chesterfield:
Aim for success, not perfection. Never give up your right to be wrong, because then you will lose the ability to learn new things and move forward with your life. – Dr. David M. Burns”
Usually the first thing to suffer in a project is quality, thus perfection is rarely achieved in a project, and most people settle for just getting the thing done.
@ PMHut – For software projects, I do believe that project managers, quality teams and stakeholders need to put enough emphasis on achieving perfection (in functionalities, UI, Design and other quality factors) – and all efforts for achieving this perfection needs to be factored in the plan.
My view on quality has been that when intermediate deliveries are done, one should not aim at perfection. It is when the changes are done, code base stabilizes and defects are fairly low that pursuit of perfection starts.
It is also important to mention here that perfection has as much to do with an individuals view of perfection as much as it has to do with following a perfect process. I have seen many great developers who are able to build perfection in their code the very first time they write it. This – as mentioned in the post – is a result of doing it well over and over again when perfection becomes a way of working.
Thanks for your comments.
Such a pellucid write-up on such a tricky topic! My recent experience follows.
Some ten days back I started on a task to review my neighboring team’s code (web front-end code). I saw some apparent lapses that can be corrected, made a list of those and since I was enthused to re-factor the code and learn during the process I set out to revamp it. Initially I estimated the first set of changes to take around two days. As I started to re-factor, more and more lapses surfaced. Lot of accessibility issues, design issues. Code also reflected the fact that some of the crucial design decisions that should have been taken before coding started have been overseen. I went on to improve everything I could until I realized that there is so much to improve, it would take around 10 days more! The old code was still getting updated with patches and fixes. I was aiming for perfection!
What I should have actually done is make the bare minimum design improvements that were required and get the application to the latest stable state (or with minor bugs) and check in the code. Most of the improvements, I felt, could be done in small pieces and atomically once a proper design skeleton was in place. I eventually decided to stop my temptation for perfection, identified the changes that I made that were dragging me into further improvisations, reverted those changes back to the imperfect code that it was earlier, got the things working and checked in the changes within two days. It will be a bumpy ride for couple of days as some bugs surface but I ensure that the new code will fall into a proper direction.
So, can’t agree more on what you say. Probably the difference between a naive and experienced perfectionist is the ability or wisdom to hold back temptation to perfect everything at once. And yes, I liked this a lot “Never give up your right to be wrong”.
Thank you so much!