When you are in production, you don’t have much time to fix bugs. If you are slow, you lose money and people remember that your website didn’t work and don’t come back.
You don’t have time to understand cryptic error messages or to guess what to do to fix them.
You don’t have time to understand what a function does or what a variable contains. The original developer may be on holiday or she may not be able to remember what that variable was about if its name doesn’t help.
A good structure helps too. If the software is easy to browse, errors are easier to find.
A production manual is a good idea.
I was managing a team whose goal was to design the production activities to be performed on a group of servers delivering virtual ISP services.
I knew that a production manual was what we needed to ensure a smooth operation.
Every event was documented in the manual along with it’s troubleshooting measures and the log of every case of occurrence.
In many cases I have written such a high quality software that production was going on event-less. This is the case of my PLC software and the software I have written for Intel Corporation.