As part of a presentation I’m putting together on managing software projects, I want to talk a little bit about what not to do and how things can go spectacularly awry. A great recent case study for this is the FBI Virtual Case File system, cancelled last year after spending over $100 million. The original slide I put together (click to enlarge) showed the basic facts of the case illustrated with a photo of a rocket sled crashing into a wall. The heading I put on there — “Another fine mess” — didn’t seem to add anything to the mix, and I couldn’t think of a better one, so I started to think about other ways to lay out the slide. In the second version, I dropped the header, used the rocket sled photo as the background, and overlaid the text on top of it. I think it came out… Read more →
EppsNet Archive: Software Development
A Methodology Question
Let’s say your software development methodology tells you to do A, then B, then C, then D, and so on, until you get to Z, at which point, you’re done. And let’s say you do A, then B, then C, then D, and you notice that your project is not going according to plan for reasons that appear to be related to the methodology. What do you do? Do you forge ahead with E, F and G, even though that now looks like the wrong thing to do? If you’re committed to the methodology, you have to, right? Or — do you fall back on the knowledge and experience of the project manager and the project team, and rely on them to do the right thing? And if you can rely on the knowledge and experience of the project team now, what was the point of the methodology in the… Read more →
Goofus on Software
Goofus sends out an email to the team stating that the company is going to decommission the custom CRM we just spent 18 months building and replace it with Seibel. Five minutes later, here comes a reply from a troublemaker: “So why did we build the custom CRM in the first place? Just asking . . .” Goofus replies: “Siebel was not on the company roadmap at that time.” Note that he completely sidesteps the actual question of why we answered a Build-or-Buy question by deciding to build a system, only to immediately thereafter buy a new system to replace it. Goofus didn’t get to be a superstar in this organization by being unable to serve up bland, poker-faced responses to provocative questions. Read more →
The Seven Wastes of Software Development
The seven wastes of software development are: Partially Done Work (the “inventory” of a development process) Extra Processes (easy to find in documentation-centric development) Extra Features (develop only what customers want right now) Task Switching (everyone should do one thing at a time) Waiting (for instructions, for information) Handoffs (tons of tacit knowledge gets lost) Defects (at least defects that are not quickly caught by a test) — Mary Poppendieck, “Lean Software Development” Read more →
Leaders Who Don’t Care About People
Leaders who don’t care about people don’t have anyone to lead, unless their followers don’t have a choice. — Jerry Weinberg, Becoming a Technical Leader Read more →
Four Questions to Ask a Hiring Manager
I’m rereading parts of The Psychology of Computer Programming and I notice that several of Weinberg’s “food for thought” questions at the end of each chapter would be good questions to pose to a hiring manager: How long have you been in charge of your present group? How many of the original people remain? How many people have left and what were the reasons for their departure? What sort of provisions do you make for this kind of turnover? Describe the sequence of work planned for your current project. Is the actual work proceeding according to the original plan? Do you expect it to continue in this manner? How close is your progress reporting scheme to the reality of the work that goes on? What checks do you have to find out if it corresponds to reality? What is your impression of what motivates your staff? Is it the same… Read more →
How Did Peopleware Become a Best-Seller?
I don’t know how Peopleware became a best-seller. . . . I hardly run into any managers who read about their industry, management theory, or psychology, period. I used to believe that they were overloaded with information regarding the specifics of their job, but frankly, managers still aren’t trained, or do not educate themselves, to do their jobs. — Brian Pioreck Read more →
Dishonest Estimation
I saw the following attributed to Ralph Johnson. I’m not sure if that’s the Gang of Four Ralph Johnson, but it probably is: The problem is that almost all software schedules and budgets are bogus. They are created for political effect and have little relationship to reality. Thus, whether they are met has nothing to do with the people working on the project. Who makes your schedules? Project managers? They are almost certainly the wrong people. You can’t predict how long something will take unless you are an expert at doing it. The programmers? Are they allowed to say “we don’t have enough information to make a prediction”? Are they ever told “that is too long, you’ll have to do it in six months”? The only way to get honest schedules is from people who have experience in doing the work who know that they need to get the schedule… Read more →
Massive Accountability
Maybe you’ve noticed that most software sucks. Maybe you’ve wondered — if you work in the software business — why our aspirations are so low compared with the possibilities of our profession. Maybe you’ve wondered what, if anything, could be done about this. Here’s a fun story about the benefits of really holding people accountable for the shoddy quality of their work. 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… Read more →
Beware Metrics
Beware metrics. We are enamored with them from the days of waterfall, when we couldn’t tell what was going on until the end of the project. So, we devised metrics to attempt to read the tea leaves of what might be going on so we could get early warnings. Earned value is a great example of this. Also, we developed metrics to prove that things were improving to our customers even though over 1/2 of our projects failed. See, we are getting better, so leave us alone and please don’t fire us. — Ken Schwaber Read more →
Our Competitors are Still Sucking Their Thumbs
We made mistakes. Most of them were omissions we didn’t think of when we initially wrote the software. We fixed them by doing it over and over, again and again. We do the same today: While our competitors are still sucking their thumbs trying to make the design perfect, we’re already on prototype version No. 5. By the time our rivals are ready with wires and screws, we are on version No. 10. It gets back to planning versus acting: We act from day one; others plan how to plan–for months. — Michael Bloomberg, Bloomberg by Bloomberg Read more →
The Legacy of Waterfall
We are so unprofessional it is incredible. The legacy of waterfall is so dominant it is scary. — Ken Schwaber Read more →
A Rule of Thumb on Documentation
As a rule of thumb, I’d guess that 90 percent of what a team knows would be lost if they tried to write it down, and that 90 percent of what they wrote down would be lost when some other team tried to read it. But then, I’m an optimist. — Ron Jeffries Read more →
Cannot Measure Productivity
I can be pretty confident that a 100 KLOC system is bigger than a 10KLOC system. But if I’ve written the 100KLOC system in a year, and Joe writes the same system in 10KLOC during the same time, that doesn’t make me more productive. Indeed I would conclude that our productivities are about the same but my system is much more poorly designed. Assuming an accurate FP [function point] counting system, if I spend a year delivering a 100FP system and Joe spends the same year delivering a 50FP system can we assume that I’m more productive? I would say not. It may be that of my 100FP only a 30 [sic] is actually functionality that’s useful to my customer, but Joe’s is all useful. I would thus argue that while my direct productivity is higher, Joe’s true productivity is higher. But all of this ignores the point… Read more →
Why Good Projects Fail Anyway
A September 2003 Harvard Business Review article, “Why Good Projects Fail Anyway” by Nadim Matta and Ronald Ashkenas (free summary here), says that the high failure rate of major projects — not just IT projects — suggests that either these projects are inherently unmanageable or else something is wrong with the standard approach to project management. Matta and Ashkenas argue that the standard project management model is designed to control “execution risk” — the risk that designated activities won’t be carried out properly — by means of project plans, timelines, and budgets, but ignores two other equally important risks: 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 →
I Am 90 Percent Confident!
If by “90 percent confident” you mean “30 percent confident.” Key takeaway: We are conditioned to believe that estimates expressed as narrow ranges are more accurate than estimates expressed as wider ranges. We believe that wide ranges make us appear ignorant or incompetent. The opposite is usually the case. — Steve McConnell, Software Estimation: Demystifying the Black Art 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 →
Respect the Classics, Man: No Silver Bullet
This essay by Turing Award-winner Fred Brooks is almost 20 years old now. Sadly, the ideas on incremental development are still considered outside the mainstream in IT, which continues to favor the widely-discredited waterfall approach. Read more →
Better, Faster and Cheaper?
Somehow we’ve got it in our heads that every programmer in India is good, fast, and cheap, and every programmer in the United States is lousy, slow, and expensive. My theory is that for version 1.0 of a product, the maximum allowable distance between the engineers and marketers is thirty feet. — Guy Kawasaki Read more →