This kitchen needs a better synch

"It's always a distribution problem." And you can quote me on that ...

We are going more and more towards "Web 2.0" applications. This is compounding a problem. It was already hard enough to find applications that would permit data to be synched between multiple copies and locations. Road-warriors have had some success with synchronizing their desktops and their PDA. But our needs are becoming more complex. We need to be be as productive on the road as when we are sitting in our main office, and if T-Mobile would have you believe that Wifi is ubiquitous, the reality is not even close. I won't even discuss working on the plane or while waiting 4 hours at the Passport Office (guess where I am right now ...) Even if the planet was plastered with Wifi antennas, it would still be necessary to be off the 'net once in a while.

Road-warriors use their laptop a lot and being able to synch todo, calendars, contacts, and general notes, as been possible for Outlook users, and now OSX users via .Mac (which is total crap, IMHO). iSync is definitely a good idea, but falls a little short to synch things like RSS readers, outlines (think OmniOutliner), general folders, source code versions, iTunes libraries, blog drafts, multimedia libraries (think Delicious), IRC logs, keychains, and such.

Now compounding this is the fact that, more and more, applications must be accessed via the Internet; and that's the front-end itself... If Microsoft has its way, it will even be impossible to *use* your computer unless it reports back to Redmond's mothership to "validate" its license.

I cannot understand why no synchronization standards exist. I guess it is too complex of a problem.
Each app needs to document what it stores and how. It has to be in a structure that can take being modified by third party apps, say XML. The structure has to have time-stamps and IDs linked at the atomic level. Then we have to create a language in which we can express a structure to scan for and a sub-structure to modify in order to synch two repositories. Preferably, the app must support re-scanning of its databases or configuration/status files.

These are problems that have been solved for Calendar apps for the longest time. Now a calendaring app cannot survive unless it offers some form of iCal support and synchronization. Developers selling commercial-ware and share-ware need to realize that they can double their sales by integrating proper synchronization capabilities in their save formats. If your app can be used both on a laptop and a workstation, then this applies.

Using a corporate Wiki

One of things that has always nagged at me was that departments always had individuals that would horde information; the "kingdom builders". These would be particularly nasty in the Operations areas. Also, if you did hold of their official documents, and you found a problem with the doc, or the system had drifted away from the doc, it was close to impossible to change it yourself.

The epitome of this is the Portal. Portals were all the rage about 3 years ago. Corporate internal portals for the employees were seen as a way to get information to the employees of the company. In reality, it just gave a way for the executives and HR to slam corporate rules at the employees. At the very best, Portals were nice attempts at corporate memory but ended up being an ivory tower of management-approved sanitized libraries. They were a feel-good thing for management, but ended up being close to useless for workers to easily distribute information to other workers.

Enter the Wiki.

Wikis are great to partially address these situations. Documents written in the Wiki can be changed by anyone in the company, in real time, if any discrepancies are apparent. Anyone can create a new document/link. It is a great way to distribute knowledge inside the company, and a great way to maintain corporate memory. I believe that all Intranets should have a Wiki installed. If they don't get immediate traction, leave it there, it will grow into its own in time. At the very least, you will find that Operations will use it almost immediately to store Standard Operating Procedures docs (SOPs).

We use PMWiki. It is based on PHP, and uses rather simplistic Wiki formatting tags. It has some quirks that might force us to look at something else. We might code our own using TurboGears at some point.

How are we hiring ?

Having a minor in Human Resources, I have scathing opinions of typical hiring techniques in the high-tech sectors. I have spent most of my career in the Silicon Valleys (north and south) and most of that as a consultant. I have also been a founder of a start-up which went on to be listed on the stock exchange. The usual hiring scenario is this:

• An HR person asks the manager what he/she are looking for, including the skill sets and experience required. The manager usually has no specific clue and will list all the small stuff that might *perhaps* apply. Like "Must know Perl" if the department has a few .pl files in their day to day operations.


• The HR person takes a look at the title of the position (like "Senior Programmer") and the list of knowledge and skills that the manager listed and then proceeds to apply some weird algorithm that has been given to them by their grandmothers or something.... So now, the "Must know Perl" becomes "Must have 7 years of Perl programming experience", or god forbid "Must have 10 years experience in Web 2.0".... I was constantly floored when I was asked to have 7 years experience in C# when it had only been out for 5.


• An ad is put in a newspaper, and on websites like Monster.com


• A gazillion resumes are received. 500 more trees die. Spam is mistaken as legit applications.


• The HR person has to apply a "scoring system" to all of these to decide which ones make the first round. This is where the HR person feels they are the "value added" in the system. So, our "7 years of Perl" becomes 14 points, and our "15 years of Web 2.0" becomes 30 points; even when it should be obvious that the candidate lied through his teeth on that last one...


• The top scoring 10 or 20 candidates are kept and their resumes are forwarded to the manager.


• The manager reviews the resumes and apply their own scoring system and keep about 5 to 10 candidates. They report these to the HR person who schedule the interviews.


• The candidates come in and meet the HR person for a quick 10 mins interview and then meet the manager for an extended interview. Fun is had by all. The manager is looking for a "team player" or some other soft skill. The candidate is encouraged to spew buzzwords at the manager. If the candidate is really unlucky, they will get to be interviewed *very briefly* by one of the department's techies.


• The manager asks the candidate what salary they are expecting. They candidate replies that he/she is very flexible, and what did the manager have in mind ? This continues on back and forth until someone says a number. The first one to say a number loses.


• The candidates are all thanked and the nephew of a VP is hired.


• OR, if the VP has no relatives to hire: The candidate with the lowest salary requirement is hired.

I wish I was joking.

We are in 2006. This procedure is total crud. We are in the information age, and hiring is still in the dark-ages. Very few managers know how to really describe their departments needs, and only a handful of companies actually test the skill sets required. Those that *do* test, typically do so at the last round of qualifications. They might as well hire randomly...

We should be testing our requirements first. Have a questionnaire on the Web and demand that applicants answer before submitting their resumes. We must have a way for the candidate to demonstrate their skill upfront, with their application. I am not proposing a boilerplate solution here, just that receiving even one resume must be accompanied with some form of skill demonstration. It is up to a real HR department to show the proper initiative and craftiness necessary to cull the crud from the cream. Anyone can lie on a resume. I find they are totally useless as a hiring mechanism. Also, a lot of candidates do not have the writing skills necessary to show well on a piece of paper.

Let the techies of the department review the skills answers. If the candidates had to code a certain function as part of their application, let the techies review each of the code bits.

When the techs have a few answers that they like, HR should contact about 6 candidates at a time and bring them in for interviews *at the same time*. When they come in, they are given a piece of paper and asked what salary they are expecting. That information is to be kept hidden during the "group" interview.

The group interview can take a few forms, depending on what soft skill-set is necessary. You will be asking your candidates to participate in a game. The game will try to bring out a skill for the interviewers to assess. The department manager is usually the one to oversee the group interviews. Here are a few examples:

• Create two identical Lego sculpture. Same colors, same blocks, same positions. Make it *really* complex. Now break apart one of them and put the pieces in a box. Take the other sculpture and put it behind a blind. Designate one candidate as the "describer". He/she gets to describe the sculpture to the rest of the candidates. The rest of the candidates must work together to duplicate the sculpture that is being described to them. At any time, a candidate may ask to take the place of the describer. Watch the sparks fly.
  
• Have a list of technical questions, and ask the group for answers. The first one who raise their hands gets to answer. Don't keep score. Just watch if the candidates are confident enough in their knowledge to show little stress during the questions.
  
• Have the candidates split into 3 teams of 2. Explain a problem to which they must design a solution. Have them write on a piece of paper their name and their answer. Have them give in their individual answers. Then get them to discuss and debate the design with their partner. Have the team give you the team design. Compare that design with the individual answers. See which candidate was able to compromise best.
  
• Make up your own
  

The HR person gives the salary requirement answers to the manager after the manager has picked 2 or 3 candidates.

If you still must know how the candidates fit with the rest of the team, bring the team and the candidates out to lunch together. Then ask the team what they think.

Summary

1. Test the skills first.
2. Involve the co-workers of the position as soon as possible in the culling process.
3. Interview in groups, not as individuals. This way you see how the candidates react under real stress.
4. Salary is not part of the main interview items.
5. Team interaction should be tested on a social setting.

Even will all this, I must admit that the chances are that you will still be forced to hire the VP's nephew...

Trip to San Jose

So, off I got to XenSource certification. A trip to San Jose is not strategic for us at this time, but we really want to get in bed with XenSource. I *have* to meet with their executives and get their technical certification if we want to play ball together.

Here's a rundown of the trip:

Customs and security were routine.

The flight to Chicago was too heavy so the airline had to find 4 volunteers to get off the plane before takeoff. Only two people said "thank you" to the volunteers as they were walking down the plane's corridor. I guess graciousness isn't really a traveler's trait.

My laptop started giving me SMART failures during the flight, so I started a backup on the plane, which I had to interrupt because we were landing. I won't purchase from Tiger Direct anymore, I really promise this time.

Arriving at O'Hare, I started Kismet and noticed that the Wifi coverage was huge, but I had no time to connect if I wanted to eat and make my connecting flight. The "Bar&Grill" on concourse G has a good fruit and bagel breakfast. I heard a Homeland security anouncement as soon as I was off the plane : "Level is Orange!" Who cares, and who can really tell what the heck that means ? Should I really change my behavior or are they just announcing justification for draconian security measures that have *previously* happened that day ?

Finding a power outlet near the H8 gate at O'Hare is like finding a needle in a haystack. I finally located an outlet and sat on the floor in the corridor to recharge my laptop. Sure enough, 10 mins later, a golf cart came by and the driver ask me to go somewhere else. That's OK. I got 20% more juice for my battery. It's not like there were any signs on the floor or on the wall that this was a reserved space...

The flight from Chicago to San Jose was OK, but I swear that I have hearing damage from sitting right next to the engines on takeoff. I was wondering if I wasn't *in* the engine. I guess S80 airplane are not known for their "hush kits".

The hotel was OK, right next to the HP arena where the Sharks play. It certainly was not a 4-star, but had complimentary Internet, complimentary breakfast and complimentary dinner. For $79US per night, that's pretty hard to beat.

As I said in my previous blog entry, the whole discussion and certification with XenSource is under NDA, so I cannot write about it at this time. But the people I met were awesome. I mostly stuck around the Aussies and Kiwis since they seem to be the best people to drink with :-) Ask Stuart to tell you the one about him going from the east coast to the west coast of the US with a $300 car purchased in New York, and then sold for $100 in Los Angeles when the trip was done...

The XenSource executives were on the ball, and my certification went rather well. I stayed at the back of the class with some kindred souls, and soon the trainer was calling us "the dangerous guys at the back", or maybe it was more like "the <censored>ers at the back"... Rebooting the Aussies box from the other end of the classroom while they were trying to finish a module was fun, and they promised to get even later over beer.

Leaving San Jose was a bit tricky. The weather was pristine but the flight was delayed for 2 hours as our destination (Chicago) was dealing with -2C temperatures. Our pilot said "I don't really know why that really matters, but O'Hare flight control tells us what to do , and we do it". I don't think he was too impressed.

I landed at O'Hare already 10 minutes late for boarding for my next leg. I rushed and got there to see the other passengers filling the waiting area. The flight was actually delayed 1.5 hours. When the plane finally did show up we were once again told that they would need 3 volunteers because they had overloaded the plane *again*. I volunteered, but it came out that it wasn't necessary since 3 passengers didn't show up. We got good wind and I ended up landing in Ottawa with just one hour of lost time from my original schedule.

Using git as a management tool.

We use git a lot. I really love it. One thing that I have been able to do with it is to track each programmer's "drifting away" from the main branch.

We can use this to remind individuals to update the local branch to make sure that they don't drift too far out and that way their commits will have much less chance of conflict. It is also vital for doing structured releases. A release manager using this technique can easily tell if all programmers have commited all relevant code.

Start by cloning the main tree:

cg-clone /main/development/branch <product>
cd <product>
cg-branch-add <programmer name> /programmer/local/branch
cg-fetch <programmer name>
cg-branch-add <programmer2 name> /programmer2/local/branch
cg-fetch <programmer2 name>
and so on

Then use this script for getting and showing where everyone is:

cg-update
cg-fetch <programmer1 name>
cg-fetch <programmer2 name>
...
cg-fetch <programmerN name>
gitk --all

You will visually see where each programmer stands regarding the main branch, and if they need to push their local branches into the main branch for release.