Power of Gamification

The leaders of my company wanted to see what all the workers think. We have a lot of employees in the company. So they hired an outside firm to set up an anonymous survey. They do these on a yearly basis. Last year there was a whopping 80%+ participation rate.

Here is the stickler. This is a long survey. And they want you to take it on your own time. That might work if you are chillin on your job. But me and my team are busy. I cannot justify spending any time on such a survey.

The local managers figured we were busy. So they cooked up some gamification techniques to encourage participation. They divided us up into teams. And they are pitting team against team. There is supposed to be a prize for the team that finishes the survey.

This gamification is encouraging some people to do the survey quick. They even try to get others on their team to do the survey too. I have a problem with this though. They said the winner will get some undisclosed prize. If you are going to wave a carrot in front of me, I need to know what the carrot is. Otherwise I will look a fool if I jump for some undisclosed prize.

I have some other ideas on how to motivate all employees to complete tasks such as this survey. But I will share those ideas at another time.

Multi Install Madness

I got back to work after a week long vacation. There was apparently a high priority problem with the rollout of our latest software. This was a major upgrade. However the uses expected to run the new and old versions of our software side by side on the same machine. Ummm I said I thought we did not support that. Apparently we we supposed to.

The problem was that every time you install our software, we uninstall any old copy that is already on the system. Normally that is the expected behavior. However the customer wants a specific version of the old software to stick around. The lead on my team decided that we wanted a multi-install capability turned on in our Installshield project.

Multi install sounded like a bad idea to me. Sure enough, the lead was having all kinds of trouble with it. In fact, he now had two problems. The customer's old versions were getting uninstalled. And he could not figure out how to get multi install to work in all scenarios.

So I backed the guy up. I told him the InstallShield and Windows theory is that a product knows what kind of product it is. And it we got it set up to remove all prior copies of itself. If you do not want to remove prior copies, you need to create a new product. For InstallShield, I had a hunch that this was some sort of unique string or number like a GUID that uniquely identified our product.

As soon as I led my team leader down that path, he found a Product GUID setting in InstallShield. With the click of a button, he was able to generate a new GUID and solve the customer problem. He backed out his multi install problem. The moral of the story is to first have a deep understanding of the problem. Then you can clearly see what it takes to resolve it.

The Rise of the Nomad

When I first started coding, I had an engineering degree. I learned how to solve problems in school. So it did not matter what work I was assigned. I had already learned how to figure new things out. No trouble.

Later I saw that developers specialized in languages and platforms. Back then Microsoft seemed hot. Therefore I learned the Microsoft stack. I became a Microsoft developer. My self proclaimed titled was a Windows Application Developer. Made for quite a few job opportunities.

When I started my current job, I got hired in as a Windows Application Developer. Perfect fit. But then I found that the database in use was Oracle. And our system is Oracle-heavy. No trouble. Remember that I am an engineer by training. I learned Oracle on the job. Even went and got Oracle certified.

Nowadays I don't seem to do as much Windows programming. It is mostly database development in Oracle. I thought I might need to morph into being an Oracle developer instead of a Microsoft developer. But lately I have been reading that it does not matter what stack you use. Your stack is not your value.

Patrick Kalzumeus says you should not even call yourself a programmer. And Andraž Bajt decribes the rise of the Nomad programmer. Time to sit back and think about my title in the work world.

Priority Order

I remember it was 7 or 8 years ago. There was going to be a new system designed to replace the current one we supported. So we were a bit more ambitious rolling out the last upgrades to the system. In retrospect, we pushed some things out too early. That meant a number of things were broken in Production. Not a good place to be at.

Somehow I rose up to lead the team. I figured that my job was to coach the green developers. And I would try to protect them from the crazy antics of management who thought they knew better. We were busy. I figure we were working around 50 hours a week. I did my best to keep morale up. After polling the developers, I went out and bought food they liked. Hey. I was not a saint. I billed the company. But I made sure we had some nice food to eat.

One of the developers figured out this job was not for him. So he put in his two weeks notice. The managers asked me to help him wrap up what he was working on. I had a good rapport with all the developers. This one developer who was leaving confessed that since he was quitting anyway, he was just going to slack off during his last 2 weeks of work. Fair enough.

The thing that was disappointing was that this guy was really excited about his blog. And he wanted to see if I would read his blogging. I was busy trying to keep some disasters managed as best I could. And I was still on the ship that was rocking. The last thing I needed to do was read blog posts from a deoparting slacker. But I knew diplomacy. I let the guy know that I was a bit busy at the moment. So blog reading would have to wait for less busy times.

I never did check out his blog. Can't blame the guy for leaving a challenging work environment. But then again, I can't imagine he had much worthwhile to say in his blog.

Microsoft Controls

Our project currently uses Microsoft Visual Studio 2008 to do the development. Previously we used VS 2005. And before that we used VS6. Right now I am trying to bring up one of our large dialogs in the resource editor. I get an error message that "4 Active X controls could not be instantiated. Reinstall or register the controls and try again."

Okay. I have the OCX files. I register the controls. Actually it is one control - the Microsoft FlexGrid. God knows why were are using it. But I register the control. Still get the error in Visual Studio. Come on Microsoft. These are your own controls. And I had our customer buy your Visual Studio. That cost some big bucks.

Well I google around. And I figure out what the problem is. These are VB6 controls from way back when. Visual Studio 2008 does not by default install licenses to use VB6 controls. Go figure. Microsoft's knowledge bases tells me to either (1) intall VB6 on my machine, or (2) find some hack on my VS2008 install media to update my registry.

I guess the real message that Microsoft is trying to send is for us to stop using the VB6 controls. Otherwise they will make it hard for developers to use them. Hey I would love to fool around and find the latest .NET controls and put them in our application. But my customer has real business needs that need to be solved. They don't want me wasting time updating controls that have no positive business impact to our system. Darn you Microsoft.

Environmental Caution

Our system keeps some slow changing values in environment variables. This works out okay. Normally we only changes these about once a year. Sometimes we need to make changes to some of these environment. I had to do so this week. But I had some troubles. My builds kept using the old values that were set. Then it dawned on me. Visual Studio must be caching the environment variables on load.

So you need to exit Visual Studio and restart it for it to pick up environment variable changes. Perhaps storing state in environment variables is not such a good idea. We could stash this stuff in the registry. Changes in the registry are immediately available to anyone who accesses the registry. We actually use the registry for a bit of run-time values in our app.