It's the first week of January, so I am required by Internet law to post a "year in review" for 2014... so here we go.

"Looking Back" photo attribution: Some rights reserved by Alberto OG

This year has been an interesting and good one - and jam-packed. Here's a rundown of some of the major hightlights for me.

Joined The That Conference staff

In 2013, I attended That Conference, a technical conference in the Wisconsin Dells. And I really enjoyed the experience. So much so, that I contacted the organizers and offered to help out for 2014. On Jan 10th, I became a member of the team.

One of the main goals for That Conference 2014 was to rewrite the website, and I ended up taking lead on that project. A lot of commuting hours on the laptop, late nights, team video calls and "what the hell did I get myself into" moments later, I had come up to speed on ASP.NET MVC, Bootstrap, OAuth, Git and GitHub, AngularJS, Twilio and a whole host of other technologies I had little or no experience with.

I also learned a great deal about the business and logistical side of putting together a conference for 1000+ attendees and their families. And doing so with a team of 100% volunteers. During the week on-site, it was exhilarating and exhausting work. And while InRule brought our entire dev team to attend and were Platinum sponsors for the event, I barely saw them as I was running around helping keep this crazy train from coming off the tracks.

I met a ton of great people and am already getting rolling for 2015.

Shameless Plug: Looking for a great technical conference in the Midwest? Come join 1000+ motivated professionals for three days (Aug 10-12, 2015) for 125+ exciting sessions on web, mobile, cloud and everything else, across a variety of languages and platforms. Plus, it's held at a water park (the Kalahari Resort in the Wisconsin Dells), so bring your family -- there's family track with sessions for them too! That Conference

New Job Title: Director of Development

My role at InRule Technology changed a bit this year, as I became the Director of Development. I documented this in my aptly-name post I Have A New Job Title: Director of Development, so won't go much further here.

Along those lines, however, one thing to note is that InRule saw a lot of growth this year. In particular, we ended the year with 11 new employees that weren't here at the start of the year. And while we did lose a couple people as well, that's a pretty big number for a company of around 40 people! We were also named to Inc. 500|5000 List of Fastest Growing Companies at #3636, and made the list of Chicago's 101 Best and Brightest Companies to Work For!

First International Vacation

Along with my wife and son, I took my first international vacation this summer -- as well as our first "destination vacation" as a family. We headed south to the Atlantis Resort in the Bahamas and it was great!

Son Back In Public School

My son, who has some substantial learning disadvantages, had not been well served by the public school system for the first few years, so we made the decision to home school him a few years back. This year, however, we found a program within the public school that matches up with his needs (and has staff that supports him) and he has once again started attending public school. He has been making great progress this year! Through 2014, this was for just a partial day, but we're working now to extend that to a full day in in the early part of 2015.

Getting Into Microcontrollers

This year I got a Raspberry Pi (and later an Arduino). I'm loving playing with electronics again! I've been putting together a "GaragePi" project, which I've written about a couple of times now:

• GaragePi – My Raspberry Pi Playground
• GaragePi v2: Temperature and Light

The Rise and Fall of My SonarQube Plugins

This one's a bit painful still, but in 2014 I published my SonarQube plugin to support ReSharper. About a month later, the cord was pulled and it died a quick death along with my plugin to support NUnit reports.

This was a fairly hurtful experience for me, as I poured a LOT of time and effort into putting these together and has turned me off from contributing to open source projects for a while. It did, however, allow me to turn my focus on That Conference.

All the other stuff

And, of course, there's been so much more. From my DIY projects at home, surviving the Polar Vortex, finally breaking 1000 on StackOverflow, to becoming the housemate of a cat. In 2014, I posted 16 entries to this blog and had approx 92,300+ pageviews -- and may actually make enough money on cumulative ad views for Google to actually cut me a check this year!

All-in-all, it's been a pretty good year! And 2015 is looking to continue the trend.

A little while back, I wrote about my first year using a Nest thermostat and since then several people have asked me for details on how I wired up my whole-house humidifier. I hesitated for a long time to post much detail, since it'd be really easy to completely fubar your HVAC, humidifier and Nest all in one fell swoop. But, after much mental consternation, I've decided to provide some detail, but with this really big disclaimer:

BIG OL' DISCLAIMER:

I am not an electrician, an HVAC specialist, a trained Nest consultant or frankly anyone you should trust. I provide this information solely as a reference implementation and provide no warranty that it's accurate or even safe. You should consult an electrician or specialist before doing anything you read here. Incorrect wiring can cause massive damage to your HVAC system, or even result in fire.

In determining how to wire things up, I relied on advise from the good folks at The Thermostat Forums, and you can also look to the DIY StackExchange site.

UPDATE:

The folks at Nest have made their official Pro installer guide available: http://support-assets.nest.com/images/pro-faq/Nest-Pro-Installer-Guide.pdf

What's a Humistat?

From my original post, you may recall:

A “Humidistat” is the thermostat equivalent for a whole-home humidifier. It generally has an external sensor that reads the current humidity levels of the outside air, as well as a built-in sensor for the inside air. When the humidity inside is too low, such as in the winter when the heater is drying out the air, it will evaporate water into the hot air leaving the furnace and into the house.

My Wiring

Again, from my original post:

Now, connecting the Nest to the humidifier was not a straight-forward process. Humidistats come in two types, which basically comes down to 1-wire or 2-wire controls. If yours only uses 1 wire, good news, you can easily and quickly hook it up to the Nest. But most utilize 2 wires, much like a light switch, where a low voltage signal travels up one wire, the humidistat acts as a switch, closing the circuit for the voltage to travel down the second wire back to the humidifier to signal it should turn on. So in order to use the Nest, which only has 1 wire to control the humidifier, you must install a relay circuit, which, if done wrong, can damage your HVAC main board, your Nest and your humidifier — so Nest asks that you have a professional do the work. However, I am comfortable doing that kind of wiring and was able to install the relay and get the Nest hooked up on my own.

So, here's what the original wiring looked like:

You'll notice on the HVAC control board, there are five terminals, labeled R, C, W, Y and G. My understand, which is confirmed by this eHow Guide and this Thermostat Wiring Explained article, the terminals are:

• R: Power (usually has a red wire)
• C: Common
• W: Heating (usually a white wire)
• Y: Cooling (usually a yellow wire)
• G: Fan

I used a 6AZU2 relay, which seems to be a commonly used relay for people doing exactly this (see the comments on the Amazon page). I used crimp-on spade connectors on the end of the wires to connect them to the relay terminals.

Here is what the new wiring looks like:

So when the Nest sends the signal on the "*" wire, the relay closes the circuit between the two lines on the humidifier, engaging it.

You can see someone else describe the same scenario, with a wiring diagram, on this site

.

Very often, particularly while helping someone non-technical with a technical problem, I think to myself "this would have been so much simpler/less confusing if the designer would have put just a bit more thought into the user experience." Similarly, I occasionally come across something where I say "man, why don't more people do this."

Yesterday, I had each of those reactions -- to the same piece of technology! So I had to share. What was this magical piece of technology that mixed both the good and bad design experiences? Why, a gas pump, of course.

Take a look at this portion of the pump user interface. On the top, you have a credit card reader, and on the bottom, a keypad.

The Good:

The credit card magnetic stripe reader. They are everywhere: gas pumps, ATMs, grocery stores -- pretty much every brick-and-mortar retail outlet you can find has some form of this device. And it seems like every time I use one, I swipe my card, only to realize I had the mag stripe on the wrong side and have to flip it and swipe again.

So what's so good about this one? Well, take a look at the little helper pictures on the device. Did you see it? You can swipe the card with the mag stripe on... wait for it... either side. There is basically no way the user can do it wrong. The manufacturer has created a pit of success for me to fall into by adding a second receiving device on the other side. I LOVE IT!

This was the first thing I noticed on the gas pump, and I rejoiced. It put me in a better mood.

The Bad:

Immediately after swiping my card, the pump asked me to enter my zip code for credit card verification, followed by the dreaded "Do you want a car wash too?" prompt. Entering the zip code for credit card verification was straight forward -- I had a set of what is clearly a numbered keypad to use. So I tapped it in. No problem.

Now I get the "Do you want a car wash?" prompt. In my head, as I recall this little episode playing out, I hear this 80s era computer voice asking "Shall we play a game?"

Ok, I can do this -- "just press 'No'" I tell myself. So I reach down to the keypad and... um.. where's the 'No' key?

Now, it's hard to tell from the picture, but the 0-9 keys, plus the yellow "Clear" and green "Enter" are all raised, like an early 90s telephone. So this is a very familiar interface to me. The yellow and green colored buttons stand out to me -- clearly the designer gave them color to draw my eye to them. Then there are these stickers on the left and right side, which are also of various colors.

Here's how it played out in my head:

Ok, so, now, how to say "no"? Let's see, what are my options? There's no clear "No" key, but there is a "No" sticker next to the "Clear" key and they are both yellow -- so maybe that's it. But wait, there's a red "Cancel" label next to the green "Enter" key, and red usually means No -- but green means confirm and the key itself is green. Better go with the yellow "Clear" key.

I hit the key -- the machine beeps. The screen refreshed: "Do you want a car wash?". Ok, maybe it didn't register... so I pushed it again. And back comes the car wash prompt. (or, in my head "How about Global Thermonuclear War?"....) Clearly, this is not the right button.

To make a short story less long, here's where I landed: Turns out, those "stickers" on the side aren't just labels -- they're actual buttons. I probably should have taken the picture from a slight angle to make it more clear how much the buttons stick out -- but to me, it was not at all obvious that these were interactive components, especially since they are juxtaposed immediately with what are clearly interactive components. So I eventually hit the yellow "No" sticker and went on my way.

There is so much going on with this little 3" x 3" square of user interface.

• keys that are buttons
• stickers that are buttons
• stickers in yellow, red, green and white (what do those colors mean???)
• keys in black, yellow and green

As a user, I don't know what this all means, which means I'm likely to get it wrong, at least once. Had the buttons all been the same physical design, I would have immediately known which button to push.

It makes me wonder if the two parts of this user interface were designed by the same people.

Two years ago I joined InRule Technology, in part, because I saw tremendous potential in the company and it's software. During those years, we've seen great sales growth (with a 67% increase year-over-year revenue in 2013), and all signs indicate that sales growth will continue for a very long time. Accordingly, the company is poised to grow in size and maturity as well, and in my new role as Director of Development, I will be helping guide the ship through.

I'm a huge believer in continuous improvement and frequent incremental change, not just for improving our software codebase and feature set, but also for our people, processes, practices - both at the micro (individual contributor) and macro (department and company) levels. In the Director of Development role, I'll help drive strategic initiatives within the Product Development (aka software development) group aimed at improving our processes, software architectures, system infrastructures and our people to make it easier to expand our products, grow the department and to venture into new technologies and new markets. I'll play a key role in growing the team itself, as well as representing the development group in cross-departmental concerns.

Many of these are things I've already been doing in the background, because I'm passionate about my work and enjoy the work I do. This title change just makes that part of my official role. Of course, Jeff Key, Sr VP of Engineering, will continue to oversee the department overall, and I will continue to report to him. While I will be absorbing some of the work that is currently in his plate, we both felt it was important that I continue to spend a large portion of my time writing code.

As such, I will still be doing development/architecture the majority of the time. This is my "happy place" and I wouldn't want it any other way. Too often, companies will take high performing members of the team and "promote" them into a leadership role which takes them away from development and the things they enjoy about their jobs. This ends up hurting the individual and the company in the long run, something I've experienced in my own career, and is something Jeff and I both wanted to avoid. That I work with a management team that understands this dynamic is yet another of the great things about working for InRule!

Hmm... Guess it's time I dusted off my Thoughts on Employment series.

Alright, enough self-aggrandizing. Check back with me in a year when I've got something to show along with my big words!

Photo Credit: Michael Heiss (Creative Commons License) Some rights reserved

A year ago, I purchased and installed the Nest Learning Thermostat (version 2) in my home, replacing my existing programmable model. This was a bit of an investment at $250 (although I got a $30 rebate from my gas company), but I made some assumptions about the energy savings and figured it would pay for itself after about 4 years... and there was a world of potential for what it can do.

Now that it's been a full year since I installed the Nest I thought I'd reflect back on the experience. While I am still very happy with it, the actual energy savings, if any, are difficult to quantify. Just looking at the raw utility numbers, it doesn't appear to have made much difference, but there are soooo many other factors at play, that I can't say for sure.

However, there are a LOT of things to like about the Nest and I am still very happy with it.

In this post, I'll share some details about my energy usage compared to pre-Nest usage, and some of the reasons why I think the device was still a good purchase.

Energy Usage

Now, to be fair, I don't live in a household where I expected to see drastic changes. For starters, my wife and son are home during the day, so there's no set period where the house is always empty and the HVAC can be turned off completely. Instead, it's ad-hoc periods that happen infrequently. Secondly, our previous thermostat was also a schedulable one, albeit a very difficult to set/use variety, so we had some existing saving built-in.

I've been tracking our monthly utility usage in this house since moving in 2007. I installed the Nest at the end of Nov 2012. In the below graphs, I've plotted the average daily consumption (total monthly units/number of days in billing period) for the Electric (KWh) and Gas (Therms). I've also added the temperature readings (from weatherunderground.com)

A note: the Gas readings are only taken every other month, with estimates (or readings submitted by me) in the off months. The electric readings were also every other month during the winter until this last year when a smart grid was installed in our city. It now takes readings every 15 mins, but the granular usage data is not yet available for customers.

Favorite Features

Below are some of the Nest's features which I found useful (and one I want but isn't yet available to me). The culmination of these are why I feel the Nest would still be worth the cost even if I never recovered the money via energy savings.

Fan Timer

The Nest allows you to run the fan on your central air system in order to circulate air throughout the house. The layout of my house, a split-level, is such that cold air settles to the lower floor and hot air to the upper. This results in a very cold TV room in the winter and a very hot bedroom in the summer.

In the past, we've put box fans at the bottom of the stairs in order to recirculate the air, but they were very loud and in the way. By using the Nest's fan timer feature, I can have the HVAC system circulate the air through the duct works, which results in a much quieter and efficient system. During the extreme temperature months, I set it to run 15 minutes out of the hour, and that results in a much more comfortable environment. This also has the side effect of running the air through the A/C filter much more frequently, which is a big bonus in our house where my son and I suffer from pollen allergies.

Here's a cheesy diagram... I mean, an artist's interpretation of what I just described.

Auto Away

Auto-away is the feature of Nest where it detects that you have left the house and stops heating and cooling until you return. You set min/max temps so that it never gets too hot/cold while you're away (especially helpful if you have pets), but you're not paying to cool and empty house. It uses a motion sensor in the Nest to track when you've walked by, and during the learning phase (the first several weeks after install), it determines how often it usually sees you during the times you're home, and if it doesn't see you for a period longer (like, an hour longer) than it normally would have, it will go into auto-away mode.

As soon as you come home and walk past the Nest, it will kick back on and return the temps back to their normal range. Want it to already be that temp when you get home? Just use the smartphone app or webpage to tell the Nest to leave Away mode and start cooling/heating right now.

Integrated Humidifier Humidistat

A "Humidistat" is the thermostat equivalent for a whole-home humidifier. It generally has an external sensor that reads the current humidity levels of the outside air, as well as a built-in sensor for the inside air. When the humidity inside is too low, such as in the winter when the heater is drying out the air, it will evaporate water into the hot air leaving the furnace and into the house.

In our case, the old humidistat had two major issues: 1. The external sensor was installed right next to the exhaust vent of our clothes dryer, so when the dryer was running and spewing hot, moist air out the vent, it would blow directly at the humidifier sensor. 2. The humidistat control just had a knob with 0 - 4 to set the humidity level. It was just a best-guess as to what the actual humidity levels would be.

Now, connecting the Nest to the humidifier was not a straight-forward process. Humidistats come in two types, which basically comes down to 1-wire or 2-wire controls. If yours only uses 1 wire, good news, you can easily and quickly hook it up to the Nest. But most utilize 2 wires, much like a light switch, where a low voltage signal travels up one wire, the humidistat acts as a switch, closing the circuit for the voltage to travel down the second wire back to the humidifier to signal it should turn on. So in order to use the Nest, which only has 1 wire to control the humidifier, you must install a relay circuit, which, if done wrong, can damage your HVAC main board, your Nest and your humidifier -- so Nest asks that you have a professional do the work. However, I am comfortable doing that kind of wiring and was able to install the relay and get the Nest hooked up on my own.

The Nest uses local weather data from the Internet to determine the outside humidity levels and temperature, so no need for an external sensor either. And the iPhone app (as well as the built-in display) show me the inside humidity levels and allow me to bump it up or down easily.

Ease of use / Ease of install

I won't get into this much, because half the Internet is talking about these. But just to say the installation of the Nest is a breeze! They make it very easy. In fact, the hardest part for me was removing the old thermostat, which had been effectively glued to the wall with coats of paint.

The user interface on the device itself is very intuitive and easy to use. Programming is as simple as just setting the temp by rotating clockwise or counter-clockwise.

And the smartphone app lets do some of the more advanced stuff with easy as well, such as seeing your usage history and modifying the programmed schedule. This is doable on the Nest itself, but the UI on the phone makes it simpler. Oh, and you can use the phone app to do everything when your away from the house.

Ability to have heat and cool mode at the same time

I live in the Chicago area, and there are certain times of the year when the temperature shifts rapidly back and forth between hot and cold. One day, it might be 85°F outside, then the next night, 32°F. Most thermostats let you run in "heat" or "cool" mode (furnace or AC), but the Nest actually lets you have both enabled at the same time. In this mode, you set an upper and lower temp, and the Nest will keep your house between those temps. So an upper limit of 75 and a lower of 64 and we're all set for the rapid swings without needing to reset anything.

Warning: Running your A/C condenser when it's cold outside can damage it, so once the outside temps reach the point where the Nest is no longer cooling, I'll switch to just "heat" mode to ensure I don't accidentally kick on the A/C.

Airwave (use the already cool coils)

The Nest, when in cooling mode, can learn how long your cooling coils stay cold after the A/C compressor is turned off. Using this knowledge, it will continue to run the fan over the coils after turning off the energy-hungry compressor, allowing it to turn off the A/C compressor a few minutes earlier and still reach the desired air temperature. This is the Airwave feature and is just another way it saves energy.

Usage History

The Nest app, and the website, provide usage history details for the last 10 days. Initially, it shows total time that the A/C or furnace ran for each day along with a little icon showing why the energy usage for that day was higher then the weekly average (more on that in a sec.). If you click on a day, you see the specific minutes each ran, as well as when the temperature settings changed (manually or via schedule) and when the system went into away mode.

There are (at least) four little icons of note as well:

The Nest went into "Away" mode.

The weather caused more/less usage then normal.

You adjusted the temperature, causing more/less usage than normal.

The Nest was turned off.

There are others for some of the special modes the Nest can use -- such as "Rush Hour" (if your utility company participates in the Rush Hour Rewards program, which mine does not), or if the Sunblock feature is utilized (which detects if your Nest is in direct sunlight and adjusts it's temp calculations to compensate).

API/SDK for software developers

Since the Nest collects and generates a LOT of data I am very interested in (as you can tell from the fact I have my utility usage details from the last 7 years), as a software developer I was really hoping that they would allow me to have programmatic access to that data, as well as my energy history. Unfortunately, that is not the case ... at least, not yet. They announced earlier this year that they are going to have an API and were allowing early partners access, but it's not open to the general public, and it's not clear that it ever will be (might require you to be a "partner" company).

Conclusion

I am a fan, and I think for many (most?) households, the Nest will end up saving money -- possibly lots of money. How much money depends on how often you're not at home and what temperatures you set for your home. I'm looking forward to seeing what else comes from Nest -- the Nest Protect looks interesting, especially since it links with the Nest Thermostat, but I'm not ready to pull the trigger on it yet ... just don't see the ROI on that one.

Image of Nest Thermostat comes from the Nest Press page. Temperature graph comes from The Weather Underground All other images are my own or came from the Nest product UI

I had a really tricky problem I had to solve in an application I'm developing and, after a LOT of trial-and-error and redesigns, I finally came up with a solution that worked and was somewhat safe from future developer unintentionally breaking it while maintaining related code. However, it was pretty unintuitive and I was very concerned that other people reading the code (or me reading it in six months) would not be able to easily wrap their heads around what the code was doing, thus there was a high risk of it getting incorrectly modified in the future.

So, I sat down with another senior developer on the project to go over the code and look for ways to improve the readability without sacrificing the ability for the compiler to find issues at compile time. After reviewing the logic with him, he made this statement:

"I don't think I would have ever come up with that solution."

Hmm.. To which I replied "Is that a good thing or a bad thing?". His answer (which I anticipated): "Both, I guess".

Now this is a smart guy, and I value his opinion a lot, so this response is a bit concerning and in part for the reasons I feared.

Why is this a good thing?

Well, I found a solution to a problem that needed to be solved. Straightforward enough. And it was a tough problem. So the "I wouldn't have come up with that solution" in this context meant (in his words, paraphrased): I would have just given up and not solved the problem.

Then, why is this a bad thing?

The solution was pretty complex, and used some parts of the .Net framework many developers are unfamiliar with (invoking methods via reflection, loading multiple instances of an assembly, cross-AppDomain communication), so you have to have a decent grasp of the underpinnings of .Net just to read it. And, the API for those areas of the framework are not pretty to look at -- with lots of object[] params, casting and the like. This means that not just anybody can jump into this code and "just get it", which puts it at a high risk of latent bugs being introduced, increases the cost of maintaining the code, etc. To me, this is very bad.

Given the amount of effort required to come up with this solution in the first place, I had already weighed the cost of the solution against the value and determined that the functionality really was needed in the long run and thus it's value out weighed the risk this code posed.

But after discussing with my coworker, I decided to take it a bit further and "dumb down" the code as much as possible. So I did the following:

• made sure variable names were extremely useful in describing what they represented. This is particularly true for MethodInfo instances and delegates where the type is something like Action<Action<string, string[]>>
• moved particularly confusing code into small, well-named methods (some with just a single line) to make the code's intentions easier to understand.
• removed some "syntactical sugar" and replaced it with more verbose (ie: more descriptive) alternatives -- such as replacing some LINQ with foreach loops, etc. In many cases, I find LINQ to make the code more readable, but when combined with other confusing aspects of the framework, it can easily muddy the waters.
• added meaningful comments to the code. I try not to rely on comments, since I've found that developers rarely read them, they quickly become stale as developer modify the code without modifying the comments, or use tools like ReSharper to automate the modifications. But this is a case where inline comments are helpful.

Ultimately, I am much more concerned about the long-term maintainability of this project's codebase than the "hey, look at this cool trick I did" aspect of the solution. This particular project is in a codebase that is rarely changed, but when it is, it's usually urgent. There's a need to keep things clean and compartmentalized enough that any developer, especially one who hasn't worked in this particular codebase before, to just jump in and fix things.

Maybe I over thought this, but I'm hoping the next guy who has to look at this code doesn't have to think about it much. If that's the case, I'll feel like I did my job today. And if I'm that future guy reading the code, I'll have saved myself some "what was I thinking?" grief :-)

Photo credits: David Goehring Creative Commons License - Some Rights Reserved

As software developers, we often focus on only a sub-set of the functionality of the systems which we develop and maintain. It is common practice for a small set of developers to "own" a section of a much larger system, allowing them to get a deep understanding of that component, which in turn allows them to efficiently dive into that portion of the code with little ramp-up time, making the larger team more efficient as a whole.

However, this developer specialization comes with some costs.

As humans, we often look for the shortest path to achieving our goals, so when a developer who knows a certain set of product features really well has a task to perform in that system, they are more likely to use the feature sets they know deeply to perform those tasks.  This presents problem 1:

Software developers tend to know the portion of the system they work with very well, but have an atrophied understanding of the rest of the system.

Further, developers tend to have a specific set of use cases in mind when they create software and often get tunnel vision when they are using the system, not deviating from their preconceived expectations for how users will utilize those features.  Thus, problem 2:

Software developers will box themselves into a specific user experience and not venture from that path.

However, with very rare exceptions, software developers do not write software for themselves.  And the real users of the system have their own ideas and notions as to how the system should be used, often differing from the developers' viewpoint.  This usability expectation mismatch leads the user to uncover bugs/unimplemented features and have a degraded user experience, since the developers did not have the users' usage patterns in mind.

So, how do we address these issues in order to improve the quality and user experiences of our software?

Let me share three experiences I've had along these lines during my career.

A Day in the Life of a User

This week at InRule, we made an investment in our product's quality by having the entire development team take part in a "Day in the Life" exercise where we were all given a real-world customer scenario, straight from one of our pre-sales engagements, and tasked with implementing a solution using our software.

Each developer went off on their own to implement their solution.  Our product owner acted as our customer, answering any questions we might have about the requirements. We were allowed to ask others for help if we got stuck (although it was suggested we utilize the public help docs, etc, first, since our clients don't have direct access to our dev team).  Six hours later, we all reconvened to discuss our findings and go over possible solutions.

So what was the result?  Multiple bugs were found, several reoccurring usability issues uncovered, and every developer came away greatly increasing their understanding of our product's features and weaknesses.  As a team, we now have a greater understanding of where we need to focus on improving usability, and where, as individuals, we have shortfalls in our understandings of the product as a whole.  While this was a fairly expensive endeavor (we programmers aren't cheap), the leadership saw this as a worthy investment, as the product will improve, and in turn so will our customers' satisfaction level, as a direct result of this exercise.

Customer Service Shadow

Another approach that we tried a couple of times while I was at Wayport, which was much more of a service company, was to have the developers spend a day shadowing one of our call center reps, listening in on calls to hear customer's pain points firsthand, as well as how the support staff was able to diagnose and troubleshoot the systems.  In this case, it exposed shortcomings for both our internal and external users' experiences, as well as helped the development staff understand where we need to better inform the support staff of existing functionality that would help improve their day-to-day job.  So again, a win-win for everyone involved, helping to reduce the friction in our user's interaction with the software, and helping to keep the otherwise isolated developers informed of how users really use the system so that we can build better experiences going forward.

Everyone Cooks

My last anecdote is not software specific, but goes to the core of the point I'm trying to make.  I spent two years working as a consultant within McDonald's corporate headquarters, and while there I learned of a part of their corporate on-boarding process that I thought was worth sharing.  Given that everyone at McD corporate is there to support the individual stores' operations, every employee, from IT project managers, to accountants and lawyers, all had to spend two weeks working behind the counter at a McD restaurant -- cooking, taking inventory, cleaning, serving customers and living the daily ins and outs of the people they would be supporting for the rest of their time at the company.  I was amazed at how much these experiences seemed to resonate with the McD folks, even years after they completed their stint in the stores.

If you have other ideas, feel free to leave them as comments.

Photo Credit: Michael Dales (Creative Commons License)

I've been wanting to move this blog to my own domain name for a while, in order to better define my "personal brand" (see Scott Hanselman & friends' advice in the subject).

Separately, Google recently announced it would be sun-setting Google Reader, a product I had come to use quite a bit and will leave a large hole to fill. This just reinforced my realization that my primary "voice" on the web (this blog) is strongly tied to a single vendor who's not directly making any money off the product - so could kill it off any day, rendering me voiceless.

So over the next few months, I'll be making some changes. First, as you may have noticed if you're reading this in a web browser, I've migrated my blog within Blogger to a custom domain. So...

http://wrightthisblog.blogspot.com/ is now ==> http://blog.wrightfully.com/

Currently, if you go to the old URL for any of my posts, you will get a redirect to the new hostname. Similarly, the RSS feed has been pointed to the new hostname.

I'm also spinning up a WordPress instance that will be the new home of my online presence, including this blog, and I'll eventually move off Blogger altogether. If I do this right, none of you will notice and your existing links should continue working as-is. As part of that process, I'm also going to convert some of my posts into more of a page/wiki format since I continue to update them over time. This will take some work to keep the old permalinks working, so don't expect this anytime soon.

And for those interested in why I went the way I did:

• I used DNSimple.com to register my domain and host my DNS records. In part because I want nothing to do with GoDaddy as I disagree with them on many political and social topics. I choose DNSimple specifically because they have a clean but full feature management UI and got a hat-tip from Scott Hanselman. Note: if you use the above link and sign-up, we'll both get a free month of DNS service.
• I'm using a "self-hosted" WordPress instance for my new site. There were several things that lead me down this route. First, WordPress has a massive ecosystem, being one of (if not the) largest blogging platform on the net. There're plugins/themes/etc available for just about anything you want to do, and most for free, so no need to reinvent the wheel. Additionally, it's standalone -- not tied to a hosting service -- and easily migrateable to another hosting provider in the future, should I want to change vendors.
• I'm planning to use Azure Websites for hosting. While it does have a really nice web dashboard for viewing stats, etc., the biggest selling point for Azure over other hosting providers is the integration with WebMatrix, which makes it extraordinarily easy to pull an instance of the current website, database and all, down to my local machine in order to make changes, etc, in an isolated dev environment and upload them back to the production system (or destroy them) easily. Pricing is reasonable and likely only to go down over time. They also made is super easy (three clicks) to spin up a new WordPress site.

Kevin P. Davis asked the question "Is There an IT Talent Shortage?" on his blog this week. I started to post a response as a comment, but it kept growing, so instead I'm posting it here. If you're a software developer/manager, I highly suggest you follow Kevin's blog.

To recap the question(s):

I keep hearing that there's a huge shortage of IT workers.  That there are businesses hiring, and they can't find good people....Is it that the IT worker rate of unemployment is that much lower than the general population rate?  Or are there plenty of IT workers that simply can't find work, or are in the wrong location....That is, are there more senior people available out there than junior people, but the openings are all for junior people (or vice versa)?

Like any good macroeconomic question, there are many variables at play. Here are my thoughts on the topic:

To be clear, I think we're only talking about the US market (in as much as it's separate from the global market), and specifically, US-based companies looking to hire software developers.

First, IT unemployment rates are absolutely lower than the general population. According to one report, it's half. I think this is because companies continue to see the ROI on software development projects and customers continue to demand greater access (web, mobile, etc).  Of course, in some cases, the ROI of a software project comes from reduction of head count (or reduced need for additional head count) in other areas of the business, which just furthers the unbalanced unemployment allocations.

So demand for IT workers, especially software developers, has remained high.

Meanwhile, cheaper sources of IT workers (ie: off shoring) have shown to be less cost effective than previously thought, so my perception is that fewer dev jobs are "going oversees".  After the dotcom bust at the turn of the century, the number of students studying computer science type degrees leveled off (vs being inundated during the bubble).  This has the affect of keeping the supply of skilled workers fairly steady.

So, at a high level, we've got high demand and a limited, but not scarce, supply.

But what I've seen in the last couple years, both as a person interviewing candidates, and as a job seeker myself, is that hiring companies have changed their approach since a decade ago. With a large exception for consulting firms, I see fewer companies willing to train workers for the skills they want and instead look for candidates with existing experience in the specific technologies utilized in the job. Since the technologies available continue to grow at a high rate, and existing technologies are not going away, the likelihood of any given developer having the wanted skill(s) is shrinking. This has the result of reducing the supply of workers drastically from the larger pool. To some extent, I think some employers are setting their expectations too high.  Personally, I prefer to hire for ability to think about complex problems and less on years of Lisp/Ruby/PHP/TCL/Cobal/Bash/Scala/Objective-C/FoxPro experience.

At the same time, salaries have generally stagnated for the last few years, and experienced developers have, in my opinion, become more selective about the work environments they are willing to consider (telecommuting, flex hours, commutes, etc, etc).

So for any given job listing, the number of people in the worker pool who have the skills sought, would be willing to work for the hiring company, and are willing to leave their current employer or are unemployed, is shrinking.

Supply vs demand.

My expectation is that within the next three years, as the economy recovers, there will be a disproportional increase in salary levels for experienced developers, and that more companies will be willing to hire more junior and mismatched skill workers to train on the job. This will pull more people into tech jobs, thus increasing the supply and reducing demand, but over the course of a decade or so. This cyclical affect will continue for the foreseeable future.

I also see companies less willing to hire full-time developers, so consulting firms are able to draw in a lot of good talent (further reducing the pool for everyone else) and they are more willing to train new graduates and mismatched skill developers. Along those same lines, I've seen several of my experienced developer peers move out of staff jobs and take independent contractor roles, where they can better dictate the work environments, hours, salaries, etc. and/or more directly reap the rewards of their efforts. I suspect these are both temporary trends until the economy pick back up and companies are more willing to provide those things directly.

Lastly, I think geography plays a shrinking, but noticeable, role. Chicago has a hot tech job market right now. Looks like Austin does too. Omaha, not so much. But I've seen more companies willing to hire remote tech workers over that last decade, and the industry is trending in that direction, so I see this as becoming less of a barrier. As an employer, if you really need that skillset, you'll hire the guy/girl in the next state; With modern Internet, Skype, IM, etc, they'll be just as productive as if you stuck them in the back cube.