Brain Food To Go

Posted on May 23, 2011 by mindstorm

Want to know how you can increase your intellect (and indirectly, your salary) during your commute? I have one word: Podcasts.

Whatever profession you work in, there are experts out there dispensing free advice over the airwaves. Just by tuning in whenever you have a drive or a spare moment, you can stay on top of current trends, learn about new products or techniques, become acquainted with new terminology and concepts, and generally enrich yourself.

Talk the Talk

I went on an interview about a year ago armed with my portfolio of over two dozen websites and applications, along with my extensive work history.  To my chagrin, the interview was not set up for me to present my work. Instead, I was barraged with questions for hours from three developers sitting across from me like the judges on the American Idol outtakes. Several questions went something like this:

“Do you have any experience working with X?”

“Um…I’m not sure. I’ve never heard of X.”

(interviewers glance somewhat skeptical at one another)

“Let me explain. X is the process where you …”

“Oh, ok. I have done that before, I just haven’t heard it called that.”

Doesn’t exactly get them on the edge of their seat at that point. Even though there’s often several ways to do something, people are often taken aback if you haven’t done it their way before, or even if you have but you called it something different.

The point is that podcasts introduce you to new acronyms, terms and phrases which will eventually become part of your language. In software development especially, understanding these terms allows you to explain concepts and converse with your peers more eloquently. The end result is that you sound like you know what you’re doing. You sound like you’ve done it before and you sound more confident. This is useful for interviews, meetings and discussions where you have to sell your ideas.

Memory Hooks

Another great benefit I’ve found is that when I have to learn a new tool or skill, all these hidden memories of a podcast will come flooding back.  Even if I didn’t fully understand what they were talking about, I picked up on bits and pieces. New concepts become much easier to grasp as you’re filling in the blanks instead of starting from scratch. Then, if I re-listen to a podcast after I have experience with the topic of discussion, I get much more out of it the second time.  Most products and techniques are a solution to a problem. If I’ve experienced that problem and had to fix it myself, I may will think “Wow, that would have saved me a lot of time. I’ll try that next time.”

Additionally, I will often hear an idea and begin to brainstorm my own ideas (I may have to pause and backup a show but that’s okay). Listening to a podcast in the morning wakes up your brain and gets you into “work mode” more than, say, Howard Stern. Unless perhaps you’re a professional womens’ mud wrestling referee.

Some Unpaid Advertising

I use the Beyond Pod app on my droid, a $7 investment.  As a developer in the Microsoft space, my current favorite podcasts are .NET Rocks, Hanselminutes, and Herding Code.  I tried Codecast and Alt.Net but did not find them as beneficial.

I sometimes get bored of code casts, so I branched out into some popular casts Stuff To Blow Your Mind and Stuff You Should Know, from howstuffworks.com. Even off topic casts can give you some more interesting conversations, which can allow you to connect with those outside of your area of expertise, like friends and family, your manager, and the owner of your company. Code abstraction patterns don’t make for a great ice breaker.

And of course there are still times when the droning voices aren’t enough to keep me alert in traffic and I just need to rock out. Then I switch to Pandora.

 

 

Posted in career, work | Leave a comment

TMV (Too Much Validation)

Posted on May 14, 2011 by mindstorm

I normally begin each post with an anecdote explaining my motivation behind writing. In this case I was asked to add code to a user profile page to validate a zip code. The request was that I not only check the length but that I compare the zip code against a registry of all possible zip codes to see if that particular zip code exists. My response was simply “Why are we bothering?”  After all, I thought, what’s next? Submit their address to Google maps to make sure it exists?   Check their name against MVA or voting records to make sure they exist?

Validation is the act of verifying that data is constrained to certain rules.  The rule could simply be required input, a certain format such as date, or a complex system of logic that combines constraints on several input fields. When a user submits data, a certain amount of validation is helpful.  We’ve all been saved at least once by having to type in our passwords twice when they don’t match.

The question I pose is this: is there a such thing as too much validation? And if so, when does that occur?

To answer that question, we have to take a step back and look at what’s happening. Data submission of any kind is essentially a conversation between two parties: the submitter provides information and the receiver provides feedback.  This could be through a web form, a paper form, or an interview. An interview requires the most time and effort by the interviewing party but offers the highest degree of validation since they can converse freely.  Paper forms remove the interviewer and thus streamline the process, but provide no validation. Invalid data is submitted, caught while being processed, and the form must be fixed or returned for resubmission.  Valid data must still be processed and stored by an administrator of some sort.  This system has worked fine for centuries and still does, but now we have the web, which brings me full circle.

Web forms can provide instant feedback and force a user to fix errors through validation. This completely cuts out the interviewer and the administrator. It also saves time for the user during entry and shortens the processing time, which benefits everyone. The only cost to the enterprise is that they now need programmers, database administrators and the technical baggage to keep the system running. Still, this is generally a fraction of the cost for the provided return.

Validation is useful for streamlining a conversation for both parties. But once validation starts to hinder the conversation, it’s usefulness declines.

The most obvious occurrence is when validation throws false complaints. This can occur when the rules change but the code logic becomes out of date. Some examples might be the 9 digit zip code or new email formats (I once forgot to allow for European email formats).  These are the simple fixes. The gray area concerns the things I mentioned at the beginning.

The issue is relevant to me not only because I code lots of forms with massive amounts of validation checks, but also because I am currently co-authoring a jQuery plugin to precede user actions with a confirmation dialog to force the user to verify their intent before committing the action. Like validation, a confirmation prompt can protect users from making mistakes, but it could also become a nuisance if it is overused. Since this is a plugin, it will be up to the consumers to decide when and how often to implement it, but to make it as useful as possible, we want the default behavior to mimic the majority of use cases.

And determining  default behavior requires a bit of prediction at this phase. Hopefully, once we go live, we will get some useful feedback from the community and see how close our predictions are.

Posted in html, work | 2 Comments

Fun With Data Annotations

Posted on April 27, 2011 by mindstorm

I’ve been using Data Annotations recently.  For those of you outside the .NET world, Data Annotations are Attributes that bind validation and display rules to your model properties. Some examples of basic validation annotations would be

  • Required
  • StringLength
  • Range
  • DataType
  • RegularExpression

And the display attributes would be

  • DisplayName
  • DisplayFormat
  • UIHint

The awesome thing about MVC.NET is that simply by applying these attributes, you instantly get server-side validation. And with a few extra javascript includes, you get client-side validation with no custom javascript!

Each validation message has an optional error message that appears to the right of the invalid field along with an optional summary at the top of the page.

Rethinking nTier Applications

At first I winced at some of the display attributes because they are ultimately writing HTML from the data layer, which seems like a violation of tier separation since html is part of the display layer. But looking at the simplicity, reuse and consistency this system provides, it just makes sense.

Employing convention over configuration, the data layer can set many overridable features that would traditionally be considered business layer or display layer. Likewise, the business layer can override the data layer with more specific display names if the model is used by several business layer. The display layer could do the same. The nice thing is that 90% of the time, default values don’t need to be overridden.

Example:
You have  a User entity with a Name property.
Your data layer might provide a display name of “User Name”. This value appears in the label next to the input on the page.

Lets say you have business objects called Employee and Supervisor, which inherits from User.  Supervisor may wish to override this display name as “Supervisor Name” but Employee might just want to go with the default.  Additionally, you might have 50 pages which use various combinations of Employee and Supervisor that could override these display names as needed.

You might be asking, what’s the point? Why not always define label text in the html page where it belongs? I felt the same way, but html pages are generally not reusable, so you may end up repeating the word “Supervisor” 50 times, then your client could ask you to change it to “Manager” (this actually happened). You can do a global find-replace, or just have a few inconsistencies. But in the practical world, the data layer provides a central location for any information that gets repeated throughout your application, allowing more consistency in your Display layer.

Potential IDE Improvements

Because these features are finite and provide predefined options for most of what you need (like a regex for email), I could easily foresee the next iteration of Entity Framework providing a GUI interface to attach these attributes to entity properties in the ORM. In fact, much of this information, such as required, data type and string length, are included in the ORM, but they don’t percolate up to client-side validation. It may have been a design decision on their part or they may have just run out of time.   The point is, I don’t think basic validation is going to be something developers will have to spend much (if any) time coding in the near future.

 

Posted in asp.net, mvc | Leave a comment

Deafening Silence

Posted on April 15, 2011 by mindstorm

Series:  The Good, The Bad, The Ugly

One thing I’ve learned over the years is that silence is not always golden.  I’m specifically referring to long periods of silence between a client and contractor in the middle of a project.  A former boss once told me he treats client interaction like a tennis game. Just always hit the ball back into their court, he said. Respond promptly to their requests and don’t keep them waiting, even if you can’t provide the solution right away. This is very good advice, people don’t want to wonder if they’ve been forgotten about. And on larger projects where both sides have project managers pushing timelines, meetings and schedules, this system works perfectly fine.

But what about when the line goes dead? What if you, the client, don’t have time to focus on the project you’ve hired us for? Maybe you’re too busy tending to your own clients’ needs or other obligations, or maybe the project just isn’t a big priority. Whatever the case, it’s been my experience that long periods of silence can be extremely detrimental to a project, even if everything else seems fine. Or to use the tennis analogy, you might hit the ball back and not get a response because your client has found a new tennis partner.

Your words, not mine.

Another funny thing happens with memory of conversations over time. We apply our own filters and hear things differently. We sometimes turn implied assumptions into explicit promises, or we omit statements from memory.  A confirmation email is a good basic step to solidify a conversation, but they invariably still leave out details and you just feel icky having to dig through your old emails to set the record straight with a client once a misperception has had too long to incubate.

I once called a client to discuss a delicate matter that I didn’t think could be properly conveyed through an email. The call went well then there was an 8 or 9 month period where they didn’t contact us. We were midway through their site, waiting on content.   Then we got an email out of the blue that our client wanted to go with another firm. They had completely forgotten that we were waiting on them.  I called to repair the damage but it was too late. Time had skewed the memory of the original conversation.  ”I remember you said word for word, ‘bla bla bla’  ”, the client reamed. I had a completely different memory of the conversation and I could see that the client had completely altered the intent of my original call to fit what was in their mind.

Whose turn is it?

One problem with the “only respond to an email” approach is that people forget you’re waiting on them. This often happens for us right after we send a website design to a client for approval. No matter how clear we try to make it that nothing more will happen until the design is signed off, it sometimes fails to register. We may get a non committed answer or no answer at all for months at a time. This happened with a previous client. After waiting several months and making several attempts to get sign off, we received an email asking if the site was finished.

What?  The whole site? Finished? We had received no design approval, no content, not even a site map. We restated that we had been waiting on sign off for months. The client stated that they had approved the design long ago and were very upset with the lack of progress. This time we had our paper trail of emails corroborating our story, but at that point it didn’t much matter. You say the design was approved? Fine. Send along the content and we’ll build your site.

Going in a different direction.

The worst case result of time is that the rest of the world has moved on while you were waiting.  I’ve experienced some of the greatest hits: Company shut down, changing business plan, funding dried up, a competitor beat us to the punch, etc.  See my post on The Perfection Trap for a list of reasons that these cases can happen.  The point is that when it takes several people working  together to get something done, you have to push full steam ahead while the project is on their front burner.

Squeaky Wheel.

Every project is important to us, but there’s simply no avoiding the fact that a responsive, involved client will get more attention than one who’s wandered off into the wilderness. Of course there is the other extreme. I remember a particularly pushy client who called my Chief Technical Officer’s  (CTO’s) house at 4:00 am to report a bug he found on a prototype demo.  4:00 am.  Because it was that important.

Anyway, the point is that for a project to be successful, a client needs to be involved. Not as involved as the crazy guy in my last story, but you have to be involved.  You can’t pass off your idea and expect it to come to fruition on its own.  You have to cultivate the seed to grow into a crop. We are merely a tool to help facilitate the process.  A hoe will not grow a garden alone. You must use the hoe. Let us be your hoe.

Posted in clients, msi, The Ugly, work | 1 Comment

A Penny On The Sidewalk

Posted on April 5, 2011 by mindstorm

There’s a sociological test where a coin is placed on the sidewalk and a varied percentage of people will stop to pick up the coin. There are many factors, the greatest being the value of the coin. The average person won’t take the time to bend down and pick up a penny, but most people will pick up a quarter. Nickels and dimes fall somewhere in between.

I’m not sure what the exact purpose of the study is, but I think it makes a great metaphor for a tool or application that isn’t quite worth the trouble to use. Oftentimes it’s the very simplest differences that determine whether the cost of learning and using a tool is worth the value that the tool provides.

Example: Team Foundation Server takes a long time to load, loads into a small window inside visual studio, and requires lots of clicks to push things through (Assigned must be saved as Active, THEN as closed). The web version loads faster but I hate that I can’t simply check off a list of bugs and perform a bulk update. Creating a new bug requires me to fill out several fields, and it’s just not worth the trouble for most minor bugs, so I jot them down on a notepad in a meeting then type them into a word doc.

Fogbugz has a beautiful, intuitive interface, you could quickly add bugs and manage bugs with bulk actions.  I would write things down directly in fogbugz. Both work, but it’s a quarter on the sidewalk. Granted, I didn’t set it up, and the fact that TFS is built into Visual Studio gives it more credence, and it does have a lot of integrated features which give it more value.

Another example, I just recommended to my collegue and fellow blogger to change his homepage settings to show full articles instead of summaries. this was my case:  my wife reads lots of blogs. She uses an agregate service (google reader) and will only read blogs that show up in full because it’s faster to load and more convenient, especially on a smart phone. She won’t even bother subscribing to blogs with a summary setting. That tiny inconvenience of having to click into your site and back to the reader is that little difference between being a penny or a quarter on the sidewalk. That may be a rare and very subjective case.  I could go on about the best cases like credit card purchase streamlining solutions or the worst cases of sites that make you do back flips to perform the simplest task, but I think you get the idea.

So is your solution a penny or a quarter on the sidewalk? (If you won’t bother to pick up a quarter then you are a snob).  Some factors are personal preference, but they all amount to a few universal factors:

  1. Speed.
    The king of kings. Take too long to load your pretty pictures and I’m out. Animation? It’d better be quick and fluid. Flash Intro? Skip. It was cool the first time…maybe. I have to create an account before getting basic info? I’m looking at YOU, experts – exchange . com, (purposely not a link). Don’t ask why stackoverflow is crushing you. Myspace vs. Facebook? Enough said. Keep your glitter, give me my news feed.
  2. Usability.
    Yes, noble developer, you find your site easy to use and don’t know why everyone else has so much trouble. Well, they don’t live on the web 8 hours a day like you and haven’t been staring at this app for the last six months.  You have to watch people use your site, see how they don’t even notice your glossy icons and how they struggle to perform the simplest tasks, despite your tooltips, FAQ, user guide pdf and captivate animations. Hear how they curse at your creation, and wistfully compare your solution to their old, dependable paper system.
    Coupled with basic understanding is the general ease of use factor. Forcing users to click through extra pages to get details or update individual records when using AJAX to load extra data or including a bulk update feature would work; these are the subtle features that greatly affect user experience. In instances where users are making an online purchase, they can often make or break a sale.
  3. Reliability.
    A.K.A. Quality of Service. “The network is down!” Cries Chicken little. This app has gotten really slow, it’s really frustrating! Oh, that’s because of that sleek javascript thing you wrote. It worked so well in your development environment with two test records. Bet you didn’t account for people pasting 10 page word docs into the “Remarks” field and uploading giant uncompressed powerpoint files.
  4. Design.
    This is often the first lamb to the slaughter when budgets or schedules get crunched and that is a great tragedy. A high quality interface design not only provides clarity and improves usability, but on an almost subconscious level, you just feel better when you’re interacting with a sleek, modern design . It gives an impression that the underlying technology is built with the same attention to detail. It is also important that design decisions are implemented site-wide to make a uniform user experience.

There’s nothing revolutionary here; these are pretty much common sense. What I find amazing is how many developers I’ve met that simply don’t seem to care about user experience.  They simply go through their requirements checklist and feel like their work is done when they are capable of executing the required actions within their own application.  The apathy epidemic is most acute on internal applications, partly due to the fact that the audience is a captive audience. It’s their job to use the in-house app and there’s no alternative. Developers can’t take all the blame though. Business decisions often place user experience as a lower priority and don’t allocate the time or personnel required to truly make a project shine.  In many cases, developers aren’t even allowed to add or improve features that weren’t specifically requested or paid for by the client. But in those cases, it’s the client’s fault, and there is no more literal example of the phrase “You get what you pay for”.

Posted in clients, work | 5 Comments