Internal Discipline

When we last left our hero the large organization was overrun by high latency task groups that were effectively obstacles to progress.

Another feature of large organizations, and by large i mean organizations with more than one person, is externally applied discipline. The problem to be solved is How does one motivate the employee to produce good work?. For the software developer, it's the wrong question.

One of the common management approaches to this problem is characterized by the carrot and stick paradigm. The idea was that to get a horse to pull the buggy, one had a carrot and a stick. The carrot was a reward for good behavior. The stick was punishment for bad behavior. Now, modern management has no experience with horses, or they'd know that the stick was not for punishment. The carrot was suspended by a string from the stick. But that isn't the modern interpretation.

Any parent will note that a promised reward is a much better motivator than punishment for children. In fact, punishment doesn't work very well, and not at all over the long haul.

But managers generally don't think that they have anything to offer an employee (which is false). They also don't think that they can get away with much in the way of punishment (which is also false). So, despite the above very common and widely talked about concept, it often plays almost no actual role in obtaining quality work.

What managers really know how to do is the paper trail. To get the developer to use source control, have a manager sign off that code is in the system. To get the developer to adhere to database standards, have a database administrator approve any database usage or changes. To get the developer to add user level help pages, have someone who only handles installing help pages on the system review the text and install it. To make sure that the customer is satisfied, have the customer sign off on the project before it is placed on the server. Each of these processes adds delays to the project, but do they ensure quality?

No. It turns out that the database administrator doesn't know anything about the application code. So even a simple query that uses only indexed keys might in fact be issued to the database millions of times. Only the developer would know that. The help text manager doesn't really know the application, and can easily miss omissions and outright errors in the text. Worse, help text usually concentrates on the details of how a function works, but never gives the end user any idea why one might want to use the function. That takes context. The customer signs off on the application, but does so at application launch. It may be a month before the customer is familiar enough with the product to be able to really evaluate it.

External discipline is inefficient and ineffective. The solution is to empower the developer to do the right thing. First, the developer should be aware of the kinds of quality that the customer wants. It may be consistency, repeatability, discoverability, ease of use, etc. Second, for those quality issues that only a developer could understand, review should be made by another developer. Code reviews have the side benefit of disseminating knowledge. Even the most senior developers learn something. Involve the database administrators early in the process, not late. The DBA should suggest good ways to do things up front, not stall a project nearing completion. To do that, the developer and the DBA need to work together. For best possible speed, they should be a single person. The customer should be able to give feedback at any time, not just before the launch.