Your application is now in production. People are trying it out, trusting it. It’s scary. But you must now keep improving it.
Undeniably the stakes have been raised. Changing code becomes more risky, more risky than we programmers tend to enjoy. One mistake and the users might lose total faith in the system.
“If it ain’t broke don’t fix it.”
This is a convenient truism. However, one might also argue that “a code base that is not actively maintained will eventually fail.” Failure can come in many forms. Failure causes include security vulnerabilities and incompatibility issues with other software. However, a primary reason for failure is simply that what’s required of the application change and it has no chance of keeping up.
Yes, we should be cautious when performing larger changes to production code. But we should never be afraid of initiating that change. It’s actually what we should be good at doing. To that end we programmers should be investing time into researching and implementing things like continuous integration and continuous delivery. There’s a universe of tools for this out there. We just need to decide that improving code changeability should be a priority even in spite of being in production.
Extra credit wisdom: Cheating Gall’s Law by C J Silverio