In my first position at Digital, I was working with two other engineers, writing CAD programs to support the CAD designers who were sitting down the hall from us. The lead engineer operated very simply. One of the designers would come over and describe a particular operation that was terribly time consuming, and he would come up with a small application for the CAD system that would make that operation less painful, tweaking it and making little fixes until the designers liked it. The collaboration was very close and personal.

As the years went by, this same team went on to do some bigger projects. One of the projects, the ERICA project which provided electronic access to images of blueprints, got distributed over a fairly broad stretch of the company. When the software had problems, that same lead engineer continued to try to do work in pretty much the same way as he always had. He'd talk to the person and then send them an updated version of the software with a fix that worked on his system. That fix then became part of the code base when the next bug was fixed. He had talked to the customer and provided a fix and they went away happy. He was very happy.

However, pretty soon, we had different versions of the software at different sites, each with different sets of bugs. It became difficult to know what version of the code was actually being used. Users were starting to get irritated. Before the lead could start feeling the heat, the supervisor of the team stepped in and started fielding customer communications and doing what amounted to release engineering, passing bugs to the engineers to fix and packaging the fixes into scheduled releases. For all that we tried to convince him, the lead engineer never saw the point of putting all of this complication on top of just delivering fixes to whoever needed them.

Then one week the supervisor went on vacation and left this engineer in charge of the project. The lead engineer tried to field problems in his usual way. The users were pretty brutal in how they felt about the bugs and the continual replacement of software with little fixes that might have new bugs. He was honestly surprised and not a little hurt. By the end of the week, the engineer learned why the supervisor had done what he did and became an active supporter of the release cycle after that.

From this I learned that sometimes the only way to teach a person is to stop shielding him from the consequences of his actions.