About finishing IT projects and perfectionism
In past I started most of my IT-related projects from vision – how should finished product look like, how should it be named, what features should it have? I spent a lot of time imagining it and all the money I’ll earn from it :). Vision and planning itself isn’t good or bad, it has pros and cons, it’s just good to know them. For example, it’s generally good to know, where and why you’re going, problem is when most of the time you spent on planning itself, instead of creating a product first. Harsh true for me is that many times I didn’t finish my projects because of that. I wanted to have best/newest technology, write great code, have big code coverage. I always planned this perfectionist approach and many times it was the sole reason why I failed. Of course, it wasn’t the sole reason I stopped developing a particular project, there were many more like:
- with time it turned out idea itself just wasn’t good enough
- various life obligations
- I got bored 🙂
I’m sure every one of us has a lot of unfinished projects and can add other reasons to this list, but in this text I want to focus on planning and perfectionism.
From my observations, most of the society treats perfectionism as something acceptable. Many people know its pros and cons. Let’s take as an example Japan, which I believe is a country full of stereotypical perfectionists. We can find traces of it in bonsai, through sushi, finishing on katanas 🙂 We admire those things, beauty of them, near ideal execution. But what these perfectionist creators needed to sacrifice for it? How much time they need to spend on it, so it could be considered perfect? Many psychologists consider perfectionism as something wrong, because of the amount of pressure perfectionist put on himself/herself. A very uneasy truth about it is a direct source of it – fear of failure. Many people us it as a strategy to protected them from a failure, they believe when we do something perfect they won’t have to face it and they will be respected for what they did.
To illustrate it – we get familiar with new technology ideal for our project, which for example could fasten our work on DB layer by half and get us easier to maintain code, but we do know that in foreseeable future we won’t touch this layer anymore and rewrite will take a lot of time. Is it worth then? In my opinion not. Changing library only to have let’s say 30% less code is not worth investment in this case. I believe this balancing act is a vital part of programming – balancing cost and revenue, searching for a solution, that will give us and our client most value.
Dealing with perfectionism in most part I believe is about saying yourself – enough. This function is good enough, you have enough code coverage, you spent enough time analyzing it. For me there is a lot of anxiety in saying – I could do this better. I think though that it could be said pretty much every time about everything. For me and for you there is a question – do you want to live constantly improving everything or just be happy with what you did and move to the next thing. Remember about 80:20 rule – 2o% effort gives you 80% value. In most cases, 80% is just enough and there is a lot of other interesting stuff to do! 🙂
Ok, but how all that I wrote touches Get Noticed competition and TeamScreen project? Well, right now my main goal is to just finish a project and create a solution that I could benefit from in my work. I plan to divide my work in several milestones, each one functional on its own, each one looking like MVP – Minimum Valuable Product – a product that could be used and rated so I could use it on daily basis and have an idea what’s working and what’s not. First MVP will be a website that simply connects to TeamCity to display builds list and JIRA to display tasks in a current sprint.
With this, I finish my post and I’d really like to know I you had similar observations and thoughts. Please share your opinion in comments. For now, thanks for reading and I hope to see you next time 🙂