Engineers ought to be good at being realistic. Our whole job is to turn ideas into reality; it's what we live and breath. The problem is, sometimes it's convenient to be realistic and sometimes it isn't.
It's in my nature to be optimistic about feasibility and estimates. I like making people happy, and I like building cool stuff; win-win, you say. That optimism has been cured by late nights of fevered deployments. Oddly enough, I got better at estimating when it wasn't just my time on the line but a whole team's time. Soon after this realization I was jokingly introduced to a customer as "the guy who says no". Check that off my bucket list.
It's convenient to be realistic about estimates, because if you're wrong you have to work late. It's convenient to be realistic about feasibility; if you aren't, you may literally find yourself expected to achieve the impossible. Most developers only have to get burned a couple times to learn these lessons. However, it's far more difficult to be realistic about work that you really enjoy.
I'm going to make some hasty generalizations about developers now. We tend to:
- Optimize for fun
- Change language/tool preference frequently
- Enjoy solving complex puzzles with equally complex solutions
- Harbor personal animosity towards minor software defects
- Rewrite existing code if it looks at us funny
Don't get me wrong; I think these are the traits that make us good engineers. I don't think it's wrong to enjoy complex solutions, fix bugs, or rewrite code. But these same traits can make us waste huge amounts of time.
If we do not know who the customer is, we do not know what quality is.
— Eric Ries, The Lean Startup
It's convenient to cover every possible (or impossible) edge case and switch to cutting-edge technology; it's convenient because it's fun. I love new code base smell. Or maybe it's not fun, but it seems like the right thing to do or the right way to do it.
Our customers don't necessarily care what language we use, or even if we've squashed every single bug. By the same token, an incomplete but usable feature can bring value to customers; code stuck in development becoming "perfect" is worth nothing. At the end of the day the quality of software is defined by its value to users. If we have good habits, things we enjoy (bug smashing, refactoring, switching to new tools) can provide value — but not always. Be realistic even when it's not convenient.