Striving for perfect code is a goal of many developers and programmers. We want our code to be simple to read, concise using the best idioms that our programming language has to offer and of course backed by an army of tests to prove it works. You want your code to be perfect. This is achievable in our own projects and products that we have invested our own time in, but what about work for clients and employers?

Your development time is measured as a resource whether you are a full-time employee or as a gun for hire freelancer. How do you justify spending hours getting the code you have written to be the most perfectly implemented code you can achieve?

You don't.

As an agile developer, the code you have written should be testable and easy to read. With a little bit of extra time, it should also be concise to the point where you have re-factored duplicate code, extracted some methods and maintained basic programming principles but also ensured that it is still readable. So what about taking a step further and making it even better?

Hold fire. The code you have written for the feature or bug or whatever it was is now working and tested. You've spent a bit of time refactoring. Now commit your changes and move onto the next card for the application.

In your eyes you have committed sub-standard code. With a bit more time you could have taken it further and made the code better. This path can go on and on if you're not careful.

In your client's eyes or employer's eyes you have committed working code, you haven't taken too much time to do it, and it works. They will be happy with your efforts.

The perfect code you are aiming for is never going to perfect and nor will it last. In a few months, the framework you have written your code with is going to be updated. Chances are the perfect code you have written could be improved upon again. In a year or two, the programming language your application is written in is going to be updated. There goes your perfect code. Then when the programming language has been superseded by a new kid on the block, the application you invested so much of your time in is rewritten in a different programming language. Your perfect code is gone forever.

Unlike the written words of Hemingway or Tolkien that have endured decades, your code is simply a stop gap to making a product or service operational. By all means exercise some time to make improvements on the code. Remove duplications, re-factor it, but always keep an eye on the clock. Spending too much time trying to achieve perfectly written code is not a good use of your time or the time of your client or employer.