All Posts in Technology

|In: Leadership|Last Updated:

You can’t make this stuff up. Ray Todd Stevens tells us:

I am working on a recovery project for a company that outsourced the coding for a major application on which the company depends. They did this to an offshore company. Someone at some point realized that the code had no comments, and so insisted on the code being commented. So comments appeared and nobody apparently looked at them other than to ensure that they are there. The project was accepted and the offshore vendor was paid.

Now we are dealing with some bugs, and have found that yes there are comments. The ones that are in English refer to process and procedure documents that were apparently internal to the vendor. My client certainly does not have them. The rest of the comments are not in English. The variables are named after Indian Gods. So far the comments that we have determined the language for are in eight different languages. Most of these refer to things that we can’t even figure out, and don’t appear to relate to the code they are tied to.

The external documentation is about as bad although it is in English.

I guess you get what you pay for.

If you’re looking for anecdotal ammunition to argue against offshore outsourcing, look no further. But that would be wrong. Once more, with feeling: Anecdotes illustrate points, they don’t prove them. The question is, what point does this anecdote illustrate? Surely not that all offshore outsourcers provide comments only under duress, and then in inaccessible languages. An anecdote this tasty has to illustrate something more profound than that.

For example, this: Alignment of goals is more powerful and reliable than specification of responsibilities.

This point plays itself out in all sorts of situations. When you delegate tasks instead of goals, for example, you have to inspect the results with far greater care, because the assignee’s work is finished when it meets the written specifications. Whether it does anything useful is Someone Else’s Problem — not the case when you delegate the goal.

When you contract with a vendor, relying on specifications almost guarantees you’ll pay more for less. Never mind offshore IT services. It’s just as true when dealing with ad agencies: Plenty develop campaigns designed to win them awards and new clients and not to make your cash register go ka-ching.

It’s the same when you don’t rely on a vendor. If you want to make sure IT delivers software that does nothing useful for the business, define your Systems Development Lifecycle so that business analysts work with business departments to determine their requirements and create written specifications that programmers use to design and build applications. If you’d prefer to accomplish something, have business analysts facilitate conversations between business departments and developers, using written specifications to remind everyone of what they decided in the face-to-face conversation. The former is reliance on specifications; the latter gives everyone the opportunity to align their goals.

Then there’s the ever-popular dress code — the subject that wouldn’t die. Companies that try to define and enforce proper dress mostly achieve resentment and a cadre of jailhouse lawyers adept at malicious obedience — at adhering to the letter, but not the spirit of the code. Companies that encourage employees to use their good judgment, dressing professionally and appropriately for their work seem to get better results.

Alignment of goals is more powerful and reliable than specification of responsibilities for a reason well-known to computer scientists: When in doubt, add more processors. When you rely on specifications you rely solely on your own brain to figure things out. When you rely on alignment of goals, you get to take advantage of everyone’s brainpower. More processors.

Which leaves just one small challenge to be addressed: How, exactly, do you align everyone’s goals?

The short answer is, that’s what leadership is about. A slightly longer answer is that it isn’t all that hard, because most people, most of the time, prefer things that way — they want to belong to a group that has a purpose they can buy into and contribute to. For some reason, likely related to a personal need for control, many managers give every appearance of working very hard to prevent this very common and natural human tendency from operating.

There are few situations in IT, or anywhere else in a modern business, where specifications are enough. Usually, good judgment matters. The only way employees can apply good judgment is if their goals and yours line up.

Making that happen is up to you, not them.

Comments

|In: Industry Commentary|Last Updated:

I knew better when I wrote it.

A couple of weeks ago I based KJR on a blistering, self-righteous critique of the various guilty parties responsible for the Katrina fiasco, deriving a number of lessons for IT along the way. While the guilty parties are just as guilty as before, it turns out the root cause of the flooding was much more complicated than my simplistic analysis (failure to invest despite a clear need to do so) suggested.

It’s almost always more complicated, which is why “self-righteous indignation” and “ignorance” are strongly correlated, if not synonymous. Simplistic analysis is for the simple, the intellectually lazy, and (to be fair) the excessively busy. None of the three are excuses for bad decision-making.

It turns out that while hurricanes have doubled in total destructive power over the past 30 years, and that global warming is probably a major cause, Trent Lott’s lost house exemplifies the bigger reason that hurricanes do more damage than they used to: Lots of Americans have chosen to build their homes along hurricane-prone shorelines.

It also turns out that Katrina’s storm surges were smaller than initially thought, well within the design parameters of New Orleans’ flood control system. Some newly renovated levees failed, apparently due to poor design (preliminary analysis suggests the use of flat plates instead of interlocking plates is a primary culprit).

Want to bet that at some point during the design process, the engineer who suggested interlocking plates was overruled due to cost considerations? And if not, that the contractor whose bid was based on interlocking plates lost out to the contractor whose design did not? The federal government does, after all, tend to award contracts to the low bidder (except, of course, when it awards no-compete contracts to Haliburton).

This new information reinforces the final point of the Katrina column — engineering does matter — but adds an entirely different perspective to it that provides another important, if prosaic reminder for IT: An absence of defects does not ensure the presence of quality. It’s a necessary condition, but not a sufficient one.

Depending, of course, on how you define “defect.” Too often, in IT, we equate bugs with defects, and as a result, testing with software quality assurance. It’s a basic point, but then, in IT as in most other disciplines, 80% of success comes from mastering the fundamentals. It’s still the case that in far too many IT shops, even testing receives too little time and attention.

In the case of New Orleans’ levees, it wouldn’t have mattered how good a job inspectors did after the installation was complete. Even if there were no construction flaws, the fundamental design was defective (assuming the preliminary analysis holds). The parallel for software development isn’t subtle: Software designs should be reviewed for conformance with software engineering standards prior to coding.

Not perfectly parallel is the need for stress testing, which would have been highly desirable for the levees were it not impossible, since there’s no practical way to set up Development and Test versions of New Orleans. There’s no equivalent reason to not stress test software.

But the larger lesson is the first one: Other than in Aesop’s Fables, it’s rare that challenging situations leave us with a few, simple, clear lessons. The world is a multivariate place, especially when those pesky human beings get involved.

Which leads to one final point, after which I’ll leave the hurricane post morti to the committees and experts. That’s the matter of what, for want of a better term, we can call “contingent responsibility.”

Contingent responsibility is what didn’t go wrong but just as easily might have. When you do something dopey, you sometimes get lucky and live to tell the tale … fortunately, or many more of us wouldn’t have survived our formative years. If you’re smart you recognize you got lucky, and avoid repeating your dopiness. If you aren’t, you figure it means your reasoning was sound.

People being what they are, I’m confident that when those who made the decisions to not invest enough in levee maintenance learned it was new construction that failed, they decided their allocation decisions were just fine after all. I’m equally confident that when those who discount global warming saw that the rise in coastal construction was the primary cost driver, they felt justified in continuing to fight emission reforms.

I’m confident, because I’ve seen too many business managers rely on luck as an alternative to investing in the mitigation of well-understood risks, disparaging those who warn of the consequences with this compelling logic:

“It hasn’t happened yet.”

Comments