From Cal Evans:

As developers, most of us are optimists. We look at a problem and say “yeah, I can solve that”. Most of the time, we are right, we can solve that, but not usually in the timeframe we originally estimate.

…

So when we tell a customer/client/family member “Yeah, I can build that this weekend”. In our mind, we mean it. We honestly think the project is simple enough to be built in a weekend. It rarely is though.

…

Remember Clock time !=Calendar time It’s not enough to say “This project will take 2 weeks” if you have other projects you are working on in those two weeks. Make sure you tell your customer/client/family member/boss/neighbor how many hours it will take to accomplish the task, and how long it will take you to slot those hours into your schedule.

To this I would add: Do not estimate in hours. Estimate in days or weeks. If you quote 120 hours and it goes to 144 hours, the client will freak out. If you quote 15 work days and it goes to 18 work days, they’ll be a lot less bothered by it. If you quote 3 work weeks and it goes over by 3 work days, it won’t even register. It’s all the same amount of time, but the framing is different.

And regarding developers being optimists, this is so true. I regularly point out to junior developers that they are insufficiently pessimistic. A highly-intelligent developer finds it easy to rationalize after-the-fact why things didn’t go as planned. Quoting from Modernizing Legacy Applications in PHP in reference to starting a project over from scratch:

Overconfidence, insufficient pessimism, ignorance of history, and the desire to be one’s own customer all lead developers easily into rationalizations that “this time will be different” when they attempt a rewrite.

These are all totally natural behaviors for developers, especially the very talented ones. The mark of an professional is to realize before-the-fact that unforeseeable circumstances are going to ruin your perfect plan, and then to make very broad allowances for the unforeseen. Those are the kinds of practices that embed themselves only with painful experience. I have used a rule of one day per controller method per 2 developers for a long time now, and it has served me well.

Afterword

Are you overwhelmed by a legacy application full of spaghetti includes and global variables? Do you want to improve the quality of the code, but don’t know where to begin or how to proceeed? My new book, Modernizing Legacy Applications in PHP, gives step-by-step instructions on how to get your code under control and keep your application running the whole time. Buy the early access version now and get free updates as it is completed, or sign up on the mailing list below for more information and a free sample chapter.

Read the Reddit discussion about this post here.

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving you codebase, all while keeping it running the whole time.