Clocks in SOX

Most people never read Sarbanes Oxley, section 404, but plenty use it as an excuse for convoluted processes, mostly involving peculiar Chinese walls.

Something like “common sense,” at some companies, for example, says that those who deploy home-grown software must be different people from those who write it. The developers get annoyed because they have to explain to some moron in “change management” obvious things like that the Spring property configurator just needs the new name for the file where you put the password which is clearly different for the key store you need to get from the security people who must know which host you want it to deploy on. Programmers can spend endless days complaining about how those idiots could not figure this all out, because they definitely sent emails explaining that you need to configure acegi-context.xml.

In that respect, at least, the “segregation of duties” becomes helpful by encouraging developers to simplify the configuration their applications require.

It does not, however, encourage any extra rigor with regards to application quality. In fact, programmers become even more reluctant to fix their mistakes because they had such a difficult time getting it deployed last time.

Just to make a dysfunctional system that little bit funnier, some people have created a process involving Rational ClearQuest. In this process, the developer creates a “deployment ticket.” The ticket specifies a human being who should perform the deployment, a time window, instructions, and some other information no one reads. A potential deployer then receives the ticket and prioritizes it among the other incoming tickets. In the fashion of true technological progress, the two parties never need to communicate except through the ticket.

This is, of course, a recipe for inaccurate execution, if not total disaster. The deployer has no control over what time the scheduler requests the ticket be executed. The scheduler has no access to the deployer’s calendar or any idea of what other schedulers might simultaneously schedule that same deployer for. The schedulers know the deployment only takes a few minutes, but they build in a half day window for potential backlogs in the deployer’s queue. The deployer sees an entire half day for completion, so feels no particular urgency.

Meanwhile, the testers wait for deployment to complete, and you have transmogrified five man-minutes of work into four to six wasted hours for several people.

Why Is Worse Than How

When we use software, we operate in a binary tree. At the root, we could be in success or failure mode, where we are either doing whatever we meant to do, or distracted by some idiosyncrasy of our tool. In success mode, our productivity flows. We could be CTRL+Spacing to auto-complete or ESC, colon, w, q-ing to save and exit, and doing what we meant to do.

In failure mode, we have another couple of options:

  1. Why does this suck?
  2. Where is the option to make a zero-based list in WordPress?

I want a zero-based list because it appeals to my binary metaphor. The first item, zero, equals bad software. It is the tool that you wish you could will into nonexistence. You imagine the deepest levels of hell holding those who inflicted this impediment on you.

While you use them, you usually do not think about good tools. Your drill lets you swap bits without thinking about the drill. You only wonder whether this bit will work for that material and do you want 5/16 or 1/4?

Sometimes your tool cannot meet the challenge. You want to bore a new dryer vent through your cinder block or put drywall around the entirely bare laundry room and your minuscule battery-powered appliance will fight valiantly and fail. This is where you leave the text editor and open the IDE, but it is not a failure mode; you have simply exceeded your tool’s capability, and you need to go get that spiffy hammer drill.

You encounter tool failure mode when you do not immediately know how to accomplish your immediate task with the tool you are using, and you do not immediately have another tool that does it. You now find yourself in one of two camps, but you have no idea  which:

  1. Your tool cannot do it
  2. You do not know that ESC, y, y copies a line

So you have to feel your way through, based on your prior experience with that package. In the good programs, you, like the Little Engine, believe that you can.