Developers are lazy. After all, we’re in the business of writing software to do things we don’t want to. We strive to write clear, simple, elegant systems that solve problems and make our lives and the lives of others easier.

So when we’re given a simple task, why does this happen?

As I said, developers are lazy. But, paradoxically, we’ll spend an enormous amount of time to build reusable components and programs so that we don’t have to build them again in the future. We think this will allow us to program faster in the long run.

Over Engineering

I’m certainly prone to over engineering solutions. I can spend inordinate amounts of time refactoring and reworking code in order to make it more general purpose, cleaner, simpler. I think it appeals to our artistic sensibilities. General purpose, elegant code just looks and feels better.

Most of the time, especially if you’re building code for a customer or your employer, you should only build what is necessary. You might think it’s no big deal and you’re just being helpful. But adding in extra features has costs:

• Development Cost. Extra “stuff” takes more time to build. Even if the development effort isn’t that much (it’s just an extra checkbox!), there’s extra testing that must occur. Each feature added increases the testing effort by a factor of two or more.
• Opportunity Cost. The software market moves fast. Any delay in releasing working features to your customers is a cost in terms of potential revenue, market share, customer base, and more.
• Maintenance Cost. The over-engineered solution has a larger footprint in terms of testing effort, time and effort to maintain, troubleshoot and fix bugs.

Intentionally Procrastinate

If you want to program faster, build only what you need. When faced with the option of writing a more general solution or adding an extra feature, intentionally procrastinate. Put the feature on the backlog so you don’t forget it, but do not work on it. Do the simplest thing that could possibly work.

There’s an acronym that came out of the Extreme Programming (XP) thinking: YAGNI. You Aren’t Going to Need It (or, if you prefer, Ya Ain’t Gonna Need It). You may think that pluggable architecture is a great idea, but until you have evidence that the feature will be used by your customers, you don’t need it.

More often than not, that use case you are solving for never becomes relevant. Your customers don’t use the feature, the business takes a different direction, or a new technology comes along that replaces the code you wrote. Until you have an actual use case, you’re just wasting valuable time and introducing unnecessary complexity.

Conclusion

I love working and reworking software until it’s “just so”. However, when building software for actual, paying customers, resist the urge to over-engineer the solution. Chances are good that your extra effort will go unused or just cost more in the long run.

This is one of the few times when it’s ok to intentionally procrastinate. Put off until tomorrow what you think you need to do today. Tomorrow you’ll know more. If your feature still makes sense, by all means, add it in, but not now.

Question: What have you built lately that you didn’t end up needing?