Thank you, patient readers, for indulging my long absence.  I will be adding some new articles shortly, including nifty tricks you can teach Subsonic to do, more C# .NET Interop magic, more news from people with similar DNA, and perhaps some revelations on audio processing, IMVU and search engine strategies for your blog.

I was interested to see how people are finding this blog.  It appears to be a common practice for IT recruiters to google prospective developers.  Many people are finding this blog by my name "Chris Velazquez", as well as the misspelling "Chris Velasquez".  In fact, a google search on just "Velazquez" shows this web site in the top 100 results, despite the more obvious relevance of Spanish painter Diego Velazquez, congresswoman Nydia Velazquez, and the fact that Velazquez is quite a common name in the Spanish-speaking world.

There seems to be some interest in C# dictionary of delegates, an alternative to using a switch statement.  While this isn't an earth-shattering revelation, several programmers have picked up on this technique, and I am beginning to use it more frequently in certain parts of my own code.

As expected, many IE7 users want to use BugMeNot to bypass mandatory registration.  And also as expected, people are having problems trying to get MS Office and Excel to work seamlessly with their C# code.  Surprisingly, the image of my daughter holding balloon with static cling in her hair is becoming a hit on the search engines.

I'll be fertilizing this blog with my mental droppings shortly.  Stay tuned!

I've raised the white flag.  I've had it with hosting e-mail.  I just purchased an e-mail hosting plan from GoDaddy, and I'm in the process of moving all the e-mail accounts.  And instructing customers on how to change their Outlook settings for the new system.  Hopefully, I can get everyone moved over in the next couple of weeks.

The sordid tale of the tar-baby from hell begins about four years ago, when I was having problems with the ISP that was hosting my e-mail service.  As things happened, I came upon an open-source mail server called Lumisoft that was written in C# and was able to handle SMTP relays, POP3 inboxes, and had a cute WinForms UI for administration.  It must have been the macho call of the wild - I can do this!  I grabbed an old computer, wiped it clean, installed Windows 2000 Pro on it and set up the mail server.  I had initially intended to use it for just my own purposes, and my wife and I used it for our e-mail.  But as things progressed, I started getting calls from customers who were getting angry that their ISPs weren't filtering their spam and letting e-mail viruses get through.  So I picked up SpamAssassin, and wrote a couple Perl scripts (shoutout: using ActiveState ActivePerl) that would comb the mail looking for spam to tag and also tossing out anything executable.  These Perl scripts were fired off by a little C# Windows Service I wrote in a half-hour.  And I'm happy to say I haven't had a single e-mail virus in Outlook in four years.  But things quickly deteorated.  To summarize:

• Network downtime - my ISP doesn't answer the phone on Sundays, so when do you think it goes down?
• Security Breach - a slacker at my ISP had a null VPN password, allowing a Japanese spammer to hijack my mail server as his own personal SMTP relay.
• Spam - causing an increasing burden on the old 450 MHz Pentium II.
• Abandoned E-mail Accounts - piling up the spam and filling up the disk
• Disgruntled Customers - I always know when the mail goes down, oh, I hear about it!
• Clueless Customers - who sign up for all sorts of online crap and wonder why they have so much spam!
• Hardware Issues - Ugh

I've had it up to here, and now I'm putting POSTAL to pasture. (Yes, I named the computer "POSTAL" as a joke.  Ha ha, just serious.)  I can get 100 POP3 e-mail accounts from GoDaddy for just $30 a year, and it comes with a webmail interface.  The admin interface is a pain in the rear, but I'm sure they can do a better job with uptime than I can.  I will miss having a bottomless e-mail account that users could send 100 MB files to, but the need for that has decreased as well.  At least I won't be wasting any more time on this.

This is better than going postal.  Don't you think?

I just came across an article from Jakob Nielson's UseIt.com web site concerning Weblog Usability.  I figure I should go ahead and take the test and see how my own blog stacks against the ideals of the guru.

Top Ten Design Mistakes in Weblogs:

1. No Author Biographies - Not guilty

I have my real name and some real info about myself in the "What's this?" box to the right.  If you visit my home page, you can even download my resume.

2. No Author Photo - Not guilty(anymore)

Yes, I have posted an unflattering, but honest picture of myself.  I do have a nice picture of myself that was taken at my wedding by a professional photographer almost 17 years ago.  I don't think I can really use that, though.

3. Nondescript Posting Titles - Not guilty

I just barely squeaked by on this.  I try to title each blurb accurately, and when I'm in a playful mood I may throw in a double entrendre, such as "Nutty Warnings".  Some titles are lame, I admit it.  I throw myself on the mercy of the court on this count.

4. Links Don't Say Where They Go - Not guilty

This is classic Web 101 fare.  Search engines look for this; SEO depends on it.

5. Classic Hits are Buried - Guilty

The dasBlog software doesn't lend itself to breadcrumb navigation, and I have been too busy/lazy/apathetic to do anything to about it.  I don't have any real "hits" because I have so few readers that it probably doesn't matter.  I'll get off with probation on this.

6. The Calendar is the Only Navigation - Not guilty

I do add categories to each blog entry, honest, officer!  Once again, I'm at the mercy of dasBlog on this one because it show categories in a linear fashion instead of a hit-based or frequency-based heuristic.

7. Irregular Publishing Frequency - Guilty

I have not made a serious attempt to publish regularly, even though I can write quickly.  As they say in the Holy Grail, "I'm getting better".

8. Mixing Topics - Guilty, Guilty, Guilty

The fertile crevices of my brain are aching to explode with information to tell the world.  While I do try to keep the topics programming-related, I suffer from ADD of the fingers.  What was I writing about, now?

9. Forgetting That You Write for Your Future Boss - Hung Jury

I have deliberately refrained from including profanity and NSFW content from my blog.  So I get a silver arrow point for that.  Some people might be offended by my cheeky humor and unabashed assessments.  If that's the case, then they have a problem with my personality.  One of my criteria for accepting a new position is that I can get at least a chuckle during the job interview.  If my boss has no sense of humor, chances are he will melt down or blow up during a difficult situation, which will make my own life miserable.  So I guess in a way you can say that I am writing proactively in self-defense.  Yeah, that's it.

10. Having a Domain Name Owned by a Weblog Service - Not guilty

Oh, c'mon!  You can't spring the $7 a year it costs to have your own domain name?  Personally, I'm helping fund Bob Parsons' kids' college education.  But let's not go there.

The Verdict

Cleared on six counts, found guilty of burying the evidence, negligent publishing, and crossing the center line of my weblog.  I am hereby put on probation and required to attend a defensive blogging class as well as blogger sensitivity training.

Now, how well will YOUR blog stand up?

Last night, I was enjoying one of my favorite snacks, peanut butter on a spoon.  Not the salmonella-infested peanut-flavored Crisco that you buy at Wal-Mart, but the good stuff: organic natural creamy peanut butter with nothing but peanuts and salt.  And I looked at the label and saw the following warning: "This product was manufactured in a facility that processes nuts".  Now I know the placement of this absurd warning has something to do with legal liability, otherwise it would make sense.  This bears a certain similarity to the way we handle homeland security in 2007.

What would the world look like if we put these warnings on software?

• Windows XP Installation disc: Warning: this disc contains an operating system that is capable of executing coded instructions and may be susceptible to malicious activity.
• Microsoft Excel: Warning: Errors in formulas and macros may lead to incorrect results.
• ActiveState ActivePerl: Warning: Improper use of the Perl programming language may result in incomprehensible gibberish.
• World of Warcraft: Warning: using this software to excess may deteriorate your social life.

In a sense, I guess that's what the modal dialog box was created for.  Sometimes you actually do need a warning if there is a side effect to the desired action.  If I want drop a database table, I want to know before I clobber a bunch of related stored procedures and program code.  More often than not, though, it is for some patronizing reason that we "interrupt the proceedings with idiocy" (as Alan Cooper puts it).  "We can't just let the user do that", I've heard from marketing types.  I recently had the displeasure of executing an old VB app that someone had written.  It always prompts with a modal dialog whenever one decides to change MDI child windows.  Why?  The data had already been saved in the database - you could reboot the computer and the data would still be available.  These dialogs were totally unnecessary.

The key to avoiding dialog boxes ad nauseum is reversibility.  Any action needs to be undoable, or a group of actions taken as a whole need to be undoable as a group.  While at Conic Systems (now Tadpole Technologies) our software implemented an "Undo Stack".  This was a pretty sophisticated approach for the 1990's.  You can use a design pattern called "Command" to partially implement this.  Unlike the IDbCommand implementers in .NET, a good Command object has the ability to reverse itself.  You place all the Commands on the undo stack, so the user can undo anything.

Undo a database record - Make sure the command object has all the information it needs to perform the delete after add, the add after delete, and the data from changed field values.

Undo a file deletion - don't delete files!  Rename them and send them to the Recycle bin programmatically.  That way you can get them back upon undo.

Undo a graphical operation - use the State pattern to incrementally change the state of the drawing surface and roll back to the previous state.

OK, enough of my soapbox rant.  I don't care if people think I'm nuts.

And sadly, that woman was not Grace Hopper.  The winner of the coveted 2006 Turing award is none other than Fran Allen.  No, I've never heard of her either.  Apparently, she has been a lifelong IBM software engineer, and her accomplishments include, uh, er, something to do with optimizing compilers.  She is apparently the head of many different computing organizations and has spent a great deal of time teaching classes as an adjunct professor.  This reminds me of the adage, "those who can, do, those who can't, teach".  I'm at a loss to explain why Ms. Allen was selected to win the Turing award, other than she is an aging female software engineer, and she is still alive to receive the award in person.  She didn't even have an entry in Wikipedia until a few days ago, what's with that?

It's my opinion that if the ACM wanted to give this award to a woman that badly, they should have honored Grace Hopper posthumously, with her family receiving the prize.  Hopper had a major impact on the world of computing, with the invention of the COBOL programming language, and this impact was felt most forcefully as we approached the year 1900.  COBOL has always been the de facto standard for big-iron mainframes that crunch data in back offices that are impervious to its stench.  And to prove the point that people will actually pay money to romance a pig wearing lipstick, Fujitsu is keeping the corpse alive with NetCOBOL for .Net.

So I give my personal award for best lifetime achievement to a woman in the IT industry to Grace Hopper.  If it weren't for her contributions, we may still be using a variant of RPG or PL/I.  Nuff said.

I recently tuned into the podcast on IT Conversations, hosted by Phil Windley, and featuring David Platt, .NET programmer and author of the new book "Why Software Sucks".  In the podcast, Platt adds some new light to problems of user-facing software (as opposed to programmer-facing software).  Much of what he has to say has already been covered in Alan Cooper's unforgettable book, "About Face".

So what makes some software suck?  Software is supposed to make our lives and jobs easier to accomplish.  When software makes it difficult for a user to do things, or forces the user to remember things, or demands that the user do a complex dance with her keyboard and mouse, then that software sucks unequivocally.

But if you visit the computer lab and ask the programmers what makes software suck, they will have a totally different perspective.  Code that's hard to read, lack of unit test coverage, tight coupling of objects, redundancy: these are the problems that make software suck.

My opinion is that you can have the most highly refactored code, in all of its object-oriented goodness, and the software can still suck.  My fear is that there are many devotees of Martin Fowler and Uncle Bob, who in their own minds believe they are writing great software, but realize only after it has been foisted on the end user that it actually sucks.

When I tried to de-suckify a feature in the web application we recently released, I was often met with fierce resistance from programmers, whereas the business analysts were very open to new ideas on how to make the software more user-friendly.  One example was when we were required to build an interface whereby a loan representative could transfer the responsibility for a loan application to another loan rep.  In our lingo, this is called "pushing a loan".  The original specification required that the end user would enter the name of the receiving loan rep or their office then run a search against the database.  I believed that this method would be error-prone and that there ought to be any easier way.  I sat down with the business analyst in charge of this new feature and asked her "What do people use this for 90% of the time?"  She stated that most often, people would push the loan to someone else within their own loan office.  So I asked how she would like it if, when the user first selects the feature, he is presented immediately with a list of the loan reps from his own office, and that this list would precede the search function on the page.  The business analyst thought this was an excellent alternative, and she went to draw up the new plans.  Back in the development lab, things ran afoul because "everyone knows" that the search function "has" to be the first thing on the page.  This was going to "break the convention" of the look and feel of the rest of the web application, and this self-imposed directive should take priority over giving the user what they truly want.  Also, this alternative was going to require extra programming that we had not originally planned.  I stood my ground on the customer's behalf, and ultimately we all did agree on this alternative presentation of the UI.  But this incident illustrates that sometimes even software developers who are in good communication with the end user will fail to have the end-user's best interest as their top priority.

In our development shop, we developers would often lapse into the flawed mentality of "the customer's always right", and I have been just as guilty as others on this.  The customer would dictate the requirements and the developers' task was to merely implement whatever they came up with.  Occasionally, the customer would ask for something so goofy that we developers would have to put our foot down and everyone would go back to the drawing board.  Such are the risks of assigning the responsibility of software design to the customer, in this case the business analysts.  The business indeed knows best what the business needs, but is typically not the best choice in deciding how to get there.  The developer has the knowledge to create whatever a specification calls for, but his knowledge of the business need is often very shallow.  This leaves a disconnect between the customer and the developer.  This disconnect was partially alleviated by the agile process we used, during the breakout sessions.  These sessions are great at defining the business need at a high level that could be understood by both business analysts and developers.  These session are not so good at defining the user interface.  And user acceptance is all about the interface.

In Cooper's book, "The Inmates are Running the Asylum", he introduces the concept of the "interaction designer", a person who's job is to define the user interface and overall orchestration for a software project.  In software development circles, the "architect" is more like the lead programmer who has view of the entire system as a whole, including database structures, development frameworks, and the code base.  Cooper's interaction designer is more like an architect in the real world, and they are not so concerned about the mechanics of making it happen as they are with getting it absolutely right with the customer.  Programmers don't necessarily make good interaction designers, because of their intense focus on the "how" of creating software, they lose sight of the "what".  The interaction designer is not so concerned that the chosen framework doesn't directly support a certain feature, they are focused on the end product, and have the artistic license to devise the product so that it works intuitively and flawlessly for the end user.

In Platt's interview, he does not acknowledge many of his observations that have already been articulated at length by Cooper.  He does offer a few helpful tips for both end users and developers.  His tips for developers include:

1) Make sure the project includes a "virgin" - that is, someone who is knowledgeable in software development but comes to the table with a clean slate, unaware of the software currently under development.  This fresh perspective will cause new ideas to bloom outside of the box of groupthink that evolves within a development team.

2) Be willing to break with convention. Doing things the way they've always been done is no longer good enough.  If you can't find the right GUI widget from your class library, get a better class library or build it yourself.

3) Don't let edge cases complicate the mainstream.  Programmers tend to write software that is mathematically correct, when they should be focused on making the actions and decisions most often taken by the end-user the top priority. Platt says that it should be easy for the user to do things that are "good, smart and safe" and difficult for users to do things that are "bad, stupid and dangerous".  Platt also demonstrates that it's faster and easier to track a UPS delivery by searching the UPS tracking number in Google than it is in UPS' own web site.  In Cooper's "About Face", he makes the absurd analogy of putting the eject button right next to the radio switch in the pilot's cockpit.

4) Instrument the user experience.  Today's software allows you to be able to report on the user's experience, so you should monitor how the user uses the software and then use that information to improve the software for the user's actual needs instead of their stated needs.  If your software is a web application, the simplest thing you can do is monitor the web server logs, but you can even do more than that.

One of the problems I see with judging software usability is that it relies on subjective experience.  There is no one good metric to determine how much a piece of software sucks or doesn't suck.  Aesthetic appeal is the first thing that hits the eye, but the lasting impression is the ease of interaction.  For instance, my T-Mobile service lets me pay my bill over the phone, and I don't even have to push a single button; its voice commands are intuitive, succinct and accurate, and I have even paid the bill while driving.

I'll have more to say about these issues on future blogs.

Last Friday, I got a chance to meet with the new customer.  I got up early, dusted off my hard hat and put on my best business casual clothes and took a 4-hour road trip to "Dinoland" (Texas' Permian Basin, land of dinosaur fossils and black gold).  We had our kickoff meeting at the local BBQ place, and then drove over to the gas processing plant, where I was able to sink my nicest shoes into 2 inches of mud.  I should have worn jeans and work boots like I had originally planned.  Anyway, we had a rather long engineering planning meeting.  At the meeting, the engineers drew all sorts of cryptic diagrams and spoke a language with which I am unfamiliar, though it did use English to connect the jargon.  And I thought to myself, so this is how we programmers must look like to outsiders - cryptic indecipherable language, UML and ORD diagrams that have the appearance of being "right", and inside jokes that they don't get but seem to crack everyone else up.  It was educational to be on the "outside" for a change.