You’re working on the requirements for Project X? Boring. You’ve got someone figuring out architecture for Project Y? Boring. The guys are designing Project Z? Boring. . . . Who has built something that their customer will certify is part of what they want? That’s interesting. Who has shipped something to their customer and the customer is using it? That’s very interesting. — Ron Jeffries Read more →
EppsNet Archive: Software Development
We Don’t Have the Money, So We Have to Think
We don’t have the money, so we have to think. — Ernest Rutherford Ernest Rutherford was an illustrious scientist — the 1908 Nobel Laureate in Chemistry, and the father of nuclear physics. His humble upbringing as the fourth in a family of 12 children in rural New Zealand influenced his approach to science, as summarized in the above quote. A recruiter called me today about a job managing an $80 million IT project. How in the world can you spend $80 million on an IT project?! I could put your company logo on Mars for $80 million. Most of the big, expensive IT projects that I’m familiar with, there really was no reason for them to take so long or cost so much. A lot of time and money could have been saved with some upfront thinking. I get a lot of this now — recruiters asking me if I… Read more →
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 →
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 →
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 →
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 →
Use the Database
It seems like a shame to have to even talk about this, but I really have found myself having way too many discussions over the years about how to avoid the use of relational databases. Today we were talking about replacing database reads and writes in a system design with file system access, XML, just floating the data around in memory, or some combination of the above. “What time of day will this system be running?” the DBA asked. “During business hours.” That’s right! We’re actually planning to do a database write in the middle of the workday! Why the thought of doing this freaks people out to the degree that it does is something I’ve never been able to figure out, but there’s an idea that persists among the less educated that read-only production access during the business day will max out an RDBMS. Look . . . a… 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 →
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 →
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 →
Profiles in Management: The Tank Commander
In the military, when I was in tank warfare and I was actually fighting in tanks, there was nothing more soothing than people constantly hearing their commander’s voice come across the airwaves. Somebody’s in charge, even though all shit is breaking loose. . . . When you don’t hear [the commander’s voice] for more than fifteen minutes to half an hour, what’s happened? Has he been shot? Has he gone out of control? Does he know what’s going on? You worry. And this is what Microsoft is. These little offices, hidden away with the doors closed. And unless you have the constant voice of authority going across the e-mail the whole time, it doesn’t work. . . . You can’t do anything that’s complex unless you have structure. . . . And what you have to do is make that structure as unseen as possible and build up the image… 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 →
Overheard
A project manager talking to a business analyst: PM: Can you have that done by today? BA: No I can’t, and here’s why. [Lengthy explanation deleted.] I can have it done by next week. PM: Can you have it done by tomorrow? Read more →
We Set Our Sights So Low
I think it’s such a shame we set our sights so low. Either you’re stuck with software that works the way it works because you don’t want to break it, or you get an upgrade that causes pain and anguish. I just want my stupid computer to work and it doesn’t. That’s not computing. That we accept the status quo says such negative things about us as humans . . . Our ambitions are so, so small compared to the opportunity. — Kent Beck Read more →
Good News, Bad News
After more than two months out of work, The Programmer lands a consulting job . . . Good news: I get paid and I need the cash. Bad news: I work for a guy who delivers insights like “See, now it’s not just about working better-faster-cheaper, it’s about working smarter!” in the tone of someone who just found a cure for cancer, or who thinks that without him, we’d all be actively seeking out ways to work stupider. More good news: He doesn’t micromanage my work, because he has no comprehension of what it is I actually do. Thus spoke The Programmer. Read more →
Talking to Recruiters
The Programmer has been out of work for more than two months now . . . A recruiter called me the other day, and in the course of our conversation, he asked me which “business requirements methods” I’ve used. I said, “I’m not exactly sure what you mean by that.” After a pause, he said, “I’m not really sure what it means either. I’m kind of new at this.” “Well, go ahead and read the next question, then . . .” Thus spoke The Programmer. Read more →
Getting Tired
The Programmer has been out of work for three weeks now . . . I’m getting tired of trying to sell myself to people who don’t seem to understand what it is I do, outside of how well I “fit” into a narrow job description. I’m getting tired of working in a broken industry. More generally, I’m sick and tired of people and their goddamn opinions about everything. And I’m getting pretty sick and tired of myself, too . . . Thus spoke The Programmer. Read more →