Author Archive: The Programmer

Setting Expectations

 

A family member had surgery recently and had to sign a consent form: I have been advised that all surgery involves general risks, including but not limited to bleeding, infection, nerve or tissue damage and rarely, cardiac arrest, death or other serious bodily injury. I acknowledge that no guarantees or assurances have been made as to the results that may be obtained. And so on . . . Don’t say you weren’t warned! Medical professionals are very good at setting realistic expectations with the customer, whereas in IT we take customers into projects with glib assurances and wishful thinking. I wonder if we could make a practice of saying to customers even something as simple as this: “This project — like all projects — has a number of possible outcomes, and not all of them are good. Let’s go over some of the more likely scenarios . . .” Thus… Read more →

10 Best Questions to Ask at the End of a Talk When You Absolutely Have To

 

From Bertrand Meyer: You know the feeling: You’ve accepted to chair a session at a technical conference, you’ve managed to keep the speakers on time, and a talk has just finished. “Any questions?” asks the speaker, met only by stunned silence. It’s your job as Chair to fill in, and you have no idea what to ask. Here, as a service to the community, is the list of the Ten Best Questions To Ask At The End Of A Talk When You Absolutely Have To: 10. When do you come up for tenure? 9. This doesn’t look like PowerPoint. What presentation software are you using? 8. Very interesting theorem you just proved on the last slide. It’s lemma 2 in chapter 1 of my 1977 thesis. 7. I like your accent. Where did you learn English? 6. Who does your hair? 5. On slide 2, what did Lambda stand for?… Read more →

The Waterfall Approach Persists as an Urban Myth

 

Much of present-day software acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software acquisition problems spring from that fallacy. — Fred Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering” We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM’s Service Bureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural . . . All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities. I think what the waterfall description did for us was make us realize that we were doing something else, something… Read more →

99 Rules

 

Here’s a short excerpt from an article called “Ninety-Nine Rules for Managing ‘Better, Faster, Cheaper’ Projects” by Alexander Laufer and Edward J. Hoffman: In a dynamic environment, project management is not about performing according to plan, with minimal changes. It is about meeting customer needs, while coping successfully with unavoidable changes. Therefore, the planning system should be capable of coping with changes. Jesus Christ, if I could articulate even one rule that perfectly, I’d publish it and call it a day . . . but there are 98 more of these! Here’s another one: More paperwork does not ensure greater information reliability or accuracy — it only adds to the non-value-added cost. It only seems that adding more measurement and reporting means better control. The illusion of control may partially explain an obsession with control. A must read! Thus spoke The Programmer. Read more →

Job Posting of the Week

 

6 Programmer Analysts with Java, J2EE, Weblogic, Websphere (before Java you should have programmed in C++ not VB or Visual Basic) I don’t entirely share the author’s view that programmers can be ordered up like pizzas — Java, C++, hold the VB — and I would point out, sadly, that the hiring path for developers is now littered with jackasses who don’t know that VB and Visual Basic are the same thing . . . Thus spoke The Programmer. Read more →

Women Leaving IT Considered Discouraging?

 

Women represent nearly half the workers in the U.S. — 46.6 percent. However, they always have been underrepresented in I.T. Even more discouraging is the fact that the percentage of women working in I.T. jobs is not growing but dropping. — Why Women Leave I.T. Why is that discouraging? Who exactly is discouraged by it? Here’s a simple explanation: Maybe women don’t want to work in IT. Is there nothing more rewarding that a woman can do with her life than work in IT? IT in the post-dot-com era is a stagnant industry. A lot of people in it would like to get out of it, but they need the money. I don’t encourage my son to get into it, nor would I encourage my daughter to get into it, if I had one . . . Thus spoke The Programmer. Read more →

Disorganization

 

We’re trying to figure out a directory structure that lets us organize project documents in a way that’s less confusing than the current directory structure. We’ve got a lot of documents and nobody can find anything when they need it. Thinking outside the box for a minute, maybe a better question would be: Do we really need to produce this many documents? Thus spoke The Programmer. Read more →

Soul-Crushing Email of the Day

 

I swear to God this is a real email from a once-promising manager with degrees from Brown and Princeton, who recently accepted a new position as Chief of Staff to the CEO, and now uses her Ivy League education to put out emails like this: Effective immediately please ensure that all written communications at [insert company name here] have a minimum font size of 12. In particular, [insert CEO’s name here] has asked me to convey that he will be ‘throwing away’ any communication he receives (over email or on paper) that does not meet this criteria [sic]. Please call me with any questions or comments, and hope everyone has a great weekend! I always say if you’re going to misuse the word “criteria,” at least do it in a highly readable 12-point Verdana font . . . Thus spoke The Programmer. Read more →

Completion Percentages

 

It ain’t over till it’s over. — Yogi Berra A project manager reports that her project is “48 percent complete.” In terms of what, I wonder? Calendar time? Cost? Effort? I know it’s not 48 percent complete in terms of functionality because there hasn’t been any working code delivered, just a bunch of documents. One approach that makes sense to me is to express completion percentages in terms of implemented requirements. For example, if you have 100 functional requirements, and 48 of them have been successfully implemented, then you’re 48 percent complete! Actually, I oversimplified that a little . . . All requirements are not created equal: Because some requirements cost more to implement than others, and some requirements have a greater business value than others, you could assign relative cost and relative value numbers to each requirement, and calculate completion percentages accordingly. This is good both for measuring the… Read more →

Profiles in Management: The Baffled Bigwig

 

Our Sr. EVP dropped by today for a meet and greet . . . he was 45 minutes late, and when he arrived, it was obvious he had no idea who he was talking to. “Is this the IT group?” he asked. It was explained to him that some of the people were from IT, but some were from the call center and tech support. “And do they all report to you?” he asked the senior manager in the room. Here’s a little trick I’ve picked up over the years: When you’re addressing a group of people, take a few minutes beforehand to learn who they are. It will make them feel less insignificant. After this fiasco, he went off to a catered meeting with other highly compensated executives, and I went out to buy my own lunch. Prediction: This meet and greet will be mentioned in at least two… Read more →

Two Simple Rules

 

More software projects have gone awry for lack of calendar time than for all other causes combined. — Fred Brooks, The Mythical Man-Month As a corollary to this, I’d say that lack of calendar time very often forces us to admit that our projects have gone awry. Denial is a viable strategy when delivery dates are far in the future, but when the deadline is staring you right in the teeth, the time for sunny optimism is over and the time for the Day of Reckoning (DoR) meeting is at hand. I attended one such DoR meeting yesterday afternoon . . . This particular meeting broke down into a battle between the Designers and the Implementers. The Designers — who happen to be the more senior members of the team — felt that they had written the specs in such excruciating detail that the system should pretty much have coded… Read more →

Man Plans, God Laughs

 

Man plans, God laughs. — Yiddish proverb A VP has asked me to review a Microsoft Project schedule printed out on 16 legal-size pages. The first thing that jumps out at me is that the level of detail in the schedule far exceeds the quality of information we have about the state of the world and the project at the future dates and times represented. I don’t see how you can break tasks down to this level of detail, add in dependencies, and state that Task XYZ is going to start at 2 o’clock in the afternoon on some date 14 months from now. And I would say that if the success of your project depends on your ability to forecast the future to that degree of precision, you are DOOMED from the outset . . . Thus spoke The Programmer. Read more →

Inspired Idiocy

 

It’s amazing how much havoc a person can wreak in the workplace by applying a certain kind of inspired idiocy to every situation: follow all procedures to the letter, do exactly what you’re told, and respond to all questions exactly as asked. One-word answers are ideal. The latter technique is especially effective via email. Thus spoke The Programmer. Read more →

High-Visibility Management

 

A friend of mine asked me the other day, “Do you think an organization really values a good manager?” He asked me that because he’s moving from a position as lead developer on a high-visibility system (lots of job security) to a position managing the developers of that system. And I had to say that in general, I think the answer is no, which is why you see managers generating a lot of useless paperwork to make their work visible: project plans, Gantt charts, spreadsheets, flowcharts . . . Does this help? I haven’t found that it does, but it does provide an illusion of control and an acceptable way of failing: the manager can point to all the paperwork and say, “Well, I followed the accepted process right down the line, so the fact that we failed can’t be my fault!” An analogy Our local basketball team is coached… Read more →

A Tradeoff

 

Do you want innovation? What are you willing to give up in terms of efficiency, predictability and control? Thus spoke The Programmer. 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 →

Like Father, Like Son?

 

The number of students majoring in computer science is falling, even at the elite universities. So [Bill] Gates went stumping at the University of Illinois at Urbana-Champaign, Carnegie Mellon, Cornell, M.I.T. and Harvard, telling students that they could still make a good living in America, even as the nation’s industry is sending some jobs, like software programming, abroad. — The New York Times, “Microsoft, Amid Dwindling Interest, Talks Up Computing as a Career” My brother is a doctor. He doesn’t encourage his kids to go into medicine though, because he’s incredibly frustrated by the fact that you go to school for 20 years to learn something, only to have clerks from insurance companies decide if a procedure you’ve recommended is or is not “medically necessary.” I’ve worked in computing for 20 years. I don’t push my kid to get into it because during that time, it’s become less and less… Read more →

Leadership Questions

 

Do you find that when one person is appointed Leader, other people in the group then expect the Leader to do things that they could do perfectly well for themselves? That they expect the leader to function as a sort of surrogate parent or playground monitor? If you are the Leader, what, if anything, do you do to encourage or discourage this? Thus spoke The Programmer. Read more →

High Failure Rates on the Web

 

. . . when public website users perform simple Internet tasks, they’re successful two-thirds of the time on average. In other words, users fail 35% of the time . . . Six sigma tolerates no more than 3.4 defects per million manufacturing opportunities; in contrast, the Web generates 350,000 defects per million interaction opportunities. The difference between the two quality levels is a factor of 100,000. — Jakob Nielsen, “Two Sigma: Usability and Six Sigma Quality Assurance” The only reason the Web works at all is that people are flexible and persistent enough to try again when their first attempt fails. The good news, I suppose, is that the opportunity for improvement is virtually limitless. Thus spoke The Programmer. 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 →

« Previous PageNext Page »