A while back I was tasked with writing a program that took content out of a database and reformat it as a PDF document with a specific layout. I found this nice CPAN module for perl called PDF::API2 which allows you to write PDFs on the fly. After some database giggery pokery I had a program in place that created the 500 PDF files in about 2 min.

After I wrote the program I wanted to address the complete lack of documentation for the module. I ended up writing an article that never got linked anywhere. I am correcting that issue now and hopefully this will help someone else with a similar problem.

Why is one of the most important parts of code life-cycle given so little attention? Usually this is because most programmers can get excited about starting something new and do not get excited about letting something go. The other reason is many developers associate sunsetting with tedious tasks like documentation. However, planning for the full life cycle of a piece of code can actually make the code function better and more stably over the use of the code.

Sunsetting can actually refer to two things. First, a scheduled checking of components or content in a system for pruning. This type of review should be standard after the launch of any piece of large code. Content placed into a system will eventually get old and be inapplicable. By looking at it now and setting a date to remove it from a system you are doing two things. One, you are creating an area where content is viable and fresh. Two, you are not bogging down your system with extra information people may not access. This pruning is like when you prune a plant. Keeping the important parts will make it more useful and prevent it from slowing down.

This also applies to objects in system. You may program a system to support online banking as an example. But after 4 months you find that no one uses the online banking components and you intend to turn them off. Instead of just masking them in system, consider removing them. This will reduce confusion by developers down the road as to which part of the system and active and which are not. It will also speed the functionality of the overall code set by removing needless tasks.

Second, the retirement of a piece of code for the replacement of a new piece of code is the other way the term ’sunsetting’ is used. Programs have a life span. Usually this is due to advances in code, hardware, software, or business lessons learned along the way while using this code. Every year you should make a short evaluation of the code to see if it still lives up to expectations and can deliver properly. If not, start to consider retiring the code and replacing it with something else. Retiring the code is a good thing because you want to bring current quality to your users and not keep them stuck in something that may no longer fit their needs. Your consumers change so your code should match with it. You can usually plan the sunsetting steps soon after launch to make this process easier.

In any case, do not expect your code to live forever. It has a time and a place and will eventually move on. Think of programming as art and life. What you create is an expression of your style to solve a problem. That expression will grow, live, and eventually sunset. Hopefully, it will be reborn anew to start the cycle again.