Early last month, I began working on a set of applications that may very well be my “last” applications as a software engineer. I put the “last” in quotes for a reason. Technically these applications will not be the LAST applications I work on but they will outlast me as a software engineer. Here's why I started to ponder this: Many of the applications I've worked on have been used in one form or another for many years after their initial development. These applications I'm starting on now will be around long after I retire as professional software engineer. After over 30 years in this business, it never ceases to amaze me just how long our applications live.
I have a little game I play when describing the age of the applications. I envision my applications as my children who have their own ages and personalities. I discuss each application in terms of childhood development. Some are toddlers, some are in elementary school, some in middle school, some in high school and in one case, if the application had been a real person, I could've sat down for a beer with it before it was replaced by a younger sibling.
It may seem trivial to assign ages to applications as though they're children. I disagree. This assignment of age gives a certain perspective to the general condition of an application. Generally (with a capital G), newer applications have cleaner and better code, and older applications have what I like to call “seasoning,” meaning that their original features may have been augmented, replaced, or sometimes removed.
Applications are living, breathing entities and they need to be accorded respect for their longevity. Also, the longer an application is used, its value to an organization likely grows.
It's this longevity that we must always consider as developers. For every application I build, I try to keep in mind that these applications live on and on and on. I try not to take shortcuts. Or when I do take a shortcut (knowing that reality always trumps theory when deploying applications), I try to clean up after myself.
To illustrate this, I'd like to discuss the new applications I mentioned in my introduction. These are green field applications, and I'm doing my best to ensure their success in the long term. I started these projects using a discovery-based process, not in architecture but in design. I know that these applications need a reasonably polished look and feel. Rather than reinventing the wheel, I started with Bootstrap 5 as my design framework. I like Bootstrap because it's a well-designed layout tool with a broad depth of adoption and knowledge surrounding it. Bootstrap, like most frameworks, comes with its own set of constraints and I wanted to make sure that it can support our look-and-feel goals. Using the discovery method, I created a new form and went to work using Bootstrap to build a page called Standards. Figure 1 demonstrates the results of this discovery process.
Once I felt that we could achieve our look and feel using Bootstrap, I moved on to the most important aspect of the application: The system architecture.
Using the same discovery process, I chose one part of the application (a simple lookup table/screen) and built out the requisite features needed by the system. This includes CRUD operations, validation rules, service architecture, unit tests, integration tests, etc. Keep in mind that I didn't build all of this from scratch. My team has around 10 years of code that I was able to pull the best code from. Once I was happy with this architecture, I continued my discovery with other system entities. I built around half a dozen features and I saw that there's a lot of boiler plate code that could be carved from the system with a few carefully constructed classes. So I refactored the entire application and reduced the lines of code by hundreds. Although no new features were added, the architecture of the system improved greatly and will hopefully take us a long way forward in the construction of this application.
Now, I could have just said “meh” that's good enough, let's move on. But I had the nagging feeling that this would ensure our long-term success. I'm hoping that this application lives on so long that I can celebrate it with a beer when it's of age. Which gets me back to my original premise.
Let's discuss the application I joked about having a beer with. That application was built in Visual FoxPro around 1998/1999 against a beta build of SQL Server 7.0. That application lived until 2019, when it was replaced by a shiny new WPF application. This application has a newer architecture, is fully unit and integration tested, and is likely to be a critical application for that client for the next 20+ years. Here's the funny part: I was a bit sad that this application was replaced until I realized that a TON of the code is baked into SQL Server stored procedures and some applications that are just now hitting the 20-year mark. So that application and some of its DNA lives on and, given its age, is just about to be able to rent a car, put on some sunglasses, and ride off into the sunset.
