Nearly two years ago, I was tasked with finding a phone that had reliable email service and basic features to perform emergency maintenance while on the go.

I sampled a lot of phones, and got rather upset.  The one phone through all this I didn't sample was the iPhone.  The reason was that the app store wasn't live yet, and the stock application set obviously didn't work (no SSH, etc).

However, by the time I finally made a decision the app store was like a week away from launching.  I then decided to look at the iPhone.  After sampling probably 10-15 devices that met the basic requirements (3rd party app support, email client, document reading) it was very clear that the iPhone was by far the best device.

Fast forward 2 years to today.

My phone was getting "tired".  iPhone OS 3.0 unveiled new features, and a lot of apps were sluggish.  This isn't really the fault of the phone, it's just that developers will, without fail, use the hardware available to the fullest extent.  I also am seeking out some tax writeoffs, and the phone is a business tool.

Now, the playing field is a little bit different. 

I've never liked the BlackBerry devices.  The media player capabilities aren't very good, and the apps just seem mediocre. 

The Palm Pre looks cool, but I really don't want to be on Sprint.  Also, the app store is far too spartan.  There is no SSH client for the Pre.  This is amazing.  If Palm really wanted to eat Apple's lunch, they should have included a Terminal app by default (hidden/not-installed) and let the geeks go crazy.  Geeks would love that, just like WebOS is pretty cool for the geeks.  Nope, missed the boat on that.  In fact, every time I look seriously at the Palm, it just seems like they missed the boat.  Cool features, last year.

That leaves me with the Android offerings.  I really would love an Android phone.  However, T-Mobile only.  Verizon will get some soon, and I love Verizon and would love to switch back.  The reason I won't consider T-Mobile is because years ago I had a Sidekick.  They bricked my Sidekick with an OTA update, I had to fight tooth and nail to get them to replace it without charging me, then the replacement broke and they said my warranty didn't carry over.  Yeah, screw T-Mobile.  That, and the myTouch 3G is getting mediocre reviews.  Not very compelling.

So, what to do?  I just stuck with what I know and enjoy.  I bought an iPhone 3GS.

Verdict?  It's awesome.  Everything from my old phone is there; all the apps and their data, everything.  It just is faster.  The camera is great for a phone, and the video editing is amazing.

It's really nice to have my expectations exceeded by something as simple as a phone.  If only they weren't set so low every time I go shopping by expecting to hate it.

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.

Lately, for a variety of reasons, I have been doing what I call "click through testing".  This is basically trying to pretend I'm a user, and click around.  You can't write unit tests or acceptance tests for these things.  It's just me clicking around randomly, until I think of something to do, and then I do it.  Or attempt to, and fail.  In which case a ticket is opened and work is created.

The most important thing is that I've found a lot of inspiration on how to do things better, and noticed little nits that are hard to fix after the fact.  These nits are usually easy to work around if you can identify them before you start the project.  The end result is a more usable and robust application.  On my list of things that make better applications, this is right under mandating styleguides.

I've been thinking to employ it in a more productive setting, and once a day completing some random task that users routinely do.  A simple recording mechanism to figure out what things suck and what things should be looked at as positive examples.

If you ask that the developers in your team start their morning out by spending 5 minutes (no more!) on your product to do some atomic thing that a typical user will do, you'll get the best feedback around.  It is a very simple task, and is a good "welcome to work" warmup routine.

I was thinking that it'd be great to randomize featuresets, then assign them (otherwise the act of thinking what to do would consume 4.5 of the 5 minutes).  After completion, a very quick questionnaire with just some sliders going from "Bad" to "Good".  Usability, clarity, efficiency.  That's what you care about.  Reporting is easy, and again, the rating should take 30 seconds, tops.

You're not going to make all users happy, but I really think that the reason why software gets convoluted and difficult to use is that so few developers go back and look at what they have built.  If, after several months, a developer still remembers the nuanced details for each step it won't have much impact.  The real impact will be doing things they've never done before (written by someone else) or that they've forgotten.