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… Read more →
EppsNet Archive: Tom DeMarco
The Can Do Manager
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 Read more →
Barbie Speaks
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?” Read more →
Administrivia
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 Read more →
Shibboleths
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. Read more →
The Comfort of Methodology
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… Read more →
Management 101: How to Demoralize Your Top Performers Into Early Retirement
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… Read more →
The Programming Circus
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… Read more →