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 do not want to spend weeks developing a feature that should take days, I do not want to spend Friday evenings debugging problems, I also do not want to spend hours manually testing an application because I fear a small change could break the whole thing. I think laziness shouldn't be about avoiding effort but rather seeking efficiency.

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.