The most common verb associated with requirements is “gather.” Yet most requirements that end up fulfilled in a system aren’t gathered. Yes, I know, there are always a few requirements that are so obvious in a new system that you can “gather” them from stakeholders, but gathering implies that the requirements are already out there, fully formed and fully understood, and ready for harvest. It just doesn’t work that way. No stakeholder ever says to an analyst, “Requirements? Why, yes, I have eleven requirements. Eight are functional, one is a usability requirement, and the other two are operational requirements. Are you collecting constraints now, as well? I have three of those. Please sit down, and I will elucidate perfectly clearly on each and every one in turn.” Most requirements are discovered–or invented. Many are transformed or compromised along the way.

Most stakeholders don’t consider the underlying requirements of their work; they do their work. They are not in the business of reinventing the work. The arrival of a new project is the point in time when the ideas for new possible ways of doing work force us to consider the underlying requirements. If you go to an experienced front-desk hotel employee and ask what requirements there are for the check-in process, you are most likely to hear in excruciating detail exactly how the check-in procedure works today. Indeed, you will probably hear more than just about check-in; you will hear about the reservation procedure and how it impacts the check-in procedure. It never crossed the mind of that employee to consider what information and material goods the hotel needs in order for a guest to do self check-in with a new automated system. And the idea of the guest selecting a room from all those available is a shock. It’s not done that way!

This is why we have folks with “analyst” in their titles. Analysis is never simply about recording requirements from clients and other stakeholders. Analysts are not waiters who take orders without comment. Analysts need to learn how to tease out the basic rules–the policies–of the system and liberate all stakeholders from thinking that the new system should be based on current procedures. It is invention that is at the heart of analysis, not gathering.

— Tim Lister

And the Gileadites took the passages of Jordan before the Ephraimites: and it was so, that when those Ephraimites which were escaped said, Let me go over; that the men of Gilead said unto him, Art thou an Ephraimite? If he said, Nay;

Then said they unto him, Say now Shibboleth: and he said Sibboleth: for he could not frame to pronounce it right. Then they took him, and slew him at the passages of Jordan: and there fell at that time of the Ephraimites forty and two thousand.

— Judges 12:5-6

Thus the original meaning of the word “shibboleth”: a password that people from one side can pronounce but their enemies can’t.

The word has since taken on a more general meaning as not necessarily a password, but a custom or practice that separates the good guys from the bad guys, the insiders from the outsiders.

Continue reading Shibboleths

Sanders quit because Lions weren’t winning

— ESPN.com headline

Background

Barry Sanders, as you may already know, was a running back for the Detroit Lions — one of the best running backs ever.

It was shocking news — to the extent that an athlete’s retirement can be considered “shocking” — when Sanders retired in 1998 because, at age 31, he was at the peak of his career, and on the verge of breaking the all-time NFL rushing record.

Some Lions fans — to this day — still expect him to change his mind and play again.

What Sanders Said

Sanders has an “as told to” autobiography coming out, in which he says that he retired, not — as the above headline says — because the Lions weren’t winning (which they weren’t), but because of his realization that the management of the team no longer cared about winning.

Big difference.

Here’s what he says in the book:

“That realization trivialized everything I did during the off-season to prepare myself. It trivialized everything I dreamed about from the time I was a kid in Wichita . . .”

It’s very similar to something DeMarco and Lister said in Peopleware:

Most forms of teamicide do their damage by effectively demeaning the work, or demeaning the people who do it. Teams are catalyzed by a common sense that the work is important and that doing it well is worthwhile.

People want to do great work. People are dying for opportunities to do great work.

I wish this information could somehow be implanted into the brain of every IT manager.

Thus spoke The Programmer.

Most of my illustrious career has been spent working or consulting for Fortune 1000 companies. These companies are fundamentally dependent on their computer systems, particularly their online systems, to transact business.

If the systems are down, the business stops running.

In fact, the systems don’t even have to be down to create havoc.

What if the response time is too slow? If you’ve ever done user testing with people whose job it is to enter money-making financial transactions for large corporations, you may have been amazed, as I was, at how fast they are.

Obviously then, the software you build for them has to be even faster; split-second response time is required. If your software is slowing people down, the business is losing money.

Or what if people are sitting around staring at their monitors because they can’t figure out how that great new interface you gave them is supposed to work?

Bad news.

Again there’s a measurable loss of revenue. Because these people are not supposed to be staring at their monitors, they’re supposed to be entering those money-making financial transactions, remember?

I could go on with this, but I think we both get the point: As a technologist working with these companies, you’re held to an exacting standard, because the cost of failure is high.

For example . . .

One evening many years ago, I put a software upgrade into production for a client, a major electronics distributor.

It was a pretty straightforward upgrade and we tested it, but I guess we didn’t test it diligently enough on certain boundary cases, because when I came in the next morning, I was informed that our “upgrade” had crashed, preventing the online system from coming up for an hour until it could be backed out and order was restored.

In other words, we had effectively put the company out of business for an hour, a really expensive mistake. I was further informed that the CIO wished to talk with us in his office once he was finished getting his ass kicked by executive management.

Well, my dick was limp, I’ll tell you.

I took a moment to divide the company’s annual revenue by the number of business hours in a year. According to my calculations, this fiasco had cost about $250,000.

I popped another Xanax and washed it down with a pot of coffee to keep from passing out. I was twitching like a chicken for hours.

Yes, and thanks to experiences like that, I now consider myself a seasoned developer. I try to anticipate the consequences of technical decisions early in a project in an effort to avoid downstream catastrophes.

But I don’t work on mission-critical applications now.

I work on Web applications.

And with different kinds of applications come different kinds of developers.

Most Web developers have worked exclusively on systems where the cost of failure is very low, so they rarely ponder the implications of technical decisions in great detail.

Why bother? What’s the worst thing that could happen?

Well, the Web site could have unpredictable access times, it could scale poorly, users could be unable to navigate the interface.

But so what?

As I write this, people still expect Web sites to have unpredictable access times, to scale poorly, and to have confusing interfaces.

Developers aren’t penalized for this; it’s all factored into the equation, as though improving the situation is beyond human capacity.

He who pays the piper is calling for a low-quality tune.

— DeMarco and Lister, Peopleware

Okay, part of the problem is that most clients either don’t know any better or aren’t willing to pay for better.

And, you might say, why should they when users are still more than willing to forgive them for mediocrity?

But here’s the real problem:

Very few Web developers have had the edification that comes from blowing away a quarter of a million dollars of someone else’s money in an hour, not to mention the resulting shitrain that descends over the land.

Because if they had, they’d be a little more careful next time.

Massive accountability

Here’s a fun story about the benefits of really holding people accountable for shoddy workmanship.

In The Innocents Abroad, Mark Twain wrote about King Xerxes, who in the 5th Century BC ordered a bridge of boats to be built across the Hellespont:

A moderate gale destroyed the flimsy structure, and the King, thinking that to publicly rebuke the contractors might have a good effect on the next set, called them out before the army and had them beheaded. In the next ten minutes he let a new contract for the bridge. It has been observed by ancient writers that the second bridge was a very good bridge.

Res ipsa loquitor.

Thus spoke The Programmer.