Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

heusserm (4461)

  (email not shown publicly)
AOL IM: MatthewHeusser (Add Buddy, Send Message)

Matt Heusser is JAPH and an XP-Er []. (The Methodology, not the Operating System.) Right now, he's doing a lot of Test Driven Development in Perl.

Journal of heusserm (4461)

Thursday October 23, 2003
06:44 AM

Perfect Vs. Good

In Unix Vs. MIT cultures, one of the recurring themes is "The Right Way" Vs. "The Good Enough Way." Another way to put this is "The Perfect is the Enemy of the Good."

Pyscologists have a term for someone who expects too much: A Perfectionist. The Perfectionist's dilemma is that they can't every get started on anything until they have it planned, and planned perfectly. As a result, it's nearly impossible for them to move from planning to actually implementing (doing).

What does this have to do with Perl? In class last week, we were talking about 5th generation langauges - declarative languages that understand the context of your words and can figure out meaning, instead of relying on syntax. Dr. Leidig said that the ideal programming language would be able to parse english sentances. Not quite to the level of a turing test, in that it doesn't have to reply in english, but pretty close.

So, of course, ProLog and LISP come up, and Bill Day says something like "Any Language with a DWIM (Do What I Mean) command has got to be another generation." We discuss how ProLog and LISP truely are AI languages that can truely understand context - but not english context.

Of course, I mention Perl. The professor's response is something like "Yes, Perl was an ugly, early attempt at grokking context." (Ok, he didn't say Grok, but that's what he meant.)

So here you have this computer language that no one in class has been formally trained on, yet several of us have used to create large, complex, mission-critical applications. And you have LISP, that several people have been formally trained on, and yet pretty much none of them have written more than two or three lines of code in. The first language is Good, the Second is Perfect.

To borrow a line from Joel Spolsky, "What's going on here?"

Well, the Perfect is the enemy of the Good here, and Good is certainly Good Enough. "Learning LISP" has been on my to-do list for several years, but i've never had the time. "Learning Perl" wasn't even on my to-do list back in 1997, but I needed a quick program to grep some data, and the code was so trivial that I didn't have to "learn it."

Doing a google search, I found this explanation of how Good can be better than best - simply put "getting to best usually gets complicated."

More searching nets the original quote to Voltaire. Anyone have any additional insight into this?
Friday October 10, 2003
07:10 AM

The easiest way to make money quick ...

... It to sell someone else a way to make money quick.

When what you are selling is in fact your own system, that's called a ponzi scheme or a pyramid scam and it's illegal.

However, "one level deep" pyramid scams are legal and very common. Probably the most common is the Real Estate Plan - "Make millions in real estate with no money down."

Of course, the people who are making the millions are the ones selling the plan. Otherwise, instead of TV info-mercials, they would be out buying real estate, wouldn't you think?

Another common one-level deep pyramid scam is the 2nd-or-3rd-Rate College-MBA scam. I'm sure you've heard the Ads on the Radio: "Earn your MBA Part-Time in about 6 months without leaving the comfort of your living room ..." these ads all but guarentee employment and a big salary once you get the MBA.

Of course, they also exist for BS/BA and AA programs - very often in Computer Stuff like networking or, my goodness, computer science.

Of course, there is a large group of people who are ... less than swift. For some reason or other, these people lack the skills to get and keep a high-paying job. What they desparately want is a "sure thing" - a degree or certificate to earn to "guarentee" them a high salary.

So, they go to Joe Schmoe College and earn an MBA. And, of course, they still lack interviewing skills - and - more importantly - analysis skills. So they can't really make use of the MBA. (It's from Joe Schmoe anyway, which isn't exactly Ivy League, so it's easy for employers to blow off.)

One big problem is that this increases the pool of available, incompetant MBA's - which decreases the percieved value of the MBA itself.

Simply put, this is essentially why I oppose Perl Certification. Eventually, training companies would spring up that will allow incompetants to pass the test - and hiring managers will begin to say "Perl? Nah, I think we should use Java. We hired some Perl certified programmers for the flim-boozle project and look what a mess they made ..."

Friday September 26, 2003
08:16 AM


Yesterday, Andy Lester came to Gr.PM and gave a revised version of his talk Automated Testing of Large Projects in Perl. It was a blast.

That morning, the GR.PM steering comittee met with Andy for Breakfast. Speaking of CMM, Andy replied "Well, let me ask you this: How much are you Into Extreme Programming?"

Al Tobey replied "Well ... we've got Matt."

Considering the person it came from, I consider this one of the greater compliments I have ever received as a programmer. Thanks, Al.
Friday September 19, 2003
11:32 AM

Construction project management

Our contractor's notion of what a ``schedule'' is drives me insane. It seems like when he says, ``it will be done by wednesday afternoon,'' what he means is, ``the guy who will be doing the actual work told me it will be done by wednesday afternoon.'' But the thing is, he knows that the guys who work for him are total flakes, and sometimes just don't show up at all. Yet his answers suggest that this takes him by surprise every single time. So it has proven utterly impossible to schedule anything based on his dates. He seems to think that answers like ``well the guy didn't show up'' should satisfy me, when I have to call up the person I've scheduled and tell them, ``oh, nevermind.''

From Some other Guys Blog (February 27th, actually)

This is pretty much the exact story of my bathroom modelling, only on a larger scale ...

(No, it wasn't "re" modelled, it was modelled. I put in a bathroom where there was no electrical or pipes in the first place ...)
Thursday September 18, 2003
01:26 PM

Critical Success Factors

If you check out the various forums and magazines for software developers today, you'll find a lot of whining: Software Developers are mistreated, underpaid, over-worked, easily laid off, h1b this, overpaid CEO that, blah, blah blah.

I have to admit, I've spent a great deal of time as a whiner. The truth is, lots of coders are under-paid and over-worked. They have been loyal, or dedicated, and not been rewarded. They worked thousands of hours of overtime for that $250.00 bonus and did the math. They are peeved.

Now, I ask: Why do you think that is?

In my opinion, it's pretty simple. Not only do software developers lack negotiation skills, they often don't even RESPECT those skills!

How many times have you heard a coder say out loud "Sales is something I never want to do."

Is it any wonder that, when that coder gets laid off, he has problems getting a job? After all, the most common way to find a job is to sell youself ...

(Yes, the further you get in your career, the more reputation and free gifts sell yourself for you. I'm mostly talking about entry-level and all-proprietary shops here.)

Last week in class, we covered "Critical Success Factors". It's an info systems policy class, and the idea is simple: Identify the things you MUST do right, and everything else will fall into place. On the other hand, if you do them wrong, you've set yourself up to fail.

Then you make sure you nail your critical success factors.

It occurred to me that, for most smart coder-types who want to become independent consultants, the Critical Success Factors (CSF) are sales, marketing, and relationship-building. Working independently, the coders are going to be able to do just about any work for hire. The challenge is getting the work in the first place.

That's the critical success factor. What surprises me is that there are so few folks talking about that - we'd rather spend our time talking about kwikis and FIT and whateverelse new toy is our now. hmm.

Vaguely Related:

Wednesday September 17, 2003
01:11 PM

Attitude in Programmers

This issue came up recently ...

The problem is that productivity of software developers is hard to measure.

Thus, the guy who says "I am the most productive" the loudest and most effectively is credited with being the most productive.

We've all seen the guys who make a big deal about how complex, or important, or hard the projects they are working on are - or how much overtime they work, or whatever.

These guys are often inflexible, judgemental, and not teachable.

Yet, in the arena of office politics, they tend to win, because people tend to repeat things they've heard. Thus, the boss hears from -other- people that joe is smart, hard-working, working on a complex process, etc, etc.

Objective, Impartial measurement of the productivity of software developers would fix this. Of course, if you figure it out, let me know - we can bottle it and sell it and make billions. :-)

06:33 AM

Exception Handling ... hmm

Right now, I'm running into a lot of legacy code like this:

sub GetValues
    my $dbh = get_connection('databasename');
    my $sth = $dbh->prepare('Select * from table_name');
    my $r;
    my @a;
    while ($r = $sth->fetchrow_hashref) {
        push @a, $r;
    return (\@a);

my "Improved" version would look more like this:

sub GetValues
    my $dbh = get_connection('databasename');
    my $ok = 1;
    my $msg = "Success";
    my $sth;
    if (!$dbh) {
        $ok = 0;
        $msg = "Failed to get connection to databasename in GetValues";
    } else {
        $sth = $dbh->prepare('Select * from table_name');

    if ($ok && (!$sth)) {
        $ok = 0;
        $msg = "Call to prepare failed in GetValues";

    my $r;
    my @a;
    if ($ok) {
       $ok = $sth->execute();
       if (!$ok) {
           $msg = "Call to excecute failed in GetValues";
       } else {
           my $r;
           my @a;
           while ($r = $sth->fetchrow_hashref) {
               push @a, $r;
    return ($ok, $msg, \@a);

  Note that my new code is literally TWICE as long as the old code.  Often, it's longer.

  Is this really advantageous?  In the long run, it feels like I'm trying the same things over and over again.  I actually made a module to abstract out the if-ish ness of the this routine, but the functions got to the point where they were taking 6+ paramters, some of which were optional.  It was just ugly.  So I've stopped using it until I can do it over again with anonymous hashrefs and "named params."

  The net result is that plenty of folks are saying "error checking is over-rated", and I can see where they are coming from.  What's the "right" answer?

Friday September 12, 2003
07:04 AM

Old habits die hard

"Hi. My name is Matt, and I spent a great deal of time coding in C++"

I've found that my C++ idioms end up in my perl code. Here's a code sample:

#begin sample

sub DoStuff
        my $blnOk = 1;
        my $strMessage = "Success";
        my $dbh = Get_DBH_Function();
        if (!$dbh)
                $blnOk = 0;
                $strMessage = "Couldn't get DBH";
        return($blnOk, $strMessage);
#End Snippit

I've got if ($blnOk) fields to get the DBH, to get the STH, to prepare, to execute ... blah.

How about something more like this?

#Begin Snippit #2
use Carp;
sub DoStuff2
        eval {
                my $dbh = Get_DBH_Function();
                if (!$dbh) {
                        croak "Failed to get dbh in DoStuff";
                #More code ...

        if ($@ ne "") {
                        return(0, $@);
        } else {
                        return(1, "Success");
#End Snippit #2

Of course, the 3rd way to do it is to Croak without the eval, and trust the calling routine to eval it - The BSD way. But I'm not convinced.

The morals of the story:

1) I'm thinking of dumping my hungarian notation
2) I'm thinking of changing my curly-brace style so my code is more compact
3) I'm thinking of adding some structured exception handling instead of writing structured code. (IE, Most of my current code has one entry point and one exit for each function, and returns status state and messages.) Since I won't have try/catch until perl 6, I'll make do with eval.


Thursday September 11, 2003
02:23 PM

Who needs software architects?

Martin Fowler Quantifies something that's always been an itch of mine.
12:22 PM

My last post


    Folks who read my last post seem to think that I was saying: "Make your programs so they can't break, and you don't have to test them."

Well, that's half right ...

    If you break your functions down far enough, but not quite to the absurd, you can understand the entire function at a glance. Then, you can know they work correctly because you can completely follow the logic of the entire function.

    Military strategists got it right with the idea of span of control - it's hard for most people to keep track of more than about seven things at once. When functions get too complex, something falls out ... and that something can all to easily be the limit of a loop index, or an "else" at the end of a long conditional.

    By keeping functions small enough that they can't break, we can avoid all that.

    Does that mean we shouldn't test?     CERTAINLY NOT! Check the comments on my last post for plenty of reasons why you should test even things you think can't break.

    In fact, in his presentation Testing Large Systems in Perl, Andy Lester suggests that you should test things that can't possibly break anyway.

1) Writing the test takes all of 2 minutes
2) It's automated - running the test is nothing.
3) Things may change.
4) You might have been wrong.

Again - my point - sure - test early, test often, test always. But minimizing the number of things that could possible break is still a good thing.