Jan 10 2006 811 hrs
      My article Tradeoffs in Methodology Design has sparked quite a bit of discussion, so I have followed it up with a "podcast"-style recording that might make it's way into an article someday. If you want to, please listen to the podcast, or the shorter snippet and let me know what you think of the format and the content. It's something new; I figured it was worth a try.

    Jan 20 2004 811 hrs
      Look at the help wanted list at any job board, and it's clear that employers view CS as a set of acronyms to be learned. VB, JCL, C#, Perl, UNIX, HP-UX, blah blah blah. Never mind what college was supposed to really teach us: The theory behind CS that we could then go any apply to any language. Software Development is not a skill to be learned in 21 days, It's a craft to be learned over years.

    Nov 19 2003 0744 hrs
      I've always had a vague feeling that, when you move toward Agile/XP, you still need someone to do system testing, GUI testing, and to help the customer with acceptance tests. Stickyminds has an article this week on the tester role in an agile environment; I found it interesting.

    Aug 5 2003 0730 hrs
     I now have blog on use.perl.org!
     I wrote Another business/CS article, this one on AngryCoder.com

    May 07 2003 0801 hrs
        Who is this Heusser guy? (And Larry Wall, and Gerald Weinberg ... so I'd say I'm in pretty good company.)

    May 01 2003 1200 hrs
        Yes, every software Developer should read a rather long list of books:

        The Mythical Man Month, Rapid Development, Writing Solid Code, Quality Software Management, Extreme Programming: Installed, PeopleWare, The Deadline, User Interface Design for Programmers, etc. (The full list is long)

        These books are more often about people and process than technology and buzzwords - and books cost both time and money. So, to wet your appitite, here are a few articles by some of the authors above that are both free and short:

        No Silver Bullet: Essence and Accident in Software Engineering By Fred Brooks
        Why Does Software Cost So Much by Tom DeMarco. (The "main" essay of the book.)
        Cargo Cult Software Engineering by Steve McConnell
        The Iceberg Secret, Revealed by Joel Spolsky


    Apr 08 2003 1111 hrs
      A few days ago, I made an entry on my main page about Automated Unit Tests. They saved me again. This time, it was a minor change in a script. I asked a question something like:

      if ($strMode=="INSERT")
            { (Do some stuff) }
      else
            { (Do some other stuff) }

      Except, of course, in perl, == is a numeric comparison. So it was really asking if ascitoi($strMode) evaluates to 0, which strings tend to do - so the wrong part of the loop was executing. My automated unit tests not only told me something was wrong, they identified which function had the bug. Fixed and running again in 5 minutes. Sure, I've got to system test it and do a few other things, but now I've got some confidence that i've got it right. This ain't no snake-oil ...


    Apr 05 2003 2300 hrs
        Yes, automated unit tests really do work
        Two words: Maintenance Programming.
        I just made a rather large change to my code library; I improved the compression function. Of course, my mind went through a million different fears: What if this fails, what if that goes wrong, Omigosh, this library function is used by many different programs; how am I gonna test this?, etc. It would be hard for a system test to shake out all the defects introduced by this change, and it's hard to justify a full system test for every maintenance fix.
        Enter automated unit testing. The whole system had a series of automated unit tests. They passed before I made the changes; they passed after. Of course, I have to system test on Monday, but for once, I actually have some confidence that things are gonna work, and very little fear that I'll miss something.
        Making sure it compiles and crossing your fingers ain't got notin' on this ...


Mar 01 2003 1100 hrs
      It looks like i'm going to be writing a good deal of PL/SQL for Priority for Oracle databases. That said, I bought Learning Oracle PL/SQL, Oracle SQL*Plus: The Definitive Guide, and the 2nd edition of Oracle PL/SQL Programming from Amazon.com. If you have any tips, tricks, or advice for a new PL/SQL programmer, please drop me an email.


    Mar 01 2003 0820 hrs
       When people plan projects, they often pad the schedule for each individual step. However, once the schedule is padded:

  1) If they have free time, they burn it up on other, more "critical" tasks. (Multi-tasking)
  2) Given an extra week, they just start late (student syndrome).
  3) Should they finish early, they think of the extra time as "my time" or spend it making the code perfect.

As a result, On Large Projects, losses accure but gains do not. This means that Large Projects are late. Eli Goldratt wrote an entire book about a theory of project management designed to overcome these problems - it's called critical chain.

This is not some boring, fuzzy business textbook. Instead, it is a fast-paced business novel that explains Critical Chain in plain english. If you are looking for ways to overcome the 900 pound gorilla of late projects, I'd highly recomend you read Critical Chain. In fact, you can buy it from amazon today!



    Nov 14 2002 0815 hrs
      Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don't improve it. Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often. What you eat before you step onto the scale determines how much you will weigh, and the software development techniques you use determine how many errors testing will find. If you want to lose weight, don't buy a new scale; change your diet. If you want to improve your software, don't test more; develop better"
            - Steve McConnell - from SoftwareQuotes.com


    Sept 20 2002 0725 hrs
     New Articles on Software Development!      
      No, it will not take "Just Two Weeks"       The WaterFall Myth
      No, you will not "make it up later"       Sometimes it's Better Never Than Late
      Meaningful Mission Statements


    Jun 27 2002 0750 hrs
        The Essential Drucker
        (Heusser on Business Administration)

    Feb 20 2002 0800 hrs
        Tom DeMarco on Professionalism - Check this out!

    Jan 23 2002 1105 hrs
        Would your CEO do this?

    Jan 7 2002 1200 hrs
        A complete list of my published essays is now available Here.
        I've also written a Semi-Spoof titled Heusser On Science Fiction.
Professional Development
Matt is an active member (former President, founder, etc.) of the Grand Rapids Perl Mongers as well as a Captain in the Civil Air Patrol. He serves as Leadership Officer in the Boulle-Norman Memorial Cadet Squadron.