Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Facts and Fallacies of Software Engineering 424

Sarusa writes "The title of the book, Facts and Fallacies of Software Engineering, is nice and controversial, and so is the content. Robert Glass is a long-time software engineer and researcher into what software practices work, which don't, and why. You'll find his name all over the literature along with names like Yourdon and Brooks, and he's got a long list of professional credits. In other words, he's an experienced, cranky, opinionated old coot who pulls no punches and writes a very readable and useful book. And he's on your side, having deliberately passed up a more lucrative career in management for a technical track." Read on for the rest of Sarusa's review.
Facts and Fallacies of Software Engineering
author Robert L. Glass
pages 190
publisher Addison-Wesley
rating 8 out of 10
reviewer Sarusa
ISBN 0321117425
summary 40 years of software engineering research in a nutshell.

The Layout

Facts and Fallacies is not a technically demanding book; it's a very easy and compelling read. There are 55 Facts (and 5+5 fallacies) grouped into logical sections such as Management, Life Cycle, and Quality.

First, each Fact is stated succinctly. (For instance, Fact 1: The most important factor in software work is not the tools or techniques used by the programmers, but rather the quality of the programmers themselves.) Then the point is fleshed out more fully -- in this case, that even with all the periodic hype for some hot new methodology that promises orders of magnitude greater productivity, the quality of your programmers matters far more than anything else (and even the best new methods only offer 5-35% increases).

Next, the level of controversy about this Fact is discussed. For Fact 1, it's that even though everyone pays lip service to the idea of people being more important than processes, we all still act like it's not true. Maybe this new hot methodology can turn all your lousy programmers into great ones! Perhaps it's because people are a harder problem to address than tools, techniques, and process. And, of course, hot new methodologies sell a lot of books.

Finally comes a list of sources and references, which can lead you to more in-depth great reading like Peopleware and Software Runaways. This all works out to about one to two pages per item.

The Facts and Fallacies

The Facts and Fallacies fall into several groups. Some are not well known (or just met with stunned disbelief) such as Fact 31: Error removal is the most time-consuming phase of the life cycle. Some that are pretty well accepted, but are mostly ignored, like Fact 1 above. Some that are accepted, but nobody can agree on what to do about (if anything), like Fact 9 (paraphrased) #150: Project estimates are done at the beginning of the project when you have insufficient understanding of the requirements and scope, which makes it a very bad time to do an estimate for the entire project.

Some Facts Glass acknowledges many people will flat out disagree with (and for a few people, very loudly), like Fact 30: COBOL is a very bad language, but all the others (for business data processing) are so much worse. These are the Facts where he really has an axe to grind, and make for amusing reading. In this case what he's really saying is that there is a use for domain-specific languages intended to do one specific thing and do it well, rather than languages like C and Java which attempt to be "good enough" for any use under the sun. But everyone hates COBOL, including me, so it's controversial.

What's Good?

Again, this is a good (and fast) Read. Even if you don't agree with everything, Glass is a skilled writer with strong opinions and a sense of humor. And you might end up agreeing more than you expected. I was pretty skeptical when I started reading. After all, I'm a long time software engineer with strong opinions too, and how often do you get opinionated geeks to agree on even what soda or text editor to use? But most of the Facts resonated with my experience, and of course for most of them Glass has substantial research reference for. The best Facts are those that you knew but might never have expressed explicitly, like Fact 41: Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software.

Or consider Fact 18: There are two 'rules of three' in reuse: (a) it is three times as difficult to build reusable components as single use components, and (b) a reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library. I knew this generally, and you probably did too, but I didn't know the specific reference for "Biggerstaff's Rules of Three," which give you a ballpark figure.

The book was written in 2002, when eXtreme Programming was hot, and it's very interesting that the predictions Glass made in this book about the strengths and weaknesses of XP were, in retrospect, pretty much on target, and this sort of predictive success helps confirm more viscerally that he knows his subject.

What's Bad?

There are a few Facts in here that Glass included just because he feels strongly about them (or even about specific people) and he doesn't really back them up very strongly except with "well golly, this is so obvious." Like Fallacy 5: Programming can and should be egoless. Note that this is a Fallacy, so he opposes it. I happen to agree with him, but his arguments are mostly personal ox-goring even if they're based on his extensive experience. Still, it's an interesting read.

A few of the Fallacies he feels are so obvious that he doesn't even really bother providing sources or references for them, and this somewhat diminishes the overall feel of rigor.

Really, the worst thing about this book is that it doesn't come with a poster of just a bullet-pointed list of facts and fallacies that you can nail to your office wall (or your boss's).

A Few More Facts

Just to whet your appetite:

Fact 21: For every 25% increase in problem complexity, there is a 100% increase in solution complexity.

Fact 37: Rigorous inspections [code reviews] can remove up to 90% of errors before the first test case is run. [But are so mentally and emotionally exhausting that we rarely do them.]

Fallacy 10: You teach people how to program by showing them how to write programs. Why don't we teach them to read programs first? Good question (and he has a few possible answers).

In Conclusion

I wouldn't say this Facts and Fallacies of Software Engineering is quite as powerful as The Mythical Man Month, Peopleware or Death March on their own, but if you program (or manage programmers) and want to be more than just a code pig, this will give you the condensed version of 40 years of research in a very readable package. Even if you don't agree with everything he says, it's well worth considering it.


You can purchase Facts and Fallacies of Software Engineering from bn.com. Slashdot welcomes readers' book reviews. To see your own review here, carefully read the book review guidelines, then visit the submission page.

This discussion has been archived. No new comments can be posted.

Facts and Fallacies of Software Engineering

Comments Filter:
  • Since he has not gone the way of other money-seeking, glory-hunting management "people", he is a "true" Veteran.

    Dear Veteran: I Salute thee for resisting the pressures of becoming another me-too manager and instead staying in trenches to fight with poor soldiers.

    • by daveo0331 ( 469843 ) * on Monday August 30, 2004 @04:09PM (#10112248) Homepage Journal
      If he was in management, wouldn't he have more influence which he could use to change things for the better? Just because you have a management position doesn't automatically mean that you believe in the PHB management style.
      • by Mateito ( 746185 ) on Monday August 30, 2004 @04:15PM (#10112294) Homepage
        Hear hear!

        This is the big problem with management. Pre-boom managers were PHBs, and thus promote PHBs. New skilled IT people look at PHBs and think, I don't want to be like that, so I won't become a manager.

        So its a self-feeding cycle.

        WE NEED MORE GEEKS IN MANAGEMENT.

        Right now, I should be writing my MBA assignment, worth 25% of the subject, due in at midnight tommorrow, but instead I'm procrastinating on SlashDot. If that doesn't qualify me to be a geek manager, I don't know what does.
        • The hard part about getting geeks into management is that they need to be around one place long enough. PHB's get where they are by riding out the clock and becoming the one with the most knowledge. This happens through attrition in many organizations. We geeks aren't often patient enough to ride the pendulum long enough for it to swing the other way.

          Our management here has been propogated through golf buddies and drinking buddies. Those with the experience to make good decisions for the organization a
        • by plover ( 150551 ) * on Monday August 30, 2004 @04:40PM (#10112505) Homepage Journal
          Except most programmers I know that are worth their weight in salt would completely and totally suck to have as managers.

          Some are poorly organized in everything but their code (*ahem*.) A few grew up believing that an employee / employer relationship should be antagonistic; that a manager must rule their team with an iron fist. That may come from looking around at a bunch of us slacker programmers thinking "hey, why aren't they working as hard as I? If I were their manager, I'd be busting their asses 24 by 7." Many are extremely introverted and have trouble speaking up among their peers; they simply would not be capable of dressing down an employee who desperately needs it.

          In most of these cases it seems that the programmers have spent their time learning machine management skills. Those skills are completely unhelpful when it comes to working with people. The lessons you learn (for example, "the machine only does exactly what I tell it") don't work with human employees, no matter how hard you try to apply them.

          Yes, management is a skill that can be learned, but I don't know any geeks that would want to spend the time, let alone actually manage. Not even for the money. Almost all the people I know who have become successful managers have never been real programmers. They were business analysts or came from completely outside the IT field.

          • by Anonymous Coward
            Except most programmers I know that are worth their weight in salt would completely and totally suck to have as managers.

            Yep. My experience of fellow computer programmers is the same. They would not make good managers. And, more importantly, they would not ENJOY being managers. They are perfectly content to be managees.

            However, the few programmers who are both capable and motivated to be in management really should aspire to do so, IMAO. They are exactly the sort of management that the industry nee
          • by twiddlingbits ( 707452 ) on Monday August 30, 2004 @06:46PM (#10113302)
            " Almost all the people I know who have become successful managers have never been real programmers"...well,meet one more. I have been a coder for many years in embedded systems work, and also in the web area. And I have (and do) manage teams of programmers and analysts. The reason most geeks don't want to manage is simple..It is HARDER than coding. No debuggers, no error messages, no recomplies, it has to be right the first time. And Senior Management expects it!! Plus the skills are mostly people skills, something IMNSHO a lot of "geeks" have trouble with. People solutions are generally not right/wrong they are somewhere in the middle, they are kinda "fuzzy" which bothers the logical programmers mind. But those "soft" management skills CAN be learned if you try. In my 22 yrs in IT I've been up the Management chain to mid-level and back down and over to Sr. Technical Staff. I prefer the Technical work, but it is getting HARD to find, so I have my PM skills to fall back on. Versatility in roles, as well as in programming skills is valuable! Oh,and don't get me started on my soapbox about how Leadership is MUCH more valuable than management, but it is in every scarcer supply in the tech world. Set reasonable expectations but hold them to it, give people room to work, help them with problems, keep the customer informed and off the programmers backs and you'll do OK in Managment.
      • ...then all developers are dilberts.

        And you wouldnt want THAT. It would spoil the cool "old soldier" metaphor...

    • by EugeneK ( 50783 ) on Monday August 30, 2004 @04:47PM (#10112575) Homepage Journal
      This message paid for Swift Byte Programmers for Truth.
  • Ahhhh... (Score:2, Funny)

    by Anonymous Coward
    "Fact 21: For every 25% increase in problem complexity, there is a 100% increase in solution complexity." How is that a fact? Some data would be nice, and i'll wager 60 Quatloos he doesn't have any.
  • by GillBates0 ( 664202 ) on Monday August 30, 2004 @04:04PM (#10112195) Homepage Journal
    and want to be more than just a code pig

    I resent that. As we all know, the correct term is r as in coder.

  • by Black Parrot ( 19622 ) on Monday August 30, 2004 @04:05PM (#10112208)


    You could have shortened that to "experienced"; the rest follows naturally from that.

  • Another review... (Score:5, Insightful)

    by tcopeland ( 32225 ) * <tom@@@thomasleecopeland...com> on Monday August 30, 2004 @04:06PM (#10112220) Homepage
    ...this one [mountaingoatsoftware.com] by Mike Cohn of Mountain Goat Software.

    Mike's review is from the "agile software" point of view, so he comments favorably on (among others) Fact 22 - "Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical".
  • COBOL (Score:2, Interesting)

    by spidereyes ( 599443 )
    I saw the word COBOL and cringed and immediately thought of long hot days in the arid lab. Also, spending enormous amounts of time programming/debugging on what I thought was the worst language ever. Master file update...almost makes me cry what they put us through...and then there was Assembler. I'll be interested to check this book out for the COBOL section alone.

    • COBOL && Lisp? (Score:4, Interesting)

      by BerntB ( 584621 ) on Monday August 30, 2004 @04:25PM (#10112389)
      I'll be interested to check this book out for the COBOL section alone.
      A guestion.

      Let's assume that the book's thesis is true that COBOL is best for administrative programming since it's a specialised language.

      Does the book address e.g. Lisp, where programmers have a standard "pattern" to create sub-languages to attack problems?

      It sounds like an argument that Lisp should be used instead of COBOL, since Lisp is arguably at least as good as any/most for non-low level programming.

      Now I'll probably be flamed by Lisp people... :-)

    • Re:COBOL (Score:3, Informative)

      by biobogonics ( 513416 )
      I saw the word COBOL and cringed and immediately thought of long hot days in the arid lab. Also, spending enormous amounts of time programming/debugging on what I thought was the worst language ever. Master file update...almost makes me cry what they put us through...

      Modern COBOLs are a far cry from the original language. Some even have OO features. While the thought of using traditional COBOL file management makes me cringe too, nowadays you can use SQL or call out to an ODBC driver. Probably the best fe
  • Deadlines (Score:3, Insightful)

    by Scoria ( 264473 ) <(gro.dezilaitini) (ta) (liamhsals)> on Monday August 30, 2004 @04:09PM (#10112253) Homepage
    The most important factor in software work is not the tools or techniques used by the programmers, but rather the quality of the programmers themselves.

    Another important factor is the amount of time that they are given to accomplish the task. Certain programmers, including many who are otherwise excellent, procrastinate and cannot meet deadlines. And, as we're aware, even good programmers often take shortcuts once fatigue begins to set in.
    • the deadline issue (Score:4, Insightful)

      by joaodk ( 625566 ) on Monday August 30, 2004 @04:55PM (#10112624)
      IMHO the real management issue concerning deadlines is the way they are defined.

      If the manager imposes an impossible deadline to the programmer, hes just a bad boss, PHB style. Of course, there are always real world time constraints to be met, but in this case the manager should define a possible goal along with the programmer, alternative solutions, scope agreements, etc.

      On the other hand, if the programmer is incapable of defining a deadline himself to a well defined amount of work, than you just cant blame the manager.

    • Re:Deadlines (Score:3, Interesting)

      by Moraelin ( 679338 )
      Being a programmer myself, let me shed some light on why and when it may look when someone is working at low speed. Or really is procrastinating.

      1. The obvious, they are not a great programmer after all.

      2. You mention fatigue. You're dead on. Being tired can sap someone's efficiency (including via increasing the number of bugs) a lot. Whipping a team into working 12 hour shifts, 7 days a week, may work for a week, maybe even two, but then you have tired _and_ demoralized people.

      3. Morale problems. Being
  • by tcopeland ( 32225 ) * <tom@@@thomasleecopeland...com> on Monday August 30, 2004 @04:11PM (#10112266) Homepage
    > Fact 37: Rigorous inspections [code reviews]
    > can remove up to 90% of errors before the
    > first test case is run. [But are so mentally
    > and emotionally exhausting that we
    > rarely do them.]

    I think some of these terms mean different things to different people. When he says "test case", he means (I think) a tester clicking around a UI and adding a new employee or whatever. But "test case" can also mean a unit test, i.e.:
    Employee e = new Employee("Fred");
    assertEquals(e.getName(), "Fred", "Name not set correctly on instantiation");
    The latter meaning of unit test provides a way to do "rigorous inspections" over and over - because a computer is doing the work. Good times.
    • by Jeffrey Baker ( 6191 ) on Monday August 30, 2004 @04:25PM (#10112387)
      Sure, but code reviews (especially of the latest patches, instead of whole tracts of fresh code) can easily catch errors for which no test exists, or for which no simple test is possible.

      Just as an example off the top of my head, it's common to write

      if (condition = immediate) ...
      which in some languages could be caught by the compiler, but not always. The author of that line can read it over and over but something in his brain will replace the mistaken '=' with '=='. The code reviewer has no such preconceptions and will (might) see it immediately.

      One good example of open review is the Mozilla project, where all commits must be reviewed by at least two people, at least one of whom must be the owner of the relevant subtree of the project. (sorry if this is not quite right, i'm going from memory here). As a result the quality of the code making it into the Mozilla tree is pretty high, with minimum "paper bag" errors.

    • by abigor ( 540274 ) on Monday August 30, 2004 @04:33PM (#10112461)
      No, unit testing and code reviews are orthogonal. Unit tests verify correctness for certain types of input, but often fail to catch subtle bugs or identify poor solutions (bad algorithms or whatever), and of course they are only as good as the person who wrote them - most often, the person who wrote the code being tested in the first place. So the input to the unit test is often just the sort of thing the code was written to manage, not edge cases and so forth.

      Nothing compares to a code review done by a super-anal type who nitpicks over everything. It is amazing what such a person can catch in terms of weird edge cases, inefficiencies, and so forth, simply by making you sit there and justify what you've done. Like the reviewer said, they are emotionally draining, but are truly worth it.
      • > a super-anal type who nitpicks over everything

        Hm. Maybe that super-anal person could fill the missing test cases for all those edge conditions. Then his analness will be preserved for posterity, because everyone can run those test cases to catch possible bugs in future code changes.
        • Sure, when he finds the bugs in your code through a peer review, you can add the test cases to first expose the problem then prove that you've corrected it.

          The other major advantage of code reviews is that you know someone else is going to look at your code soon. You're less likely to try to slip something trashy that works through.
  • COBOL (Score:3, Insightful)

    by MikeMacK ( 788889 ) on Monday August 30, 2004 @04:11PM (#10112269)
    Fact 30: COBOL is a very bad language, but all the others (for business data processing) are so much worse

    COBOL is an old language, not necessarily a bad language. Like anything else, you get out of it what you put into it. If you like programming in COBOL then you'll probably be good at it. If you like programming in Java, then you'll probably be able to code any business data processing functionality you need in it too. I think it's best to use the tool you're most comfortable with.

    • Re:COBOL (Score:4, Funny)

      by gillbates ( 106458 ) on Monday August 30, 2004 @04:41PM (#10112512) Homepage Journal

      COBOL was designed not to actually get work done, but rather to destroy the ego of any young, up-and-coming prima donnas.

      After the first year of debugging and maintaining COBOL programs with millions of lines of spaghetti code, obfuscated, global variables, etc... the young programmer has no room left for an ego. He has come to the realization that he can't understand everything about the system completely; he is humbled.

      Then, when given a Java assignment, he feels a sense of gratitude and loyalty to his boss, who has just lifted him from an endless quagmire of PERFORMS and GO BACKS, and SOC4 ABEND...

      THAT is why COBOL came about. IBM never expected that business would build systems with a language designed to break-in the new hires...

      But, as they say, the rest is history...

    • Re:COBOL (Score:3, Insightful)

      Counterexamples: brainfuck, intercal. The lesson is that at least at some level, programming language does really make a difference.
    • Re:COBOL (Score:3, Interesting)

      Cobol is a bad language and it always has been! There is just so much that is bad about Cobol that it is unbelievable that people would use it.

      Flow control like PERFORM, no good way to set up storage classes, akward syntax, horrible verbosity are just a few things.

      Setting up linkage sections is a pain in the ass. It is no wonder Cobol programers hated calling subroutines. What is worse is the spagetti code they rouintly wrote and then painfully debugged.

      There is a language that is quite good as a repl
  • by Anonymous Coward on Monday August 30, 2004 @04:12PM (#10112280)
    ...the worst system except for all the others.
  • by fishwallop ( 792972 ) on Monday August 30, 2004 @04:16PM (#10112306)
    In regards to Fact 37 ("Rigorous inspections [code reviews] can remove up to 90% of errors before the first test case is run, but are so mentally and emotionally exhausting that we rarely do them."): so what?

    If a code review, which takes several hours of my time and the time of my fellow developers, can catch 90% of the errors before the first test case is run, or I can catch 90% of the errors (not necessarily the same ones) using the test cases, it's a better use of resources to let the computer point the errors out to me.

    A code review on "90% debugged" software that finds an error strikes me as more useful than a code review that finds several errors in 0% debugged software.

    As for fact #1, good process or tools may not be able to make all programmers gods, but bad process or tools can make a mortal out of anyone.

    • It is the presumption on your part that you will or can catch the 90% that is the so what.

      It is emperical that people tend to overlook errors in their own work. Hence, the reviewing by others.

      I don't think he's talking about compilation errors, so the computer can't always find the (business logic) errors.
    • Yeah, but it's quite horrifying how many people/shops look at code reviews as unnecessary or too time-consuming. When I'm interviewing at companies, I tend to ask careful questions about process. If they don't include code reviews, I'm out of there.
    • by rumblin'rabbit ( 711865 ) on Monday August 30, 2004 @04:45PM (#10112551) Journal
      Yes, but you can review your own code.

      After writing out a couple hundred lines of code, print it out. Then come in the next day and read it. I mean, truly read it, line by line.

      Some may argue that this is not as good other programmers reading the code. Undoubtedly true, but you will still catch many errors. The fact that you've waited a day means you are, in a sense, a different programmer than the one that wrote the code. And the fact that it's printed rather than on the screen gives you a different perspective.

      I suggest that running tests is not sufficient to ensure a reasonable level of quality. There are certain errors that are unlikely to be caught by testing, and yet are quite obvious in a read through.

      In other word, testing is not a replacement for read throughs. In finding problems, a multi-faceted approach is needed.

      • If printing it out is not an option, displaying it in a different font, in a different size, ideally with differnt line breaks (hard for code, possible for other things) is almost as good.

        The aim of printing or reformating is to change the text, and force you to actually read the letters that are on the page. This is done by destroying the patterns in the positioning of the text that the writer is used to, thereby hindering recall.

        This is one of the reasons LaTeX is useful (for me, at any rate), because
      • And use a grinder (Score:3, Informative)

        by devphil ( 51341 )

        Which is what we used to call pretty-printers when they did more than just wrap everything in font tags.

        My favorite was lgrind, which produced TeX/LaTeX versions of your source. It could be taught about variable naming patterns, so if your code does something like "delta_vn = blah", it would emit "\delta_{vn} = blah". When printed, this becomes an actual Greek delta character, with the "vn" as a subscript. (Just one example.)

        Checking the formula in the code against the formula in the math reference

      • You are right. Don't just print it out and read it. Print it out and take it somewhere else to read it. Don't just print it out and read on the desk one foot away from your monitor. Take it outdoors and get some sun!
    • by Chris Parrinello ( 1505 ) * on Monday August 30, 2004 @05:13PM (#10112767)
      The thing that every seems to forget about the code inspection school of thought is that it was developed at a time when running tests and debugging actually did cost real money back in the 1970's when Fagan came up with his inspection process. Your department was charged everytime you compiled and ran your program on the mainframe computer because the mainframe was expensive to buy/rent, power and maintain.

      Now it doesn't cost real money but has an implied cost that bugs found later in the development process cost more money to fix than if you found then in the coding phase at a code review. Never mind the fact that the recommended rates of code inspects in lines of code per hour are near glacial and costs more money now to have 4 highly paid people to sit in a room and read code out loud. One project I worked on was all brand new code and would have taken three full months of code reviews to review every single piece of code at the speed the QA people were insisting was required for a proper code inspection.

      The process also insisted that we code inspect before we began any testing. So instead of running a suite of tests that could test 90% of the code in a matter of minutes, the QA insisted that we go through a code inspection before test just because the QA people's definitive texts on software quality still use the same data that Fagan used from his research back in the 1970s. They can quote the facts but they don't understand what assumptions were in the original research.

      Code inspections do have their place. I would say those places are to enforce coding standards and knowledge transfer which both help with maintainability in the long term. In reality however, most of the code I inspect today has been pounded on for a month or so before we review it. I can't remember the last time I actually found an error through inspection that would have resulted in a bug report. Most of the stuff we find are missing documentation and typos in that documentation. *yawn*
    • "In regards to Fact 37 ("Rigorous inspections [code reviews] can remove up to 90% of errors before the first test case is run, but are so mentally and emotionally exhausting that we rarely do them."): so what?"

      Two reasons (there are more, but these are the best ones that come to mind immediately):

      (1) The next time you park yourself on a commercial airliner you can be thankful that the software controlling the engines, the autopilot and the cabin pressure controls, to name just a few subsystems, was revie

    • i will give you the shortest possible summary of the difference between code reviews and test cases: code reviews are done by humans, test cases by computers.

      who's smarter?

      test cases are a great way to ensure that your code continues to do what it's intended to do. code reviews can catch design errors [though the ego factor is problematic here], can lead to new ideas, can dramatically simplify algorithms, etc.

      ITS GOOD WHEN THE PROGRAMMERS TALK ABOUT THE CODE EVERY ONE IN A WHILE!

      a free side benefit of r
    • Not at all. (Score:3, Insightful)

      A code review on "90% debugged" software that finds an error strikes me as more useful than a code review that finds several errors in 0% debugged software.

      That may be what your intuition tells you, but you're wrong. That is the most expensive way to debug software.

      When you find a defect in code inspect, you have your finger on it. You know exactly which line of code is faulty, and you know how it is faulty. Fixing it is trivial.

      When you find a defect in unit test, you know which subsystem is at

  • by SlashCrunchPop ( 699733 ) on Monday August 30, 2004 @04:17PM (#10112314)
    Fact 21: For every 25% increase in problem complexity, there is a 100% increase in solution complexity.

    Addendum: Unless you are talking about a Microsoft product where for every 1 % increase in problem complexity, there is a 7 year delay in solution delivery.

  • Book Club (Score:5, Interesting)

    by Viking Coder ( 102287 ) on Monday August 30, 2004 @04:19PM (#10112331)
    We had a Book Club at my job, where we reviewed one to four Facts or Fallacies at each meeting, once a week. We collected comments and suggestions about how to change how we worked. It was really interesting, and it was good to engage more people in the discussion, because while I might really care about this stuff and have strong opinions, other people in our organization did not have strong opinions and actually started to think about this stuff as a result of our meetings.

    Unfortunately, our suggestions didn't really get anywhere as a Massive Reorganization (TM) of the department took place. *grumble*

    We're thinking of doing another Book Club, talking about the "Dynamics of Software Development" by Jim McCarthy.
  • by tcopeland ( 32225 ) * <tom@@@thomasleecopeland...com> on Monday August 30, 2004 @04:19PM (#10112333) Homepage
    > Fact 41: Maintenance typically consumes
    > 40 to 80 percent (average, 60 percent)
    > of software costs. Therefore, it is probably
    > the most important life cycle phase of software.

    Hm. This is a tricky one. Does maintenance take that big a chunk because of the way we write v1.0? Maybe we can improve our initial code to make subsequent changes easier. And build in a safety net of units tests to make those changes less painful.

    A lot of maintenance may be a good sign - it may mean that the program is being evolved and improved and is actually useful to someone. Dead programs and cancelled projects don't get maintained, but that's not a point in their favor.
  • by Anonymous Coward on Monday August 30, 2004 @04:20PM (#10112343)
    Fallacy 5: Programming can and should be egoless

    I have worked with somebody who turned himself into a great programmer by being egoless. He could solve any problem by the simple expedient of not trying to do it all himself and being very good at accepting ideas from other people. In most circumstances programming is done within a team and ego just gets in the way.

    Who wants to work with somebody who rejects an idea just because they didn't think of it!!.
    • by Anonymous Coward
      Not only are egoless programmer better at accepting ideas, they are better at giving ideas. I've seen time and time again more junior programmers act proprietary with their ideas because they are in competition with the world. The economics of programming guarantee there will journeymen programmers and one mature team mentor is worth a whole room full of ambitious young monkeys with typewriters.
    • by Anonymous Coward on Monday August 30, 2004 @04:42PM (#10112520)
      Different sense of "ego", I think. There is ego, "Everybody else sucks", and then there is ego, "Yes my code is good, and I'm confident enough in myself to know that I can deal with the problem."
    • I do. What's his name and email address? If his ideas are all good, I'm hiring!
    • by kin_korn_karn ( 466864 ) on Monday August 30, 2004 @04:57PM (#10112633) Homepage

      The main reason programmers appear to have an ego about their work is that as you get older and more experienced you're expected to know more about software engineering than the people younger or less experienced than you. Never mind that you've never worked with Package X, you are a senior guy and you can handle it. They also have their junior people lean on you and then their success depends on yours.

      If you appear egoless and unashamed to draw from others' advice, you appear to be ignorant and unmotivated once you get to be a certain age or get a certain amount of experience.
  • If this type of thinking could be eliminated (through examples and actions), lots of people would have happier, healthier work environments and professional relationships:

    "And he's on your side, having deliberately passed up a more lucrative career in management for a technical track."

    Why they vs. us? Why can't we all just get along? :)
  • by Hypharse ( 633766 ) on Monday August 30, 2004 @04:35PM (#10112478)
    I still remember (and cringe when doing so) my software engineering class in college. SE is over-analyzed to a fault. You have so many "improvements" like UML and programs like Rational Rose that only help to overwork and confuse those working on programs. And don't even get me started on the bazillion buzzwords created for software engineering just to make obvious facts sound scientific.

    I think a book like this is what is wholly necessary. I am not saying this book does a good job of it (I haven't read it). There just needs to be a book that tells people how much of the software engineering information is false and unnecessary. This is so we don't have to either sift through all of it or even worse waste countless hours trying to follow a faulty discipline.

    Yea I have an agenda because writing software is hard enough in itself. It is 10 times worse when cluttered with overhead. I remember my very first programming class in high school (it was at a community college) where I was told for a FACT that I should flowchart every function and include a separate box for every line of code. It is ridiculous and they are feeding this stuff into students heads as fact.

    • by Malc ( 1751 )
      What's wrong with UML and Rational Rose? I've just come back to a project from 3 years ago that I designed and developed by myself. Nobody else has touched it since. I'm so thankful I used Rational Rose to create UML diagrams for my documentation as it's made my learning experience with everything I'd forgotten much easier. When used properly, UML doesn't confuse people. Either that or the people have been educated about it.
  • by Anonymous Coward
    Since when does a "fact" include a value judgment, like COBOL being a bad language? That's an opinion.
  • Fact 21: For every 25% increase in problem complexity, there is a 100% increase in solution complexity.

    Fact 37: Rigorous inspections [code reviews] can remove up to 90% of errors before the first test case is run.

    Fallacy 10: You teach people how to program by showing them how to write programs. Why don't we teach them to read programs first? Good question (and he has a few possible answers).


    FACT: a piece of information presented as having objective reality - in fact : in truth

    fact 21 & 37 are not f
    • What you're reading here is a review, not a full restatement of each thesis in the book. Have you RTFB? If not, then you do not know what data he provides to buttress his statements as Facts and Fallacies.

      OTOH, what data can you provide to contradict him? Your own personal perceptions? Or can you actually show verifiable numbers?
    • Technically, a fact is not "a true statement". A fact is a statement that is either objectively true OR objectively false, but cannot be both. This is as opposed to an opinion, which is subjective and can thus be simultaneously true for one person and false for another.

      You are acting as if "fact" is the opposite of "false". It's not. "Fact" is the opposite of "Opinion".

      "The earth's moon is made from green cheese" is a fact. It happens to be a false fact, but it is still a fact instead of an opinion.
  • by Fulcrum of Evil ( 560260 ) on Monday August 30, 2004 @04:50PM (#10112591)

    Really, the worst thing about this book is that it doesn't come with a poster of just a bullet-pointed list of facts and fallacies that you can nail to your office wall (or your boss's).

    Or your boss.

  • This is Blatant Self Promotion (you have been warned).

    Here's a good list of software resources [berteig.org], mostly books that I've collected over the last five years or so. Lots of stuff about agile, stuff for managers as well as developers.

  • by ChipMonk ( 711367 ) on Monday August 30, 2004 @05:09PM (#10112738) Journal
    Fallacy 10: You teach people how to program by showing them how to write programs. Why don't we teach them to read programs first? Good question (and he has a few possible answers).

    This is exactly what John Lions was trying to do with his commentary [peer-to-peer.com]. And he used nothing less than the Unix kernel source code as an example of well-crafted, and very readable, code.

    Rest in peace, John. Your little project helped more hackers than you could ever have known in this life.
  • A similar read (Score:3, Informative)

    by jefu ( 53450 ) on Monday August 30, 2004 @05:51PM (#10112998) Homepage Journal
    A book in the same kind of vein is "A handbook of Software and Systems Engineering -- Empirical Observations, Laws and Theories". In it, "laws" are stated and discussed with emphasis on experiments or studies that back up the law, or that tend to falsify it.

    As an example, one of the laws mentioned in this discussion is given as "Individual developer performance varies considerably." (Law 31) Then some statistics are given showing the variability. Finally there is a comment on if we should or should not trust the numbers given.

  • by epine ( 68316 ) on Monday August 30, 2004 @06:07PM (#10113099)

    Does anyone esle find it incredible that this reviewer complains that the cranky old coot author doesn't bother to provide justifications where he really doesn't have anything compelling to add?

    Knowing when to shut up is one of best indicators that someone cares enough about their subject matter that they don't feel the need to "fill air" as if other people can't supply their own experience.

    I heartily condone the approach: here's what I think, take it or leave it.

    I'm an old coot myself, and I've learned that it's generally a waste of time to write toward an audience that won't think for itself. If you boss won't think, a poster of convenient sound bites won't solve any problem that matters.
  • Project estimates (Score:5, Insightful)

    by Sebastopol ( 189276 ) on Monday August 30, 2004 @06:14PM (#10113129) Homepage
    Project estimates are done at the beginning of the project when you have insufficient understanding of the requirements and scope, which makes it a very bad time to do an estimate for the entire project.

    This is what separates the men from the boys. Estimation of project requirements are not perfect until the project is complete, so you have no choice but to work with educated guesses.

    Modern project management is an exercise in managing uncertainty.

    It is easy to say how long it would take you to write a script, anyone can do that in their head: guess base on experience, multiply by x2 and have a reasonable estimate.

    Now try estimating a thousands scripts (or circuits) done by hundreds of engineers of varying aptitudes that will result in a capital cost of several billion dollars over (hopefully) a few years! All of which is directly reflected in your retirement investments!

    That kind of planning is real nuts-and-guts stuff that most of us well never have to wrestle with, and a "fact" like this grossly understates and misrepresents.

    Programming is easy.

    Planning is orders of magnitude harder by comparison.

    I prefer programming, the latter makes my brainpan throb.

  • Teaching (Score:4, Interesting)

    by Spazmania ( 174582 ) on Monday August 30, 2004 @07:02PM (#10113422) Homepage
    Fallacy 10: You teach people how to program by showing them how to write programs. Why don't we teach them to read programs first?

    For the same reason we don't teach people how to write books by telling them to go read: If they're serious about writing, they're *already* avid readers. Teaching them to read would be redundant.

    If a wannabe programmer isn't already reading code for ideas then he's wasting your time asking how to be a programmer.
  • by gosand ( 234100 ) on Tuesday August 31, 2004 @08:11AM (#10117203)
    I am curious if he addresses the fallacy of "Software development only consists of programmers".

    I have been doing QA/Testing for 10 years, and it is pretty sad how all-important people think programmers are. The best ones may be, but they aren't all the best ones. When you foster an atmosphere where "develpment is always right" you run into major roadblocks in software development. Requirements analysts can't do their job properly or requirements are ignored. Documentation people are glared at for trying to make the system understandable. (yet we all love to bitch about bad online documentation) Test people are seen as people who are just blocking the inevitablility of shipping the code. If anyone tries to even analyze why things are F'd up, they are seen as "not being team players" and "finger pointers", even if you are trying to fix the process and not the people.

    I will say that what he says about inspections is right on. Although, I think just focusing only on code reviews is wrong - rigorous reviews of requirements/code/test plans/process docs/user doc/etc will remove 90% of the defects. And defects in requirements are much more costly to fix later. The trick is balancing which of these are most important for your company to review, depending on the project. You can't just do it willy-nilly, you have to do a risk assessment on it and make a decision based on something.

    I actually had a director of engineering say in a meeting "Since we implemented my new requirements management process, I *guarantee* that the code will work, first time, out of the box." I laughed out loud, and received a very dirty look from him, but agreement from everyone else. Needless to say, that release is the worst one we have had in 5 years, and it is at least 6 months over schedule. People have had to work a lot of OT to try and shine this turd, and they are getting burnt out. Most places do software development and not software engineering. Which is fine, as long as you are clear about it.

    I just thought of a very good analogy that /.ers can understand. There is probably little doubt that Microsoft has a lot of good programmers. However, their culture and business model has lead the direction of their product. That alone should show you that software development is not all about the programmer. On the other hand, OSS is great but it can only get so far on "good code". Once it is managed, it can be pretty powerful.

Statistics are no substitute for judgement. -- Henry Clay

Working...