Sometimes when you’re programming (or working on any project, really) you’ll discover some feature or issue that requires a lot of work to do properly. It’s often something that you completely overlooked during your initial design work, a tricky bug that came up during testing, or a use case that only some users will find.

A few months ago I made a simple Rubik’s Cube page and put it up on the web. More recently, I discovered it had a bug; a pretty serious bug that meant it wasn’t doing at all what it was supposed to be doing, namely simulating an actual Rubik’s Cube. Fixing it was hard. It meant rethinking the entire design of my code. I spent more time fixing this bug than I did on the entire first version of the project. At the moment I’m wrestling with a similar issue on my current project. To make it work well in 100% of all possible use cases is taking considerably longer than it took to make it work 80% right. Programming projects are full of these types of issues that look simple until you start working on them and realise they’re not.

Often the right decision to make in these situations is to not do the extra work. 80% right might be good enough. It might not have been worth fixing the Rubik’s Cube at all (it was just a toy project, nobody actually uses it, and if I was really worried about having buggy code on the web I could have just taken the page down). If you’re working on someone else’s project, it’s their decision whether you put the time and effort into making things perfect. If the most important thing is to release on time then releasing without the extra work is probably right.

But while there is clearly a cost to putting in the extra effort, there are some benefits too:

• You learn something. One reason the task is difficult is because it’s outside your current set of abilities. Pushing through and getting it done will stretch your abilities, and that should benefit you in future projects.
• It feels good. We all have internal standards of quality that we like to live up to in order to feel good about the work we do. Striving for that extra bit of quality helps us to feel that sense of professional pride in our work.
• You may get a better overall design. Once I’d fixed my Rubik’s Cube bug, I actually had less code, and the design was more elegant than it had been before.
• What you release is better. It may only be perceived by your users as infinitesimally better than it would have been, or it may only be a small number of your users who actually notice. But the fact is that it is slightly better than it would have been. Maybe this makes a difference to your business. The marginal use case you fixed could be essential to a particular user who raves about your product on her blog and gains you several more customers as a result.
• You get a sense of satisfaction when it’s done. You took on a challenging task and completed it, and that can be very satisfying.

When you encounter an issue like this, it’s important to accept that the problem exists, decide whether it’s worth doing or not, and commit to that decision. There is no point hoping that the problem will go away. There is no benefit at all to dithering about whether it’s worth fixing it or not. Consider the cost, consider the benefits and decide. If you decide to do it and it ends up getting even more complicated than you’d anticipated, you can change your mind later. But there’s something very motivating about committing to fixing an issue no matter how difficult it is or how long it takes, and very satisfying once you’ve fixed it.