Slashdot Mirror

← Back to Stories (view on slashdot.org)

Alan Cox on Writing Better Software

Posted by michael on from the use-more-white-space dept.

Andy Gimblett writes "Alan Cox recently gave a talk in which he discussed some current and emerging techniques for producing higher quality software. Some of these will be familiar to Slashdot readers, such as validation tools, type checking, etc, but others seem heavily influenced by his recent MBA. In particular, he has a lot to say about Quality Assurance in the software world, and the kinds of things we should be doing (and some people are doing) to make better software. Story and lots of quotes at Ping Wales, and video at IT Wales."

42 of 391 comments (clear)

  1. Quality by mfh · · Score: 5, Funny

    he has a lot to say about Quality Assurance in the software world

    Quality Assurance in 4 easy steps!

    Dear Managers,

    1. Listen
    2. Close your mouth
    3. Plan everything around #1
    4. Profit!!! (notice there is no line with ??? because you listened!)

    --
    The dangers of knowledge trigger emotional distress in human beings.
    1. Re:Quality by mfh · · Score: 4, Insightful

      And what then when the customer wants some hard evidence about what has been done? What then? What will you provide to them? How does your irrational hatred of managers actually assure quality in concrete steps?

      A good manager does all the detail work and keeps track of everything. My post was about what they haven't been doing much of lately.

      I don't hate managers, and to suspect that I might by reading my previous post means you failed to understand it.

      Quality in business comes from many different people in any given project. Software quality can be adversely affected by morale, and you guessed it -- programmers have some of the lowest morales in the business world today; they are often not respected by management, they have the highest workloads, and they have no time for social lives.

      If managers listened, and remained silent or inquisitive instead of arbitrary or antagonistic, software quality would be up.

      --
      The dangers of knowledge trigger emotional distress in human beings.
    2. Re:Quality by acvh · · Score: 4, Informative

      "no time for social lives"? like they would know what to do if they did?

      but seriously, good managers manage. Bad managers threaten, cajole, bribe or whine. software is either a product, which means that management is monitoring to be sure the product is what they can sell; or software is a tool, in which case the manager must ensure that the tool works.

      either way, successful software is a combination of good programming and good management.

    3. Re:Quality by jc42 · · Score: 3, Interesting

      1. Listen
      2. Close your mouth ...

      One problem with this: By listening with your mouth closed, you run a very real risk of misunderstanding what you're hearing. Without feedback to verify that you're understanding, you are highly likely to do things completely wrong.

      Funny example: A few years ago, I was implementing an interactive web site, and we had a nice test server machine in the lab. In one discussion with The Mgt, I casually mentioned that for testing, I thought we needed to run another server.

      I didn't hear any response, so I went ahead and cloned the apache server that we were using, and fired it up on a different port. 10 minutes work, and we proceeded to test.

      A while later, I discovered just in time that the managers had heard me say that we needed a second server machine, and were ordering another one. After a bit of discussion, I realized that to them, a server is a piece of hardware, while to us software guys, it is a piece of software.

      I managed to explain to them that, no, we didn't need a new machine. I'd already set up a second web server on the old machine, and it was working fine. There was still time to cancel the hardware order.

      But still, they had done a bunch of unnecessary work, and had almost spent a good sum of money unnecessarily, all because they had listened carefully without asking questions. If they had asked what hardware the new server needed, I'd have realized quickly that there was a misunderstanding, and we could all have saved a bit of time.

      Listening without interacting, and acting on your understanding of what you heard, can lead to a lot of serious problems.

      --
      Those who do study history are doomed to stand helplessly by while everyone else repeats it.
    4. Re:Quality by fyngyrz · · Score: 4, Interesting
      Quality Assurance in 6 Easy Steps:

      1. Fire the managers
      2. Fire the beancounters
        (steps 1 and 2 may be reversed if required)
      3. Fire anyone who even mentions the word "committee"
      4. Keep labs open 24/365. Apply metered, but 100% flexible, work hour rules for programmers (ie, "You have to work 40 hours/week, but it doesn't matter which 40 hours.)
      5. Provide superb comfort and amenities to programmers
      6. Create significant bonus program tied directly to number of problems found in each programmer's code per release cycle. Zero problems, max bonus, more problems, less or no bonus. Stir to taste.

      Enjoy good results.

      --
      I've fallen off your lawn, and I can't get up.
    5. Re:Quality by penglust · · Score: 5, Insightful

      Been there, done that. I could not agree more. But I have had a number of good managers in the past. Did a stint as manager myself at one time. I backed off because, like you, I just plain like to be productive and I think like an engineer. This may it difficult to deal with those above me.

      My direct manager right now is acutally one of the best I have seen. The other 3 or 4 layers above are lost and clueless most of the time. Their buzz word at the moment is ISO 9000.

      I think your comments bring up another issue. F**k up move up is often not just a saying. I have made friends and lost friends in the past for my opinions but if one of my fellow programmers is just plain incompetent, lazy, or an ass hole then they need to go. I don;t encorage moving them to get them out of my hair. I have done this before and somehow I always ended up having to deal with them again.

      There is also the type that are just biding their engineering time till they can become a manager. I have generally found these guys to be less than worthless. They are usually garanteed to make the worst managers.

      These are the criteria I usually find good in a manager and tried to use as one:

      1. Have a good broad software background. If working at the kernel level (including driver) have a basic understanding of hardware

      2. Understand how software impacts the potential customers and their needs. Books have been written on this, most of them wrong.

      3. Know your employees and their stengths and weaknesses. Use this to build a team that can and will perform.

      4. Trust the team but keep track of everything anyways.

      5. Process is a must but it should be pretty lightweight. Make it enforcable and do not waiver in ensuring the necessary pieces occur.

      6. Insulate your engineers from most of the stuff above. Not all, just most of it. Usually controlling the flow will suffice (often this involves rumor squashing).

      OK enough for now.

  2. Unit testing? by JohnGrahamCumming · · Score: 4, Interesting

    It's quite surprising to me that there's no mention here of unit testing, or any sort of automated testing where the engineers who wrote the code actually write tests.

    It should, by now, be clear that "code that doesn't have tests, doesn't work", and that if XP has done anything for us, it's to focus on writing tests. I've seen this in action and it works.

    John.

    1. Re:Unit testing? by bloggins02 · · Score: 5, Insightful

      Unit testing is essential, but it's not a panacea. In particular, beware of two pitfalls:

      1) "The unit tests passed, so it works." This assumption is flawed on several levels. First, and most fundamentally, even if all unit tests pass, there is still the issue of whether your software works as a whole. Software often has "emergent logic" and UI scenarios that are difficult or impossible to test (after all, that's not what unit testing is for, but some people seem to think it is).

      Second, just because a test passes, doesn't always mean the API works. This is especially important if you didn't write the tests yourself. Just because a unit test CLAIMS it tests X, doesn't mean it does. Is the test complete? Any false positives? Is the test just a skeleton that was intended to be implemented later but never was? I've had all these bite me in the past.

      2) "That particular test has NEVER passed, so there's something wrong with the test. We just ignore it now." Bzzzt! Wrong! There's a REASON it never passed. It's either not implemented properly, just a stub that fails waiting for someone to write an implementation, or maybe you just think the feature it tests actually works. Look closer. The test might be trying to tell you something.

      If you are careful with unit tests, they can be very rewarding and useful (especially for regression testing, where they are invaluable), but put too much confidence in them or depend on them to do the kind of overall testing they were never designed to do, and you will fail long before your first test does.

    2. Re:Unit testing? by cerberusss · · Score: 3, Insightful

      What people should realize, is that it can cost quite a bit of effort to build a unittest. I.e. if you write some code that reads several rows from a database and as a result writes a bunch of rows in another table, you need to run scripts before and after your unittest. It's of course all doable, it's just that it's sometimes more work than writing the method itself.

      --
      8 of 13 people found this answer helpful. Did you?
    3. Re:Unit testing? by Unkle · · Score: 5, Insightful
      But that's really the reason it's not done all that often. Developers think that the unit test will be a waste of time. The problem is, nobody codes perfectly. Finding a bug during unit testing is much better than finding it in design validation testing. Indeed, on many projects I have worked on, issues that could have been found with adequate unit testing were not found until after release.

      Unfortunately, when schedules get tight, it's things like unit testing (and testing in general) that get cut. The more emphasis we get on the importance of QA the better our industry will be.

      --
      Against stupidity, the gods themselves contend in vain.
    4. Re:Unit testing? by Anonymous Coward · · Score: 3, Insightful

      Study Mock objects

    5. Re:Unit testing? by OP_Boot · · Score: 3, Insightful

      the engineers who wrote the code actually write tests

      Do NOT get the engineer who wrote the code to also write the test.

      It's fairly fundamental - the engineer who wrote it will have a prejudiced view of what should/will work.

      Get someone else to do it and get a valuable fresh insight.

    6. Re:Unit testing? by richieb · · Score: 3, Insightful
      A solid requirements based development process and requirements based testing/verification process is the key to large high quality software.

      You tacitly assume that it is possible to get solid requirements. When writing avionics software, I'm sure you can, because the problem is well understood and we have good science/math to back it up (eg. GPS nav system).

      But in most sofware projects it is impossible to create requirement ahead of time, mostly because the problem you are trying to solve is new and we don't understand it well enough yet.

      Are there requirements for the web browser? Were they created before the code was written? WHat about requirements for MS Word?

      --
      ...richie - It is a good day to code.
  3. Good code... by TrollBridge · · Score: 5, Insightful

    ...isn't just for end-users! If you anticipate that others will be working on future versions/releases of your software, good commenting can make the job SOOOOO much easier for the next codemonkey.

    I'd say commenting is doubly important in OSS projects, as it involves many sets of eyes trying to comprehend what you coded.

    --
    There's a Mercedes gap too. I want one and can't afford one, but it's not government's job to do anything about it.
    1. Re:Good code... by Dr.+Evil · · Score: 4, Insightful

      Commenting must be 100% accurate else it is detrimental to understanding the code.

      Sometimes code changes don't result in updated comments...

      Once I find an inaccurate comment in somebody's code, I have to start rewriting or deleting all the comments because I can't trust them anymore.

    2. Re:Good code... by johannesg · · Score: 4, Insightful
      That, and good naming of variables / functions / classes. To clear up any possible confusion: that means that the name has some bearing on what the thing in question is doing for you...

      Recently I had the misfortune to wade through a few hundred kilobytes of Java that was written by someone who thought he should 'abstract' everything as much as was humanly possible. Sounds good, right? Well... It turns you can do a lot of harm that way, too. I don't think he had a single function in there that _wasn't_ called something like SetProperty(), GetValue(), DoFunction(), etc. There was absolutely no way to guess what it was doing based on the name of the functions. Naming of classes and variables wasn't much better. After looking at it for a couple of hours I don't think I could have guessed what it was trying to do if I hadn't already known that beforehand.

      So, next time you are writing software, feel free to get in touch with reality and name stuff after what it is supposed to be doing. Nice long names please, no abbreviations unless you go over 30 or 40 characters. Down with CmtPmt2Db(), down with SCUPD(), and down with GetPropertyValueInterfaceCaller()!

      Because, be honest: those mean nothing, while CommitPaymentToDatabase(), ScreenUpdate(), and GetXLocation(), have intuitive meanings we all understand...

    3. Re:Good code... by gidds · · Score: 4, Insightful
      Comments tend to state the obvious and not tell you what you really want to know.

      This is a reason to write better comments, not to avoid them completely!

      Of course comments that are flippin' obvious, or wrong, do no good to anyone. But some sorts of comments can be incredibly helpful:

      • Big-picture comments. Explaining what this function, method, class, file, or interface is doing; how it fits into the app or system; important design decisions. Also authorship and date information, if that's important.
      • API comments. Describing the implicit (or explicit!) contract that a function, method, class or whatever has with its caller. When you should be calling this code, what the caller needs to have set up beforehand, what the code guarantees to do in return, any gotchas.
      • Section comments. Within long functions, just a few words every 10-30 lines, breaking it up into logical sections, can make it much easier to understand the flow, or find the particular section you're looking for.
      • Here-be-dragons comments. Describing tricks, shortcuts and other hacks. Better to make the code clear and obvious, of course, but there are times when a clever technique or bit of magic is needed, and for those rare occasions, a few words of explanation can make things so much clearer -- and prevent someone ignorantly 'fixing' it later!
      Of course, there's some overlap. But these are the sorts of things that can make code so much easier to read, and don't take much effort to maintain. The big-picture and API comments tend to be common practice in literate languages like Java (JavaDoc) and Perl (POD), but too many people don't follow it -- and even where those comments aren't extracted automatically, they can still be incredibly useful.

      My rule of thumb is: Try to make the code itself obvious. And comment everything else!

      --

      Ceterum censeo subscriptionem esse delendam.

  4. Alan Cox by Anonymous Coward · · Score: 5, Funny

    Who cares about what Alan Cox has to say? He's soooo 2.4

  5. Code review and pair programming by Frans+Faase · · Score: 3, Funny
    The most effective techniques for finding defects is still code review. It seems that one of the pair programming is a very good way of doing code review.

    However the greatest problem with writing good software is still in the marketing. In order to sell/license software it needs to have features, and the lack of defect often does not count as "features".

    1. Re:Code review and pair programming by ZorbaTHut · · Score: 5, Interesting

      Funny, that. I recently started working at a company with mandatory code reviews. Here's a list of my recent experiences with it:

      1) Checked in code. Spent fifteen minutes justifying design decisions. No changes made.

      2) Checked in code. Code contained horrible horrible bug. Code reviewer didn't see it.

      3) Checked in code. Defended my design against several more computationally expensive suggestions that were also more complicated. No changes made.

      4) Listened to a friend gripe about having to spend a DAY AND A HALF repeating design reasons and fixing bugs introduced by his code reviewer "cleaning up" his code.

      5) Received company-wide email about a build that flat-out didn't compile - apparently someone hadn't bothered compiling a patch, and had sent it to a code reviewer, who likewise hadn't bothered compiling it before authorizing it.

      Now I'll admit that there are also a whole lot of "well, it only took five minutes, so it wasn't much of a waste" cases. But so far I haven't heard one person talking about how useful the mandatory code reviews are.

      Maybe it's just an artifact of the kind of programmers working at this company, or the kind of code being worked on, but so far code reviews have been a net loss in my experience. I've taken to doing major changes in my own personal branch of the repository (which doesn't enforce the code-review requirement) and in a month or two I'll have 3000 lines of code for someone to look at - but at least I won't have nickel-and-dimed them to death with 120 100-line code reviews, 3/4 of which I will inevitably end up deleting entirely.

      Note that I'm not saying "code reviews are bad" - what I am saying is that there's a time and a place for just about every technique, and there's also a time and a place where each technique is worse than useless. Pick your battles and pick your tools.

      --
      Breaking Into the Industry - A development log about starting a game studio.
    2. Re:Code review and pair programming by Unkle · · Score: 3, Informative
      Sounds like your company has a bad process. Having a formal code review after each check in is crazy. Reviewing code when a task is declared completed makes more sense, or even doing regularly scheduled reviews.

      Our company has some loose rules (we're working on strengthening them) that state that checked in code must be unit tested. This is to prevent things like your #5. But we haven't gotten to code reviews yet. Being on the team that's working on our process, I'll remember your experiences when we get to code reviews.

      --
      Against stupidity, the gods themselves contend in vain.
    3. Re:Code review and pair programming by Alan+Cox · · Score: 3, Insightful

      If you are bug hunting then the code review needs to be an explanation of what the code does. "We get a foo, we have to decide if its in US or UK format so we compute both checksums and .. oh umm.. I'll come back later'

      It's very different to things like design reviews. They have their place too. A lot of things Linus rejects are really design review things. Its not uncommon to get a "Yes this needs fixing but do it this way instead". It works well providing the person saying that has good judgement.

      Bad code review, bad tools, bad compilers and bad managers are _all_ useless

    4. Re:Code review and pair programming by someme2 · · Score: 3, Insightful
      [... Examples of how code reviews slowed down this guy's work without doing any good ...]

      If this happens to you on a regular basis then you are probably a better-than-average developer. Which is just fine as long as we find a way to make your work more average. And code reviews seem to do the job.

      Seriously, the productivity spread between developers (20 times as effective... adding more people... Thank you Mr. DeMarco) is what a lot of very strict process models and practices (such as code reviews) really attack - and it is a good thing, too. Because otherwise developer workforce does not scale well.

      The productivity spread is the enemy of plans, predictions, estimations and bureaucracy. Bureaucracy is the most successful human scaling mechanism.

      In other news: Big cooperations have difficulty exploiting the individual genius of low-level members of their workforce.
      --
      You can attach boosters to anything. It just costs more. -
      Anonymous Coward on Sunday November 07, @12:26PM
  6. Testing is good by TreadOnUS · · Score: 4, Insightful

    But the real key is reducing the number of defects introduced into software. Testing only finds existing errors. If the number of errors are low from using good requirements, design and development practices then testing becomes less expensive and time consuming.

    1. Re:Testing is good by djmurdoch · · Score: 3, Insightful

      Testing only finds existing errors.

      No, testing finds new errors. That's what test suites are for: to let you know when your change to X caused Y to break.

  7. Testing and releasing software by plcurechax · · Score: 4, Interesting

    My employer produces a large-ish software package, with 10 years of history and a small, 2-3 people, development team. Since I joined we have made massive strides in automating the build process, include some unit tests, and a few smoke tests in an automated process.

    Well, the effort paid off. Before we supported one version of HP/UX, and one release of Linux, now we support HP/UX (still a pain), and 4 looking at going to 6 Linux version/distributions and it is less work to produce a release now than ever just a year ago.

    Tools like automake, autoconfig, libtool, cvstrac and of course cvs have made my life bearable.

  8. Paths to quality by Anonymous Coward · · Score: 3, Insightful

    The links seem dead so I will add my .02. The programmer's view of the software should not be confined to the source code control system. Programmers should know how to install and implement the software they design and code. Programmers should have some personal experience supporting the software they code. NOTHING highlights the weaknesses of your software faster than being forced to work a support line/forum, etc. Establish personal relationships with employees in the sales force and management. You will be able to be more influential in the company if you do this. Establish personal relationships with your customers. You can use them to push your agendas. Paying customers have some of the most pull with your company. Use this to your advantage.

  9. Code validation tools... by tcopeland · · Score: 4, Interesting

    ...are nifty. They can catch all sorts of stuff and produce lovely reports - or, well, at least functional reports. And running them nightly - or hourly - helps to ensure the code won't get out of sorts.

    PLUG: Need to check Java code? Try PMD!

    --
    The Army reading list
  10. Keeping prototypes just that by mark1348 · · Score: 4, Insightful

    You can't help but be frustrated when dealing with projects that were obviously "proof of concept" which then evolved directly into the actual "product". Hard to resist but just plain stupid. I wish more open source projects had strict standards.

    --
    yomomma.org/
  11. Interfaces and contracting... by LeonardShelby · · Score: 3, Interesting

    Reusable, reliable, quality software begins with the interface. If someone cannot tell what a routine or module does with just a quick read, then all is lost. They'll cease to believe what the documentation (if any) says, and go on to write it themselves.

    The solution is better interface design. Clear, concise naming without ambiguity. And including the specification is absolutely necessary. With the contract included as part of the interface, there is even less chance for error and/or any ambiguity. Testing is aided because the rules for calling a routine are right there with the routine interface and comment.

    Unfortunately, most programming languages refuse to support contracting in any form, and most developers don't see the benefits. Until this hurdle is breached, quality software will not be achieved.

    Steve

    --

    --
    remember Sammy Jankis
  12. Re:2 words by Unkle · · Score: 5, Funny
    I actually had a coworker marked down on his yearly review last year for wanting to write re-usable code. Our manager's (very VERY flawed) opinion was that, though it might be nice to have the re-usable code, just write it for this specific task because it's just easy and fast.

    The kicker is, this year that same manager wants to re-use the code that my coworker was origionally going to write.

    --
    Against stupidity, the gods themselves contend in vain.
  13. There are different types of code reviews... by Richard+Steiner · · Score: 4, Insightful

    We used to implement code reviews at my former workplace, but they were more "sanity checking" peer reviews than anything else. They didn't take very long, and it gave one or two other people a chance to see how understandable or generally logical the changes were.

    That type of thing doesn't work as well for large changes, but we found that for small ones it sometimes can be a useful thing.

    --
    Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
    The Theorem Theorem: If If, Then Then.
    1. Re:There are different types of code reviews... by TreadOnUS · · Score: 3, Interesting

      This type of sanity checking is especially useful for training junior programmers. It can be very instructive for a senior programmer to sit down with a junior progammer and go through their code together. The primary purpose of a review should be to have a second set of eyes on the code but it is very valuable for training and communication as well.

  14. Write the tests *first* by wowbagger · · Score: 5, Insightful
    More importantly, write the tests FIRST. Then write the code, updating the tests for anything that is identified during the coding.

    This has several important benefits:
    1. You have to DEFINE what the module is to do so that you can write the tests. Granted, the first pass for the "tests" may simply return "failed" until something is written for the module, but at least you will have a chance to think about what you should be testing.
    2. You actually DO write the tests, rather than blowing them off. If your manager says "Why aren't you working on $blarg?" you can say "I *am* working on $blarg" since the first step is writing the tests.
    3. As you get funtionality working (as demonstrated by the tests passing) you can quickly determine if a later addition to the code breaks the working feature - and fix it while the change is still fresh in your mind (and hopefully BEFORE you commit your changes to the mainline code path (you ARE using a source code control system, aren't you?))
    4. You can automate the testing of the system.

    --
    www.eFax.com are spammers
  15. Being on a chip by AnuradhaRatnaweera · · Score: 3, Funny

    Wonder if he also talked about being on a chip. ;-)

  16. Re:2 words by johannesg · · Score: 5, Funny
    Ha, that's nothing. Long ago I used to work for a company that thought it was a good idea to NEVER reuse code because then you would reuse all the bugs as well. OTOH, they reasoned, if you wrote it from scratch you wouldn't be copying old bugs, thus this was a safer thing to do.

    I'll leave the results as an exercise for the reader...

  17. Linus already covered this by jaymzter · · Score: 3, Funny

    "regression testing, what's that? If it compiles it works and if it boots it's perfect!" - Linus

    'nuff said

    --
    If thou see a fair woman pay court to her, for thus thou wilt obtain love
  18. Good practices by vinukr · · Score: 5, Insightful

    These are some things i guess is necessary for good software
    1) Reviews at all stages.(Reqs/design/dev)
    2) While at development, u sure must know whats the most efficient way to code a design (which libraries are more suitable etc)
    3) Unit testing and Integration testing (when the project is huge)

    Some practices that managers can really use to take the pressure off the team
    1) Try giving buffers to the team (seriously, it works)
    2) Proper Code management (Lotsa rework and pressure come due to lack of this)
    3) Proper tracking and status updates to the customers

  19. Didn't know he used Gentoo... by cs02rm0 · · Score: 3, Funny

    emerging techniques for producing higher quality software

  20. MBA? by Anonymous Coward · · Score: 5, Funny

    So now we're taking software writing advice from PHBs now? :)

  21. WHY, not what by wowbagger · · Score: 4, Informative
    The single best rule of comment is "Comment upon the WHY, not the WHAT".

    Don't say:

    double sum = 0.0; // zero sum
    for (i = 0; i < len; ++i) // all samples
    {
    double signal = buf[i]; // get value
    sum += signal*signal; // add signal^2 to sum
    }
    return sqrt(sum/len);

    say:
    // Compute RMS average of signal -
    // compute the sum of the squares of all values,
    // then compute the mean (sum/len), then the
    // root of the sum - hence Root-Mean-Squared

    double sum = 0.0;
    for (i = 0; i < len; ++i)
    {
    double signal = buf[i];
    sum += signal*signal;
    }
    return sqrt(sum/len);
    In other words, tell me WHY this code added the square of the signal, not THAT it added the square of the signal.

    Moreover:
    1. Every directory of the project should have a purpose, and should contain a short README describing the purpose of the code in the directory.
    2. Every file should have a header that describes the purpose of the file.
    3. Every function should have a header describing the purpose of the function, as well as any inputs and outputs (including global, static, and class variables), any exceptions thrown, and any assumptions made.
    4. Blocks of code within a (large) subroutine should have a descriptive block comment describing the overall goal of that block (e.g. "Now we walk the list of conversations and update the call stats").
    5. Comments on a line of code shouldn't be needed normally - the code should speak for itself. Only pretty tricky things ("use a shift and add rather than a multiply as this saves 3 clock cycles") should need a comment at end of line.

    If more folks would follow these rules it would be a HELL of a lot easier to follow their code.

    NOTE: If you can say it in the code, do so - if you can specify the exceptions to your function via a "throw(int code)" type statement, then do so rather than using a comment.

    Remember - the code tells the COMPILER and the programmer what is going on, the comments tell the programmer WHY it is going on.
    --
    www.eFax.com are spammers
  22. Re:2 words by sootman · · Score: 4, Informative

    And for those who don't like exercise, I suggest Joel. Samples:

    "The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. Au contraire, baby!... it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes.

    One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.

    Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters. When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work."

    --
    Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.