Slashdot Mirror

nossim writes "When it comes to developers' productivity, numerous controversial studies stress the differences between individuals. As a freelance web developer, I've worked for a lot of companies, and I noticed how some companies foster good practices which improve individual productivity and some others are a nightmare in that regard. In your experience, what are the worst practices or problems that impede developers' productivity at an individual or organizational level?"

Jason Bennett has returned with a review of Mark Minasi's The Software Conspiracy. The book is basically a well-informed perspective of the state of the software industry - how it functions, what it does, and what's really going on. Click below to learn more.

The Software Conspiracy author Mark Minasi pages 271 publisher McGraw-Hill, 09/1999 rating 8/10 reviewer Jason Bennett ISBN 0071348069 summary A non-technical (but well-informed) telling of the state of the software industry

Background

A short digression before I start my review of this quite interesting book. I had the privilege of spending a few days in Seattle at a Construx Software training event on OOA/OOD using UML (hi, ImageX!). Amazingly enough, seven hours of flying each way will give one plenty of reading time, even including talking with those herding into the seats around you. Although I almost missed seeing my hometown Titans in the Super Bowl, I feel it was time well spent. Alas, I didn't get to see Steve, but maybe he'll email me if he reads this. :-)

Nevertheless, on to the business at hand. My book reviews have generally centered around the concept of software engineering, and how to apply its principles to development efforts. This week's book is more of a review of the state of the industry, and where the industry is trying to go. It should come as no surprise to most people reading this that the picture is not particularly pretty. There is, however, a glimmer of hope, but only if we can shake off the combined forces of greed and apathy. Hey, I never said it was going to be easy! <g>

What's the book about?

I believe the book's subtitle just about sums it up: "Why software companies put out faulty products, how they can hurt you, and what you can do about it." As I said in the summary, this book is geared toward non-technical software users in an attempt to explain to them why their software breaks, and why they shouldn't take it anymore. Many parts of this book will be well-known to regular Slashdot readers, but I dare say there are parts that will raise your hackles, regardless.

Chapter 1 is more or less an overview of the theme of the book: that software bugs are bad, that consumers and the media tolerate those bugs to an unreasonable extent, and that those same consumers must act to stem the trend toward more broken software. I'll address his on-point evidence as I discuss the following chapters.

Chapter 2 addresses an important, if not always obvious question: why do software bugs exist in the first place? The short answer is that it's difficult to think of every possible interaction and exception when devising an algorithm. The author employs some interesting mental experiments in the process of the discussion to make this fact more evident to non-programmers. He also mentions some historically important bugs (including the recently-historical Y2K). So far, nothing earth shattering....

With Chapter 3, the journey moves from easy to confrontational. To sum the chapter's theme in one sentence, software is buggy because programmers are slack and customers are more slack. As a counterpoint to the oft-heard statement, "Bug-free software is impossible," Minasi examines the Capability Maturity Model in detail, including how it has been shown to reduce error rates, and why most firms do not employ it. You won't feel complimented by this explanation. In short, most software firms don't try very hard to keep defects out of their software because they expect defects to occur, and (according to one survey), 15% of software firms do not even bother to test their software at all before shipping. I'm always one to quote the adage about the three kinds of lies, but somehow I'm inclined to believe this one. Why don't firms test? Basically because they can get away with it, and programmers don't want to be told they've made a mistake. The argument that bug-free software is too expensive is, of course, the same argument the meat packing industry made at the end of the 19th century, that wholesome meat was too expensive and impossible to produce. Fortunately for everyone, that excuse was eventually put to rest. Minasi believes the software excuse should be equally put out of its misery. The author does make one point that I disagree with, however, in that he claims that process isn't really for "geniuses," only "regular" programmers. I would argue, however, that everyone needs process to channel whatever genius they may possess, and that structure does not stand counter to creativity. The author also addresses some of the shortcomings of the CMM, but in the end believes that the evidence behind process, any process, is overwhelming.

Chapter 4 moves into another arena near and dear to our hearts: UCITA. As I read this chapter, I kept finding my jaw hanging open in astonishment at the gall of the software industry and the law they have crafted. This book is fairly recent, and thus the information current, although I recommend checking Cem Kaner's site or Slashdot for the most recent information. I won't go into bloody detail here, but suffice to say under UCITA the software industry can disclaim all responsibility for their software, while simultaneously putting unreasonable restrictions on your usage of that software. Amazingly convenient, huh? You could also no longer treat software like a book, as the software industry would completely control the software even after you had purchased/licensed it. Needless to say, a raw deal for the consumer.

Chapter 5 proposes an interesting rehash of Yourdon's The Decline and Fall of the American Programmer. Now, before I proceed, I've never actually read that book, so this analogy is based on my understanding of Yourdon's thesis. Basically, Minasi compares today's software industry to the auto industry of the 1950's. At that time, cars had more or less reached technological maturity. Marketing ruled the industry, as all the car were more or less the same. Planned obsolescence was invented, and quality declined as more and more useless features (e.g. fins) were added to cars. Of course, we all know the end of that story. The Japanese car industry invaded and smacked Detroit around for a while before the American automakers were able to recover. Minasi proposes that the America software industry is in a similar situation today, and UCITA could exacerbate that tendency. Could another country's software industry rise up? Minasi doesn't really offer any competitors at this point, but the threat is certainly there.

Chapter 6 exhorts users to stand up for quality software, just as they would stand up for quality in other products. Write letters. Don't pay for bug fixes. Help stop UCITA. Nothing earth-shattering again, but important nonetheless.

Chapter 7, the conclusion, paints two pictures of the future, one rosy, where buggy software is brought under control, and one bleak. I won't spoil them for you, but suffice to say the bleak one might surprise you. In any event, and effective storytelling mechanism.

Finally, there is an appendix of how to fix you current software, or at least get around its problems. Programmers might scoff at the information contained therein, but your mother will likely find it useful.

What's Good?

If you don't want too technical of a read, and you're interested in why software is in its current state, this is an excellent and informative book. The rationale is sound, and the information on UCITA is important to educate others about its dangers, especially when the time comes for a vote in your state. In short, read this book if you're tired of crappy software, or you don't know why software is crappy.

What's Bad?

On the other hand, if you think process is silly, and you're doing the best you can, dangit, you won't enjoy this book. I would like to think that most open source proponents would understand the importance of testing, but then again I don't remember reading too many test plans for OS projects. Whatever. Regardless, this book might not be for you if you want a detailed, technical discussion of the state of software, and you're already well up on your UCITA info. YMMV.

So What's In It For Me?

Regardless of who you are, coder or suit, what this book discusses will impact you. The U.S. software industry is going to be fundamentally shaped for decades to come by what happens in the next few months and years. It behooves you to understand the implications of where we are going, regardless of where you stand on the issue.

• Table of Contents
• Introduction
  1. When Some Bugs Bite, They Kill
  2. Why Are There Bugs? How Defects Happen
  3. It Doesn't Take a Genius, It Just Takes a Process: Building Good Software
  4. Software and the Law
  5. Bugs and the Country: Software Economics
  6. Fighting Back: How to Improve Software
  7. The Future
• Appendix: Software Self-defense
• Endnotes
• Index

Jason Bennett has returned with a review of Mark Minasi's The Software Conspiracy. The book is basically a well-informed perspective of the state of the software industry - how it functions, what it does, and what's really going on. Click below to learn more.

The Software Conspiracy author Mark Minasi pages 271 publisher McGraw-Hill, 09/1999 rating 8/10 reviewer Jason Bennett ISBN 0071348069 summary A non-technical (but well-informed) telling of the state of the software industry

Background

A short digression before I start my review of this quite interesting book. I had the privilege of spending a few days in Seattle at a Construx Software training event on OOA/OOD using UML (hi, ImageX!). Amazingly enough, seven hours of flying each way will give one plenty of reading time, even including talking with those herding into the seats around you. Although I almost missed seeing my hometown Titans in the Super Bowl, I feel it was time well spent. Alas, I didn't get to see Steve, but maybe he'll email me if he reads this. :-)

Nevertheless, on to the business at hand. My book reviews have generally centered around the concept of software engineering, and how to apply its principles to development efforts. This week's book is more of a review of the state of the industry, and where the industry is trying to go. It should come as no surprise to most people reading this that the picture is not particularly pretty. There is, however, a glimmer of hope, but only if we can shake off the combined forces of greed and apathy. Hey, I never said it was going to be easy! <g>

What's the book about?

I believe the book's subtitle just about sums it up: "Why software companies put out faulty products, how they can hurt you, and what you can do about it." As I said in the summary, this book is geared toward non-technical software users in an attempt to explain to them why their software breaks, and why they shouldn't take it anymore. Many parts of this book will be well-known to regular Slashdot readers, but I dare say there are parts that will raise your hackles, regardless.

Chapter 1 is more or less an overview of the theme of the book: that software bugs are bad, that consumers and the media tolerate those bugs to an unreasonable extent, and that those same consumers must act to stem the trend toward more broken software. I'll address his on-point evidence as I discuss the following chapters.

Chapter 2 addresses an important, if not always obvious question: why do software bugs exist in the first place? The short answer is that it's difficult to think of every possible interaction and exception when devising an algorithm. The author employs some interesting mental experiments in the process of the discussion to make this fact more evident to non-programmers. He also mentions some historically important bugs (including the recently-historical Y2K). So far, nothing earth shattering....

With Chapter 3, the journey moves from easy to confrontational. To sum the chapter's theme in one sentence, software is buggy because programmers are slack and customers are more slack. As a counterpoint to the oft-heard statement, "Bug-free software is impossible," Minasi examines the Capability Maturity Model in detail, including how it has been shown to reduce error rates, and why most firms do not employ it. You won't feel complimented by this explanation. In short, most software firms don't try very hard to keep defects out of their software because they expect defects to occur, and (according to one survey), 15% of software firms do not even bother to test their software at all before shipping. I'm always one to quote the adage about the three kinds of lies, but somehow I'm inclined to believe this one. Why don't firms test? Basically because they can get away with it, and programmers don't want to be told they've made a mistake. The argument that bug-free software is too expensive is, of course, the same argument the meat packing industry made at the end of the 19th century, that wholesome meat was too expensive and impossible to produce. Fortunately for everyone, that excuse was eventually put to rest. Minasi believes the software excuse should be equally put out of its misery. The author does make one point that I disagree with, however, in that he claims that process isn't really for "geniuses," only "regular" programmers. I would argue, however, that everyone needs process to channel whatever genius they may possess, and that structure does not stand counter to creativity. The author also addresses some of the shortcomings of the CMM, but in the end believes that the evidence behind process, any process, is overwhelming.

Chapter 4 moves into another arena near and dear to our hearts: UCITA. As I read this chapter, I kept finding my jaw hanging open in astonishment at the gall of the software industry and the law they have crafted. This book is fairly recent, and thus the information current, although I recommend checking Cem Kaner's site or Slashdot for the most recent information. I won't go into bloody detail here, but suffice to say under UCITA the software industry can disclaim all responsibility for their software, while simultaneously putting unreasonable restrictions on your usage of that software. Amazingly convenient, huh? You could also no longer treat software like a book, as the software industry would completely control the software even after you had purchased/licensed it. Needless to say, a raw deal for the consumer.

Chapter 5 proposes an interesting rehash of Yourdon's The Decline and Fall of the American Programmer. Now, before I proceed, I've never actually read that book, so this analogy is based on my understanding of Yourdon's thesis. Basically, Minasi compares today's software industry to the auto industry of the 1950's. At that time, cars had more or less reached technological maturity. Marketing ruled the industry, as all the car were more or less the same. Planned obsolescence was invented, and quality declined as more and more useless features (e.g. fins) were added to cars. Of course, we all know the end of that story. The Japanese car industry invaded and smacked Detroit around for a while before the American automakers were able to recover. Minasi proposes that the America software industry is in a similar situation today, and UCITA could exacerbate that tendency. Could another country's software industry rise up? Minasi doesn't really offer any competitors at this point, but the threat is certainly there.

Chapter 6 exhorts users to stand up for quality software, just as they would stand up for quality in other products. Write letters. Don't pay for bug fixes. Help stop UCITA. Nothing earth-shattering again, but important nonetheless.

Chapter 7, the conclusion, paints two pictures of the future, one rosy, where buggy software is brought under control, and one bleak. I won't spoil them for you, but suffice to say the bleak one might surprise you. In any event, and effective storytelling mechanism.

Finally, there is an appendix of how to fix you current software, or at least get around its problems. Programmers might scoff at the information contained therein, but your mother will likely find it useful.

What's Good?

If you don't want too technical of a read, and you're interested in why software is in its current state, this is an excellent and informative book. The rationale is sound, and the information on UCITA is important to educate others about its dangers, especially when the time comes for a vote in your state. In short, read this book if you're tired of crappy software, or you don't know why software is crappy.

What's Bad?

On the other hand, if you think process is silly, and you're doing the best you can, dangit, you won't enjoy this book. I would like to think that most open source proponents would understand the importance of testing, but then again I don't remember reading too many test plans for OS projects. Whatever. Regardless, this book might not be for you if you want a detailed, technical discussion of the state of software, and you're already well up on your UCITA info. YMMV.

So What's In It For Me?

Regardless of who you are, coder or suit, what this book discusses will impact you. The U.S. software industry is going to be fundamentally shaped for decades to come by what happens in the next few months and years. It behooves you to understand the implications of where we are going, regardless of where you stand on the issue.

• Table of Contents
• Introduction
  1. When Some Bugs Bite, They Kill
  2. Why Are There Bugs? How Defects Happen
  3. It Doesn't Take a Genius, It Just Takes a Process: Building Good Software
  4. Software and the Law
  5. Bugs and the Country: Software Economics
  6. Fighting Back: How to Improve Software
  7. The Future
• Appendix: Software Self-defense
• Endnotes
• Index

Thanks to Jason Bennett for sending us a review of author Steve McConnell's lastest book After the Gold Rush. The book looks at the maturation of software development and what that means for us. Click below to read more. After the Gold Rush : Creating a True Profession of Software En author Steve McConnell pages 182 publisher Microsoft Press, 11/1999 rating 9/10 reviewer Jason Bennett ISBN 0735608776 summary One impression of the maturation of software development

Background

I've always been amazed that certain fields of endeavor exist in which many people prefer rank amateurs to trained professionals. I don't know many people who would choose their neighbor's kid to perform surgery, or hire a journalist to build a bridge, yet every day software development shops hire people whose only training is that they have read some book on Visual Basic or C++ or Perl, and put them to work on major projects. In fact, in the software development business, experience can sometimes be a liability (see the debate over immigrant programmers and age discrimination). Don't worry, you won't have to apply for a license to write code, and no one is going to confiscate your keyboard if you design your own web page. Accountability, however, is another story....

What's the book about? Steve McConnell, author of Code Complete , Software Project Survival Guide , and many other excellent books on software engineering, has returned. For those of you who might not be familiar with him, Steve is President and Chief Software Engineer of Construx Software, a software consulting firm based outside of Seattle. He's also the Editor in Chief of IEEE Software, and is generally regarded as one of today's best authorities on how to do software the right way. In After the Gold Rush, Steve gives his view of where the software world should go from here.

Currently, people don't know how to build software. Or, to be more accurate, there are good techniques out there to build software, but most people ignore them for one or more reasons, none of which hold up under close scrutiny. In addition, software development depends on death-march-style schedules, whereby programmers wreck themselves trying to get the software out the door at the appointed time. One major problem is that the developers are not trained in writing software in the first place. They are either trained in computer science, or some totally unrelated field. To compound this problem, very few if any continue their education in such areas as professional reading or training.

There is hope, however! Now that software development is moving out of its "gold rush" period, where the firstest gets the mostest, we can begin to develop software engineering as a profession. This means training people in engineering instead of science, and defining what it means to be a software engineer. Unfortunately, we have a lot of work to do both on the level of education, and in the mindset of today's software developers.

The third and final part of ATGR dwells on the future, especially as it relates to what these developments will mean for software developers of today. I'll spare you some of the suspense, and tell you that you won't be forced to be certified. Does anyone really care if your desktop clock was written by a true engineer? On the other hand, you bet I care that my air traffic control software and my medical scanning software and my car's control software were signed off on by someone who knows what he's doing. Licensing will be in software engineering what it is in other engineering fields: required in some areas, meaningless in others. In the end, however, software will be better for it.

What's Good?

Personally, I greatly enjoyed this book, mostly because it says what I've felt for some time now. The development of true software engineering will be akin to the development of true medicine. We will be able to move ourselves from the Age of Leeches to a more enlightened age where quality and process matter. McConnell makes a compelling case for why events will transpire in this way, and what the benefits are. No one thinks that these developments will be some sort of panacea or silver bullet, but when true software engineers, complete with a code of ethics and a professional organization, are responsible for developing software, there will exist an undercurrent of ownership and responsibility that currently does not exist.

What's Bad?

There's not much I didn't like about this book. If you develop software for a living, read this book. It describes where your industry is going in the next twenty years.

So What's In It For Me?

Maybe a lot, maybe nothing. If you develop your software purely as a hobby, these events won't directly effect you much. You will never need a license just to write code. If, however, you belong to that cadre of programmers that likes to think of themselves as "software engineers," or who would like to think of themselves as such, read this. You won't be forced to take a test tomorrow, but software development will never be the same.

Pick this up book up at ThinkGeek.

• Table of Contents
• Acknowledgments
• Introduction
  1. The Tar Pit
     1. Software Dinosaurs
     2. Fool's Gold
     3. Orphans Preferred
     4. Software Engineering Is Not Computer Science
  2. Prospecting
     1. After the Gold Rush
     2. Engineering a Profession
     3. Ptolemaic Reasoning
     4. Body of Knowledge
     5. Novum Organum
  3. Through the Pillars
     1. Stinking Badges
     2. Architects and Carpenters
     3. Hard Knocks
     4. The Professional's Code
     5. Alchemy
• Epilogue
• Notes
• Index

Thanks to Jason Bennett for sending us a review of author Steve McConnell's lastest book After the Gold Rush. The book looks at the maturation of software development and what that means for us. Click below to read more. After the Gold Rush : Creating a True Profession of Software En author Steve McConnell pages 182 publisher Microsoft Press, 11/1999 rating 9/10 reviewer Jason Bennett ISBN 0735608776 summary One impression of the maturation of software development

Background

I've always been amazed that certain fields of endeavor exist in which many people prefer rank amateurs to trained professionals. I don't know many people who would choose their neighbor's kid to perform surgery, or hire a journalist to build a bridge, yet every day software development shops hire people whose only training is that they have read some book on Visual Basic or C++ or Perl, and put them to work on major projects. In fact, in the software development business, experience can sometimes be a liability (see the debate over immigrant programmers and age discrimination). Don't worry, you won't have to apply for a license to write code, and no one is going to confiscate your keyboard if you design your own web page. Accountability, however, is another story....

What's the book about? Steve McConnell, author of Code Complete , Software Project Survival Guide , and many other excellent books on software engineering, has returned. For those of you who might not be familiar with him, Steve is President and Chief Software Engineer of Construx Software, a software consulting firm based outside of Seattle. He's also the Editor in Chief of IEEE Software, and is generally regarded as one of today's best authorities on how to do software the right way. In After the Gold Rush, Steve gives his view of where the software world should go from here.

Currently, people don't know how to build software. Or, to be more accurate, there are good techniques out there to build software, but most people ignore them for one or more reasons, none of which hold up under close scrutiny. In addition, software development depends on death-march-style schedules, whereby programmers wreck themselves trying to get the software out the door at the appointed time. One major problem is that the developers are not trained in writing software in the first place. They are either trained in computer science, or some totally unrelated field. To compound this problem, very few if any continue their education in such areas as professional reading or training.

There is hope, however! Now that software development is moving out of its "gold rush" period, where the firstest gets the mostest, we can begin to develop software engineering as a profession. This means training people in engineering instead of science, and defining what it means to be a software engineer. Unfortunately, we have a lot of work to do both on the level of education, and in the mindset of today's software developers.

The third and final part of ATGR dwells on the future, especially as it relates to what these developments will mean for software developers of today. I'll spare you some of the suspense, and tell you that you won't be forced to be certified. Does anyone really care if your desktop clock was written by a true engineer? On the other hand, you bet I care that my air traffic control software and my medical scanning software and my car's control software were signed off on by someone who knows what he's doing. Licensing will be in software engineering what it is in other engineering fields: required in some areas, meaningless in others. In the end, however, software will be better for it.

What's Good?

Personally, I greatly enjoyed this book, mostly because it says what I've felt for some time now. The development of true software engineering will be akin to the development of true medicine. We will be able to move ourselves from the Age of Leeches to a more enlightened age where quality and process matter. McConnell makes a compelling case for why events will transpire in this way, and what the benefits are. No one thinks that these developments will be some sort of panacea or silver bullet, but when true software engineers, complete with a code of ethics and a professional organization, are responsible for developing software, there will exist an undercurrent of ownership and responsibility that currently does not exist.

What's Bad?

There's not much I didn't like about this book. If you develop software for a living, read this book. It describes where your industry is going in the next twenty years.

So What's In It For Me?

Maybe a lot, maybe nothing. If you develop your software purely as a hobby, these events won't directly effect you much. You will never need a license just to write code. If, however, you belong to that cadre of programmers that likes to think of themselves as "software engineers," or who would like to think of themselves as such, read this. You won't be forced to take a test tomorrow, but software development will never be the same.

Pick this up book up at ThinkGeek.

• Table of Contents
• Acknowledgments
• Introduction
  1. The Tar Pit
     1. Software Dinosaurs
     2. Fool's Gold
     3. Orphans Preferred
     4. Software Engineering Is Not Computer Science
  2. Prospecting
     1. After the Gold Rush
     2. Engineering a Profession
     3. Ptolemaic Reasoning
     4. Body of Knowledge
     5. Novum Organum
  3. Through the Pillars
     1. Stinking Badges
     2. Architects and Carpenters
     3. Hard Knocks
     4. The Professional's Code
     5. Alchemy
• Epilogue
• Notes
• Index

SEGV has continued his tradition of excellent reviews with an examination of Jon L. Bentley's Programming Pearls (Second Edition), recently released by Addison-Welsey. One of the classics of programming, the new version continues the first edition's heritage of excellence. Click below to read more. Programming Pearls (Second Edition) author Jon L. Bentley pages 239 publisher Addison-Wesley, 10/1999 rating 10/10 reviewer SEGV ISBN 0-201-65788-0 summary A classic revised.

Choice and Precious

One definition of pearl is something "very choice or precious." Like the programming pearls it describes, Bentley's collection of essays has itself transcended the ordinary to achieve pearl status.

Originally published in Bentley's "Programming Pearls" column in Communications of the ACM, these fascinating essays were collected and revised in book form in 1986. Now revised 14 years later, this material has definitely stood the test of time. The first edition remains #2 on McConnell's Code Complete Reading List, and is listed favourably in an article on Great Books in Computer Science.

A Sense of Wonder

It was directly because of McConnell's Code Complete reading list that I, a few years ago, purchased and read Programming Pearls and its sequel, More Programming Pearls. Despite McConnell's effusive praise and corroboration from a colleague, I was not fully prepared for the experience.

I say experience, because that's what it was. It reminded me of reading Alice's Adventures in Wonderland [1] or Godel, Escher, Bach [2] (perhaps not coincidentally, also on the above list of great books in computer science). It filled me with a sense of wonder that is difficult to describe. It confirmed my love for computer science.

I believe that I am not alone in this regard.

What's New?

Twelve of the thirteen columns in the first edition have been edited substantially for this edition, and three new columns have been added. The new columns are on the topics of testing & debugging & timing, set representations, and string problems. This new edition is about 25 percent longer.

Although the first edition had been getting a little long in the tooth, the revisions once again place the essays in the modern world. Discussions of performance take into account modern hardware, caches, and instruction-level parallelism. Modern languages (C++, Java) are compared and contrasted where appropriate. Modern books (such as McConnell's Code Complete and Musser & Saini's STL Tutorial and Reference Guide [3]) are referenced and recommended.

Like Meeting an Old Friend

Re-reading this book was like meeting an old friend. Notwithstanding the major revisions, it has changed in subtle ways. Some anecdotes have been updated, some material reorganized. But it's still the same book. All of the energy and fun remains, youthful as ever.

I'm pleased to see that Bentley is still happy working at Bell Labs / AT&T / Lucent. Perhaps that's why this book is so great. There's a lot of intelligent people working there, and they put out some fine books. Bentley produces a Markov text generator in column 15, and compares it favourably to his colleagues' (Kernighan and Pike) version in the recent book The Practice of Programming [4].

Supporting Material

I must say that the supporting web site for this book (URL below) is excellent. It has all the information on why this book was updated, along with exactly what was revised. There the curious reader will find excerpts from columns, some problems and their solutions, and many other parts of the book available online.

All of the source code is available and free for use. Relevant web sites are linked and annotated. I love the Java applet that demonstrates sorting algorithms (source available!). Bentley even provides some overhead transparencies for use in teaching.

Recommendation

This is a no-brainer. I've always recommended reading this classic, and even re-reading it. The second edition is merely an excuse to purchase and (re-)read a revised copy. The time spent is well worth it. (Remember, only one column per sitting!)

I also recommend scrounging a copy of the sequel, which is out of print [5].

Purchase this book at fatbrain.

Links

Programming Pearls (Second Edition) Official Site

Programming Pearls (Second Edition) at Addison-Wesley

Programming Pearls (First Edition) at Addison-Wesley

More Programming Pearls: Confessions of a Coder at Addison-Wesley

Table of Contents

Part I: Preliminaries
1. Cracking the Oyster
2. Aha! Algorithms
3. Data Structures Programs
4. Writing Correct Programs
5. A Small Matter of Programming
Part II: Performance
6. Perspective on Performance
7. The Back of the Envelope
8. Algorithm Design Techniques
9. Code Tuning
10. Squeezing Space
Part III: The Product
11. Sorting
12. A Sample Problem
13. Searching
14. Heaps
15. Strings of Pearls
Epilog to the First Edition
Epilog to the Second Edition
Appendix 1: A Catalog of Algorithms
Appendix 2: An Estimation Quiz
Appendix 3: Cost Models for Time and Space
Appendix 4: Rules for Code Tuning
Appendix 5: C++ Classes for Searching
Hints for Selected Problems
Solutions for Selected Problems
Index

Notes

[1] Why do people (book sellers, web sites, bibliographies, etc.) insist on incorrectly calling this book Alice in Wonderland? It's not just for kids; Lewis Carroll was a mathematician, and it abounds in metaphor, puzzles, hidden treats. Read it. Accept only the John Tenniel illustrations!

[2] Godel, Escher, Bach: An Eternal Golden Braid is subtitled A Metaphorical Fugue on Minds and Machines in the Spirit of Lewis Carroll. It was reviewed on Slashdot: Godel, Escher, Bach (Review).

[3] However, use this book instead: Austern's Generic Programming and the STL.

[4] I reviewed this book for Slashdot: The Practice of Programming (Review).

[5] Why? I don't understand why some classics go out of print. I'm still trying to find copies of Artificial Life II, On Numbers and Games, Computation: Finite and Infinite Machines, and a host of others.

SEGV has continued his tradition of excellent reviews with an examination of Jon L. Bentley's Programming Pearls (Second Edition), recently released by Addison-Welsey. One of the classics of programming, the new version continues the first edition's heritage of excellence. Click below to read more. Programming Pearls (Second Edition) author Jon L. Bentley pages 239 publisher Addison-Wesley, 10/1999 rating 10/10 reviewer SEGV ISBN 0-201-65788-0 summary A classic revised.

Choice and Precious

One definition of pearl is something "very choice or precious." Like the programming pearls it describes, Bentley's collection of essays has itself transcended the ordinary to achieve pearl status.

Originally published in Bentley's "Programming Pearls" column in Communications of the ACM, these fascinating essays were collected and revised in book form in 1986. Now revised 14 years later, this material has definitely stood the test of time. The first edition remains #2 on McConnell's Code Complete Reading List, and is listed favourably in an article on Great Books in Computer Science.

A Sense of Wonder

It was directly because of McConnell's Code Complete reading list that I, a few years ago, purchased and read Programming Pearls and its sequel, More Programming Pearls. Despite McConnell's effusive praise and corroboration from a colleague, I was not fully prepared for the experience.

I say experience, because that's what it was. It reminded me of reading Alice's Adventures in Wonderland [1] or Godel, Escher, Bach [2] (perhaps not coincidentally, also on the above list of great books in computer science). It filled me with a sense of wonder that is difficult to describe. It confirmed my love for computer science.

I believe that I am not alone in this regard.

What's New?

Twelve of the thirteen columns in the first edition have been edited substantially for this edition, and three new columns have been added. The new columns are on the topics of testing & debugging & timing, set representations, and string problems. This new edition is about 25 percent longer.

Although the first edition had been getting a little long in the tooth, the revisions once again place the essays in the modern world. Discussions of performance take into account modern hardware, caches, and instruction-level parallelism. Modern languages (C++, Java) are compared and contrasted where appropriate. Modern books (such as McConnell's Code Complete and Musser & Saini's STL Tutorial and Reference Guide [3]) are referenced and recommended.

Like Meeting an Old Friend

Re-reading this book was like meeting an old friend. Notwithstanding the major revisions, it has changed in subtle ways. Some anecdotes have been updated, some material reorganized. But it's still the same book. All of the energy and fun remains, youthful as ever.

I'm pleased to see that Bentley is still happy working at Bell Labs / AT&T / Lucent. Perhaps that's why this book is so great. There's a lot of intelligent people working there, and they put out some fine books. Bentley produces a Markov text generator in column 15, and compares it favourably to his colleagues' (Kernighan and Pike) version in the recent book The Practice of Programming [4].

Supporting Material

I must say that the supporting web site for this book (URL below) is excellent. It has all the information on why this book was updated, along with exactly what was revised. There the curious reader will find excerpts from columns, some problems and their solutions, and many other parts of the book available online.

All of the source code is available and free for use. Relevant web sites are linked and annotated. I love the Java applet that demonstrates sorting algorithms (source available!). Bentley even provides some overhead transparencies for use in teaching.

Recommendation

This is a no-brainer. I've always recommended reading this classic, and even re-reading it. The second edition is merely an excuse to purchase and (re-)read a revised copy. The time spent is well worth it. (Remember, only one column per sitting!)

I also recommend scrounging a copy of the sequel, which is out of print [5].

Purchase this book at fatbrain.

Links

Programming Pearls (Second Edition) Official Site

Programming Pearls (Second Edition) at Addison-Wesley

Programming Pearls (First Edition) at Addison-Wesley

More Programming Pearls: Confessions of a Coder at Addison-Wesley

Table of Contents

Part I: Preliminaries
1. Cracking the Oyster
2. Aha! Algorithms
3. Data Structures Programs
4. Writing Correct Programs
5. A Small Matter of Programming
Part II: Performance
6. Perspective on Performance
7. The Back of the Envelope
8. Algorithm Design Techniques
9. Code Tuning
10. Squeezing Space
Part III: The Product
11. Sorting
12. A Sample Problem
13. Searching
14. Heaps
15. Strings of Pearls
Epilog to the First Edition
Epilog to the Second Edition
Appendix 1: A Catalog of Algorithms
Appendix 2: An Estimation Quiz
Appendix 3: Cost Models for Time and Space
Appendix 4: Rules for Code Tuning
Appendix 5: C++ Classes for Searching
Hints for Selected Problems
Solutions for Selected Problems
Index

Notes

[1] Why do people (book sellers, web sites, bibliographies, etc.) insist on incorrectly calling this book Alice in Wonderland? It's not just for kids; Lewis Carroll was a mathematician, and it abounds in metaphor, puzzles, hidden treats. Read it. Accept only the John Tenniel illustrations!

[2] Godel, Escher, Bach: An Eternal Golden Braid is subtitled A Metaphorical Fugue on Minds and Machines in the Spirit of Lewis Carroll. It was reviewed on Slashdot: Godel, Escher, Bach (Review).

[3] However, use this book instead: Austern's Generic Programming and the STL.

[4] I reviewed this book for Slashdot: The Practice of Programming (Review).

[5] Why? I don't understand why some classics go out of print. I'm still trying to find copies of Artificial Life II, On Numbers and Games, Computation: Finite and Infinite Machines, and a host of others.

In a truimphant sophmore return, Jason Bennett has sent us in a review of Software Project Survival Guide. Part of ongoing series of books reviwed by Jason, the goal is to walk through a number of valuable software engineering books. For the full scoop, check below. Software Project Survival Guide author Steve McConnell pages publisher Microsoft Press rating 9/10 reviewer Jason Bennett ISBN 1-57231-621-7 summary

Steve gives a good once-over of the software development process, and backs it up with good examples and on-line documentation.

Background

This being the second review in my series of software engineering books (process and management being key components of said concept), I thought it would be good to give an overview of where we are, and where we're going. Last week, we looked at Frederick Brooks' Mythical Man-Month , the seminal classic of software management. This week, we'll be looking at the latest book by a new classic author, Steve McConnell. Now, I might as well say right upfront that Steve is a Microsoftie (at least part-time). You can take that as praise or criticism, but it's truth nonetheless. Fortunately, Steve is above idol worship, and thus his books are quite palatable, even if you have to support the Evil Empire in the process. No matter who he consults for, however, Steve knows what he's talking about. In the end, that's what matters. We'll be staying in Steve country for this week and next (his Code Complete is next), after which we'll move on. For now, however, enjoy this review/summary of Software Project Survival Guide.

What's the book about?

To a large extent, this book is the culmination of many years of writing on Steve's part. His previous books are Code Complete, which focuses on the details of writing code well, and Rapid Development, which focuses on the software lifecycle, with some management thrown in for good measure. Now, with Software Project Survival Guide, Steve has written a quick-pass tutorial on how to deal with getting a program out the door. One major focus of this book is on process, that is following the steps of development closely to catch problems as early as possible. Echoing a sentiment expressed by Brooks, Steve points out that the earlier a problem is caught, the cheaper it is to fix. It's dang easier to erase a line on a whiteboard than to rip out multiple modules/objects full of code and correct them (a lesson which my project at work is currently learning).

The book is divided into four major parts:

1. The Survival Mind-Set
2. Survival Preparations
3. Succeeding by Stages
4. Mission Accomplished

The first part addresses the underlying concepts of the book (process, finding problems early, what a successful project looks like, etc), giving the reader an understanding of what it means to properly take a project through the valley of the shadow of failure. Steve also first mentions the concept of "staged delivery" in this part, something he will harp on throughout the book. Basically, staged delivery is how most open-source projects run: having multiple release dates with integral increases in functionality. For vertical or internal applications, however, this is a rarity. When software is driven to a releasable stage multiple times, it establishes the exact state of the software, allowing for better schedule estimation and allows the user to obtain a minimal, but possibly critically functional, piece of software early. Staged delivery differs from multiple versions released over time in that the final staged delivery fulfills one set of requirements stated at the beginning, while multiple versions will each have a unique set of requirements (which will typically bloat for every further release).

Part II addresses the initial, planning phases of a project, before actual detailed work is done. This includes oversight boards (of varying size, just as long as someone is reviewing the decisions), effective configuration management, risk analysis, and scheduling. Requirements are also done at this point, an architecture crafted, and QA/QC brought on board. At this point, everyone who will be involved should know what is going on, and all planning and infrastructure should be in place. Unfortunately, this stage has a tendency to drag on, as people waffle over who will do what, and what exactly will be done. My project in particular experienced some serious delays in this area, as the customers were incapable or unwilling to tell us what they needed, and when they needed it, beyond "everything, in a month." We finally got past this point, but not without wasting way too much time.

Part III digs into the meat of the process -- keeping on track while the software is being written. Brooks addresses this part of the process in MMM with his famous quote, "More programming projects have gone awry for lack of calendar time than for all other causes combined." The man speaks truth. Steve takes the project through stage planning, detailed design, construction, testing and release. These steps will then be repeated for each stage of the project, until all stages are completed. As discussed earlier, this will allow maximum delivery in a minimum time, especially of critical features. Steve also emphasizes "miniature milestones" to better gauge where the project is. There's a true saying that "90% of the project is done 90% of the time." Of course, what that really means is that no one really ever knows how much of the project is completed. However, setting small, concrete milestones all along the timeline will allow an excellent gauge of where the project is. "How does a project get to be a year late? One day at a time. (Brooks)"

Part IV discusses the project aftermath, especially learning from the project. This is a short part, and mainly emphasizes archiving all documentation and reviewing what went right and what went wrong. Steve also offers a nice list of project management resources, including other books and web sites.

What's Good?

Steve McConnell is a proven author, and as such does not disappoint. The chapters are clear and concise, with excellent checklists at the end of each. He also has an entire website devoted to supporting the book. He steps through the process methodically, making sure all parts are covered. For those of you interested in the SEI's CMM practices, Steve has drawn heavily from them for this book. My understanding is that Steve is not wedded to the model itself, although he certainly sees it as an excellent step forward. In fact, following the recommendations of this book will definitely bring a project closer to level 2 compliance.

What's Bad?

Well, if I thought the book wasn't useful, I wouldn't have reviewed it. :-) Anyway, the book does not have any glaring flaws. I think Steve tends to emphasize organizations that need five member change boards over those where the board is likely to be the manager (which is probably most organizations). If, however, you can adapt his ideas to your situation, you and your project will benefit.

What's In It For Us?

Once again, where does Open Source come into this? I'm going to end up repeating myself somewhat from last week, but I am firmly convinced that open source projects need more process and structure. The software community has managed to survive for forty years with little process, and open source has done the same for twenty. Now, however, that chapter must end. We need increased productivity and better organization to be truly effective. We need written requirements to keep the projects on track and stop the waste of time and effort that non-required code brings. We need solid design (and detailed design) to keep everyone on the same page. We already do staged delivery (to some extent), but we need to pre-document when and how this will happen, instead of putting out a release when we feel like it. Too many projects wander off into oblivion because of gold plating or lack of vision and purpose. The better we can focus our passions and efforts, the closer to victory we will come.

Purchase the book over at Amazon.

• Table of Contents

• Acknowledgements
• Preliminary Survival Briefing

1. The Survival Mind-Set
   1. Welcome to Software Project Survival Training
   2. Software Project Survival Test
   3. Survival Concepts
   4. Survival Skills
   5. The Successful Project at a Glance
2. Survival Preparations
   1. Hitting a Moving Target
   2. Preliminary Planning
   3. Requirements Development
   4. Quality Assurance
   5. Architecture
   6. Final Preparations
3. Succeeding by Stages
   1. Beginning-of-Stage Planning
   2. Detailed Design
   3. Construction
   4. System Testing
   5. Software Release
   6. End-of-Stage Wrap-Up
4. Mission Accomplished
   1. Project History
   2. Survival Crib Notes

• Epilogue
• Notes
• Glossary
• Index