Entries from February 2007 ↓

The Next Frontier in Offshoring

I have a friend who works for BearingPoint (formerly KPMG Consulting), and she wrote to tell me about her firm’s newest Global Development Center (which are basically off-shore, low cost software development offices). They currently have centers in India and China, and their next destination is…Mississippi. That’s right, a Global Development Center in Hattiesburg, Mississippi.

It turns out Mississippi has a low cost of living (thus low wages) and satisfies the need for clients like the federal government that require work be done in the U.S.

From a financial perspective (though some might call it greed) this seems like a logical trend for some businesses to follow, and similar to one call centers travelled in the 1980s before the internet made “around the world” into “down the block.” But as a fellow developer I’m curious to hear your thoughts on the following questions:

  1. Is it a good thing that development work is moving to low-cost areas, but staying within the U.S.?
  2. Is this a savvy business move made to keep a company competitive, or a devious, greedy move made to take advantage of developers and pocket fistfuls of cash?
  3. Would you be interested in moving to a low cost area of the U.S. (read: the middle of nowhere) and working for less money, but having a better quality of life with no traffic and cheap housing?

Software by Rob Job Board Launches

I’m receiving fairly regular requests to post job listings on SbR so I’ve decided to follow in the footsteps of a few other blogs and launch a small job board (if you’re reading this on the web, you may have already noticed it staring at you from the upper-right corner of each page). I’m using a third party called JobThread to handle the heavy lifting, which makes it easy to see if a Software by Rob job board will fly. In 10 minutes I was up and running.

To celebrate the launch I’m having a special for the first month: $30 buys you a 30-day listing, which places your job in front of 25,000-35,000 software developers.

A Survey to Determine if Your Developers Are Happy

After publishing Nine Things Developers Want More Than Money late last year, I received several requests for something that could provide more specific information than the 1-9 score on Rob’s Criteria for Keeping Your Developers Happy. In other words, managers want to know which of the nine areas to focus on, and most who wrote suggested I create a survey they could give anonymously to their developers.

In response, I’ve created a 29-question survey that covers all nine of Rob’s Criteria. I built it in HTML so you can print it out and distribute paper copies, or write code to place the responses in a database for easier analysis. If you wind up using a database I’d appreciate if you would send me a copy of your code so I can post it here.

The survey does not have a norm since it has not been administered to anyone. As a result, determining the results will be up to your interpretation. Hopefully that’s not too difficult given the nature of the questions.

If you have other questions you’d like included, or stories to share about survey results, please post them in the comments.

User Interface Design: Complexity vs. Flexibility

While building a report a few weeks ago I realized something I’d never thought of before: in user interface design, the more flexibility something offers, the more complex it tends to become.

This is an obvious conclusion, but I had never thought of it in these terms before.

A Simple Report
A few weeks ago I built a report. The first iteration used a hard-coded SQL query called by a page with no visible input parameters. The UI was delightfully simple: a single button marked “Run Me.”

The next step in designing something usable was to add two input fields for the start and end dates. At that stage I had a report that was fairly simple, but not very flexible.

Next, I added three parameters that allow a user to narrow the report by Customer, State, and City. With that the report became slightly more flexible, but also more complex. Luckily, this is where the complexity ended (read: the need for flexibility ended). It’s a good thing, too, because the interface was beginning to look busy.

If I had continued along this path to absurdity, I could arrive at a single text area for inputting SQL queries. This approach would be extremely flexible, but far too complex for business users.

Shopping Carts
Another example of this inverse relationship between simplicity and flexibility can be illustrated with online shopping carts.

Someone asks me every month or two about online shopping carts, typically: “If I want to sell a product online, which shopping cart do you recommend?” My first question is always: how technical is the person who’s going to manage it? (read: how much complexity can they tolerate?)

The simplest option is something like Yahoo! Stores or Shopify. Simple, yet configurable to the extent Yahoo! or Shopify allow in their control panel.

A more flexible approach is purchasing an off the shelf shopping cart that can be customized by a programmer. Products like .netCART contain loads of functionality, but they’re geared towards technical people rather than business owners, since they are too complex for the average person to configure. They offer loads of flexibility with lots of complexity.

And finally, the most flexible shopping cart one coded from scratch. Super flexible, very complex.

Cake and Eat it, too
With an entire design movement built around simplicity, it seems warranted to ask: can a design be simple and flexible at the same time?

In thinking about this, Gmail comes to mind since it’s simple enough for my mom to use, but flexible enough to serve the needs of more advanced users (and once they get POP3 retrieval out of beta it will be that much more powerful). Google achieves this by making common tasks obvious, and uncommon tasks hidden. Want to send an email? It’s right in front of you. Set up POP access? It’s in the settings menu. The more advanced items are hidden from beginning users, but the key is that they can accomplish 99% of their tasks without every looking in Settings. In fact, that’s one way Gmail succeeds where Outlook fails.

I also find the WordPress blogging engine flexible and powerful, yet surprisingly simple. As with Gmail, the WordPress team has managed to create a product with a ton of features that somehow leads beginning users to where they need to go quickly and effectively. I’ve introduced several newbie bloggers to WordPress, and never once have I had to answer basic questions you’d expect (“How do I create a new post?”, “How do I change the skin?”). Yet WordPress is insanely configurable through the administration console, its configuration files, skins, and add-in modules.

These applications do a good job of making common tasks trivial, while shielding the user from advanced tasks until they have the need or motivation to seek them out. These applications are not simple, nor are they feature-limited, but they do an amazing job of catering to beginning and advanced users at the same time.

The Holy Grail of UI Design
In doing so these applications provide flexibility and simplicity simultaneously; a feat that’s difficult and often expensive to accomplish because it fights the natural tendency towards complexity. Ultimately, I believe this combination is the holy grail of UI design.