Is it DONE yet?

Seriously, is this task really done? What does done mean?

There is a huge difference in working in a task and actually completing it. We, as developers, have a natural way of thinking logically. We see when the result works as we expect it and trust it's the right answer, we trust it's done.

I remember the time when I was working in one of my first websites. It was a website about rats that can detect tuberculosis and land mines (pretty cool, right?). I worked on it with two other developers and we did the whole layout according to the design. It worked as it should, the navigation was right, the content was in place, it looked perfect to me. When the Project Manager looked at it, he said that the logo had a 1 pixel line next to it and it had to be fixed. He didn't accept the project as done. It seemed like all the week's hard work was in vain because of an insignificant 1 pixel line, like it didn't matter how many things worked, that the information was there, nothing mattered. I was offended.

I learned a valuable lesson after that day. I realized that a small (but important) detail can throw away hard work. I learned that there are simple things that make or break a project. "God is in the detail".

After that, I decided not to fight against that concept. I decided to use it to my advantage. Now I always check the details of what I do. I know that those small details prove that I care about the result, that I like what I've done and that I can be proud of my work.

It's not easy for a developer to think about everything. That's why regular users are usually the first ones to spot bugs. But it's important to think differently, to think not only as a developer, but also as a user, as a Project Manager, as a designer, as a CEO. It's important to realize that our work must be appealing to everybody, as much as possible.

I recently used the analogy of delivering a car. One of the best developers in my team solved a problem in a very elegant way, I was impressed, but there was a simple case when his solution failed, and it was an easy thing to solve. I told him that he was delivering a brand new, shiny, powerful Ferrari, but with flat tires. Why would he miss such an important detail that made all his hard work useless? I've seen him care very much about the details afterwards.

A task is done when it fulfills its requirements, when it has been tested against the use case and more cases, when it doesn't break other functionality, when it has no typos, when it's ready to be used, when there is no way to improve it for the project's needs.

So the next time you're about to say that your current task is done, STOP and give it another look. Think simple. See it with as somebody that wants to find a way to break your solution and then make it impossible for that guy to break it. Make sure you can be proud of your work. It's not easy, I know, but you wouldn't buy a $100,000 car with flat tires, would you? Think about it the next time you are delivering your work!