Embracing Laziness in Software Development

Laziness being a good thing is a common and frequent theme in software development. One of the most famous quotes by Bill Gates states:

I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.

While in a sense this may be true, I don't think that the right conclusion to take from it is that being a lazy software developer who avoids effort is somehow better.

We understand laziness as always choosing the easy solution, which usually means the quickest solution that takes the least amount of effort.

I now recognize that reframing laziness has allowed me to build better software.

It's easy to write new code that fulfills some current requirements; the hard part is ensuring it is easy to change and maintained easily.

It would be great to write software once and be done, but the reality is that most of the time software will need to be modified at some point or another, usually to fix problems or extend it's functionality, and when we do that, we often don't stop to re-evaluate past design decisions.

We usually design software when we first write it, and then just tweak it constantly to do the new thing we want it to do, so we end up with fragile code that is essentially a pile of quick fixes, with a lot of complexity and dependency bagagge which might not be needed anymore.

Fragile code leads to buggy software that is hard to change, making for a frustrating user experience and a slow development cycle.

I still consider myself lazy, but in a different way. I don't want my team spending weeks developing features that should take days, I don't want my team working Friday evenings debugging problems, and I certainly don't want to spend valuable development cycles manually testing applications because we fear small changes could break production. I don't want to spend my mornings responding to urgent bug reports that could have been prevented with better practices. I think laziness shouldn't be about avoiding effort but rather about building sustainable, efficient software.

Modifying a codebase isn't just about patching it up to meet new requirements, it's about reconsidering whether previous design decisions, abstractions, and complexities still serve their purpose or if they've become obsolete.