As a consultant I rarely see systems that are operating well. People don’t take their cars to the mechanic when they are functioning properly. I appreciate that this colours my experience.
Still, I’m continually surprised to find smart people working in the “Care and Prayer” model. These people work really hard and try to gain a deep understanding of the minute details of what they are working on. That’s the “Care” part. Then they make the smallest possible change that they think will have the desired effect. And they hope it will work, which is the “prayer” part.
Extreme Programming (XP) became popular more than a decade ago because it freed programmers from “Care and Prayer.” I’ll keep saying XP to refer to XP and all of its many descendants like Agile. More recently DevOps techniques have driven “Care and Prayer” out of the bulk of IT.
XP brought in a new model called “Show and Know.” Instead of making the professional the corner stone of quality assurance, the boring-repetitive parts of quality assurance are entrusted to software. Instead of praying that your change doesn’t break anything, you run an automated test that proves that it didn’t break anything that you or your predecessors ever cared about.
“Care and Prayer” is detrimental for a few reasons:

1. The biggest problem is that testing in general, and regression testing in particular, are ad hoc and inefficient. Either they don’t get done, or they take absurd amounts of effort.
2. The next problem is that the “maintenance” programmer is inclined to make the smallest change the can think of in hopes of reducing side-effects, rather than making the best change they can think of. We’ve all seen code with multiple authors none of whom were prepared to take on the task of cleaning.
3. The final problem is that “care” takes a lot of time, while “prayer” is hard on morale. XP teams work more quickly. Each “Show and Know” change builds confidence and momentum. The development team broods about every “care and prayer” change for some time after it is done.

There are two steps in this major cultural change:

1. First you need a test environment. Better yet, you need a means to easily provision as many test environments as you need when you need them. (Cloud computing makes this cheap and easy).
2. You need to record your tests in an executable format.

If you see someone agonizing over a page of code then something is wrong. Either you don’t have a suitable test environment or you don’t believe that you have enough tests. Correct those underlying problems rather than worrying about the details of the code. Every change ought to be a smooth operation of adding a new test case that demonstrates the need and then adjusting the code until both the existing tests and the new one all pass. Worry does nothing good for efficiency. And “Show and Know” produces at least as good quality as “Care and Prayer”.
-Steven