Cold Hard Code

Building a better mousetrap

I wrapped up a meeting to decide how we are going to move forward.  Our current, well, everything was showing too many signs of aging.  Queries that were inefficient were now blowing up, as our dataset grew to several hundred thousand rows.

In the discussions, and many previous to this, I discovered that a lot of engineers don't want to build mousetraps.  What happens is they build traps that can catch mice, but they could just as easily catch a laden or unladen swallow.  This is, quite clearly, because mousetraps are boring.

Especially because each software solution is just unique enough to your specific business to not be able to just do a bulk copy'n'paste and be done with it.  No matter the solution, there is always some programming that must be done.

As proof, I submit to my gentle readers Drupal and any other leading CMS.  If you want to step outside the bounds of what has been done before, you will have to learn some PHP.  Thus, any person looking to implement a solution has a very simple choice: Is there a willingness to forego features that may be wanted (or needed) to avoid customized programming?

If yes, then there are plenty of software packages out there to do anything you could possibly want.

Unfortunately, it is nearly impossible to say yes.  Now we're stuck with some customized programming.  However, there is a problem with this.  Most developers who are well skilled don't want to customize a prebuilt solution.  They want to build their own.  It's boring to customize a prebuilt solution, and the people looking for this aren't paying enough to capture quality developer attention.

What inevitably happens is subpar and inept developers building subpar and ineffective solutions, frustrating business owners who are paying the bills.

If a developer/team is hired to build something custom, and candidates are screen appropriately, you'll be happier but it will also go over time (and most likely budget).  However, the end result will be something that works well.

Your mousetrap.  Complete with swallow-killing capabilities.

The solution is, in my humble opinion, more frameworks and less applications.  This is one of the reasons why I love the Perl community so much, and fervently defend it from misguided criticisms.

Yes, there aren't any killer applications written in Perl.  Movable Type is good, but certainly nothing that inspires a developer.

The real strength is the framework.  Mediocre and skilled programmers alike can build quality solutions just by crawling through the CPAN and finding the modules they need.

The problem with that is the list of modules is daunting, and without being in the Perl community and recognizing author names, you don't know what is a good module to use.  There are a few methods, but you still have to be part of the community to know they exist.

You could look at star ratings, release history, or just follow dependency chains.  Nothing is really a steadfast marker to inform a new user, "This is the choice for you."

So, what's my solution?  More blogging and writing about what tools people do use.  Get the word out, gauge quality by people posting recipes.

Then, developers have more information than just the module documentation and they can see how people are using it.

Finally, developers can create custom solutions from the wonderful frameworks that exist in Perl, without writing everything from scratch or customizing a generalized "all in one" solution. 

Up next I'll talk about why I think people discount using Perl (and it isn't the language).  For now, I'll let this simmer.