The goal of programming is not the system, but the process of keeping the system alive

This took me a long time to realize...

Over the years I've (co-)created a bunch of programs, systems and projects. Small programs, like a perl script to create synthetic training data for tesseract; and large programs like the JaikuEngine Mobile Client. Small systems, like the linux server at my mother's office (running since 1998 as a firewall, file and directory server, SSH access point and previously an email server) and medium sized systems like the 50 machines doing video transcoding and streaming at my latest contracting project. Open-source projects, like the Jaiku port to AppEngine.

I have agonized over some of them. Over the unused code, left to rot. Over the systems that are running but might have bugs. Over the programs that no longer work because their dependencies have changed too much.

However, I only really understood this autumn that the reason I'm stressed about possible bugs in the code or system configuration I've left running somewhere is that I had thought the goal of programming was to create a program or a system. I should have understood earlier, that the goal of programming is to create the process through which the system is kept alive (until it no longer produces enough value to justify the maintenance). No program is perfect, if nothing else the world around it changes.

There are many ways to keep a system alive. You can sell (or buy) off-the-shelf software with support. You can sell custom software with support. You can sell custom software to an organization that is capable of taking over the maintenance. To have an open-source project, you must be able to create a community that wants to maintain the code as the world changes; including either providing leadership or being able to attract it.

Should I program again, I at least now know what I should aim for.

BTW, I don't think I'm the only one who hadn't realized this - this is the reason for all 'legacy' systems.