Macadamian Blog

New Video Mini Series: BlackBerry 10- Top 3 Reasons to Port

RIM's Alec Saunders, VP of Developer Relations, sat down with Macadamian CEO, Fred Boulanger. In the first of three instalments we focus on the strong support available to those developing apps for BlackBerry 10. If this video piques your interest, we encourage you to click here to view part 2 and 3 of this BB10 mini series.

Why Skillset Doesn’t Matter

Part of my job includes staffing projects by selecting the right developers for the job. At any given time, we have approximately 10 new potential projects and as much as 100 developers that need to be matched in harmony. Naturally, my customers expect the developers we put on their projects to have the right skill set to do the job. However, that's not always as easy as it sounds.

In this article, my goal is to convince you that having the perfect skill set isn’t always necessary anyway.

Attitude

Being a service company, we tend to lean towards hiring generalists more than specialists. This is necessary because we don't always know what project they will be working on two months from now. So naturally, one of the virtues we look for in our candidates is his or her ability to quickly ramp-up on new technologies.

Good programmers shouldn't be (and aren't, at least at Macadamian) judged by the programming languages, and stacks they know, but rather the way they think, how fast they learn, and how motivated/passionate they are. In my opinion a motivated programmer who doesn't know a particular technology will be more productive than an un-motivated programmer who does.

Don’t get me wrong; we still try to hire people with decent expertise in specific subjects. This helps us build up the collective experience of our development group, which, at this point, is enormous. We have a wide variety of skill sets we can leverage when we need help. We do this through dedicated "experts" mailing lists, architect brainstorming sessions, just to name a few, and of course , we always respect our customer's intellectual property.

Languages/Stacks

Naturally, I wouldn't propose something totally far-fetched like putting a C programmer on a HTML/CSS/JavaScript project, but if I put a Java guy on a J2EE project, well I'm pretty sure that'll work (with some training). Think about it, the Java developer is probably just one book away from knowing this new facet of Java, or any new programming language, as a matter of fact.

Recently, I read a blog post on Kalzumeus that had a quote I couldn’t agree with more "In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t been doing that one for your entire career."

I remember one case where a potential customer was hesitant about a candidate I proposed to him; the project was about developing a protocol for remote desktop-ing and my candidate did not have any previous experience, (but really who does?) However, my candidate was one of the top guys here, the type of guy that out-codes entire software teams in his sleep. I knew he would succeed. Unfortunately we never had the chance to find out, but the point here is that I wouldn't present anyone that I knew couldn't get the job done.

Conclusion If you are in a rush to finish the project, obviously I will only propose people with the required skill set. But most of the time, any of my staff will get the job done. That's what they live for; most people I hire are looking for a challenge and an opportunity to learn new things, that's partly why they come to Macadamian.

In many instances, I'll even offer to pay for the "down time" experienced during the ramp-up phase. Finally, in the spirit of our new culture value of ‘Being Intentional’, we’ve asked the more senior folks to develop mini-courses to ramp-up developers on new technologies. That way, developers will be better prepared when they jump on their next project!

Ignore the User Experience, Lose A Billion Dollars

From this recent case study -  "Walmart based this incredibly expensive misadventure on what customers said, rather than what they did. And the customer experience is all about what customers do."

This is more or less right. The survey - and what Walmart did with it - are subject to three obvious problems I can see:

1. You are not asking users why they are responding that way
2. You letting a non designer design (if you take a suggestion verbatim) and just implement
3. You are mixing up perceptions (what they say) vs. behaviours (how they will actually act); the point up above from the article.

The general point is that if you want to design anything (software, a store, a culture) and you want to do research to inform your designers (software, store, culture) then you need to be aware of both the benefits and limitations of the research.

You need:

• a clear purpose and question(s) (walmart didn't) correct methodology (survey wasn't it)
• experts to carry out and interpret (they didn't have it)
• talented, knowledgeable well informed designers who know what to do with the information (again, missing from Walmart)

This is what software companies absolutely need in their product management and design process. If Walmart had 90 seconds of our time (or any professional product manager or UX researcher's time), they could quite conceivably have saved a billion dollars.