Begin With the End in Mind

I remember writing a code generator early on in my career to accomplish a very boring programming assignment. When finished, I was very proud of what I had created. I toiled away several late nights making sure that I accounted for a wide range of potential changes and edge cases. I took the time to build in an extensible framework and even refactored to a widely used design pattern. When I was finished, I ran it once to generate the code I needed - and never used it again.

I spent so much time prematurely optimizing my workload that I never slowed down enough to think about the implications of spending days of hard work, effort, and budget on a throwaway application. I never stopped - even for a minute - to consider the potential lifespan of what I was building. I think this is a common problem we face far more often than we should.

We approach software design with one of two absolute mindsets. First, we imagine a quick-and-dirty throwaway application, or script that is meant to run once, or twice, or a dozen times, and that's it - delete it before you go home for the evening. On the complete other end of the spectrum, we simply jump right into analysis, planning, or development, and assume that our software will, sort of, live on forever. There is no middle ground.

Everything else that humans build, besides software, is designed with a deliberate and predefined lifespan. Cars, airplanes, video game consoles, microwaves, televisions, etc., all have a shelf life, and, most of the time, the manufacturer has already started working on the next version before the initial product has been fully released.

Whether we want to think about it or not, all software has a finite lifespan. Taking the time to understand how long your application needs to live can have a profound impact on design trade-offs you make:

• Is this something that will become obsolete in 12 months?
• Are there external factors that could force a significant change in core functionality?
• Will it need to perform a small set of tasks reliably over the next decade?

If you're anything like me, you have been operating your entire career without ever asking how long your new application will need to exist before being replaced - not to mention coming up with a plan on how to replace it. Next time you find yourself designing a new project, begin with the end in mind. Deliberately think about the optimal lifespan of your application and plan accordingly, you'll be better off for it.