Perfectionism and Programming, Where to Stop?

I know it is good to be a DRY, Agile programmer and not repeat yourself, but I have a hard time being “lazy” due to a problem with perfectionism.
I have been working on finishing up additions to a web app in PHP that I coded last year and for each day that I *should* wrap up, I find One More Thing that should be polished A Bit More, just One More Thing. Last week, I fell down a hole of internet research about the latest developments in PHP security. This was bad, because there have been new techniques on how to best beat the bad boy hackers, so this week I found myself making a few changes to reflect best, current secure practices of the most recent cutting edge.
This is the right thing to do, right?
Well, bits of the app then needed to be recoded, and then a few more changes, and then test the database, and then some more recoding, and I had a huge refactoring snowball rolling down a hill attacking me. Gah. But in good conscience, I could not leave the client with security holes.
Where do you stop? Right at the letter and law of the contract? A few extra hours of work if you find some new information on the latest and greatest practices? Or do you just do it and refactor the whole app for professional pride and a good job well done?
Let me know where you draw the line.

One thought on “Perfectionism and Programming, Where to Stop?

  1. Anytime you look at a piece of code after a period of time, you will find a better way to program it. This has held true for me for decades, and for every language from COBOL to ColdFusion and everything in between.
    The biggest issue is security and risk – those of course take priority. next is performance, and lastly coding standards. If cleaning up code vs. getting the site out the door is the choice, it’s best to keep the client happy.
    mp/m

Comments are closed.