EppsNet

To understand control’s real role [in software development], you need to distinguish between two drastically different kinds of projects:

• Project A will eventually cost about a million dollars and produce value of around $1.1 million.

• Project B will eventually cost about a million dollars and produce value of more than $50 million.

What’s immediately apparent is that control is really important for Project A but almost not at all important for Project B. This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value.

To my mind, the question that’s much more important than how to control a software project is, why on earth are we doing so many projects that deliver such marginal value?

— Tom DeMarco, “Software Engineering: An Idea Whose Time Has Come and Gone?”, IEEE Software, July/August 2009

Staring your boss in the face and saying June 1 when you know that even a year from June would be optimistic sounds bad. It sounds like lying. But being a Can Do manager sounds good.

— Tom DeMarco, Slack

I’m listening to an online interview with Kent Beck, Cynthia Andres and Tom DeMarco. My son hears Andres’ voice and says, “You’ve got a woman teaching you about technology?!”

“What a sexist you are,” I say.

“I’m just repeating what you always say: ‘Oh, women don’t know anything about computers.’”

“When did I ever say that?”

“You say it all the time. ‘Men are a lot smarter than women.’”

I deny this vehemently, and not just because my wife is sitting across the room.

Meanwhile, Andres is saying something: Blah blah blah Kent blah blah blah . . .

“Ken!?” the boy says. “Who’s advising you? Barbie?”

So much of our developers’ time is wasted by managerial fiat that some days they can’t get a damn thing done. One manager asked me in exasperation “Why can’t my people ever get through their work on time?” And my answer, after observing his organization for a while was that they couldn’t get through their work because most days they never even got to their work. They were too busy doing all the administrivia that he and the organization had imposed upon them.

— Tom DeMarco

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

Ill-specified systems are as common today as they were when we first began to talk about Requirements Engineering twenty or more years ago. Yet the task of creating complete and perfect specifications is not rocket science. We have adequate and comprehensible theories at our disposal for specification of finite state automata. We have proceeded over the past decades to develop and refine a discipline of applying these theories to real-world systems. In our methodological focus, we may have lost sight of some endemic problems that plague not the process but the people who do the process. Is it possible that an engineering approach to requirements is as badly suited to our real need as would be an engineering approach to raising teenagers? I’m beginning to think so . . .

— Tom DeMarco, “Requirements Engineering: Why Aren’t We Better at It?”, 2nd International Conference on Requirements Engineering

There are zillions of books on how to raise kids, and I think my wife has read most of them, along with countless magazine articles . . .

In fact, she’s far more open to taking child-rearing advice from books and magazines than she is from me, despite the fact that none of the authors has ever met our kid, and can therefore offer no insight into our particular situation.

But how comforting must it be to think that there’s a “methodology” for raising kids or for building good software — that someone has already solved all the hard problems for us . . . that we don’t have to rely solely on our own judgment to make critical decisions when we have only a limited amount of time, a limited amount of information, and no certain knowledge of the consequences . . .

Thus spoke The Programmer.

Related Links

• Peopleware
  If I could require that everyone in the IT business read one book, this would be it. Tom DeMarco (see above) is one of the co-authors.

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.

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.