[Garak takes a drink of root beer]
Quark: What do you think?
Garak: It’s vile.
Quark: I know. It’s so bubbly and cloying and happy.
Garak: Just like the Federation.
Quark: And you know what’s really frightening? If you drink enough of it, you begin to like it.
Garak: It’s insidious.
Quark: Just like the Federation.

- Star Trek: Deep Space Nine - Way of the Warrior (S4 E01) (and here’s the video)

For a long time, I’ve been quite anti-Google. I’m certain this comes from loyalty to Inktomi, where I used to work once upon a time. In time, it was strengthened due to my dislike of the number of people who joined the cult. Google released and/or acquired a lot of cool apps: maps, Earth, calendar, mail, gears … the list is virtually endless. It could be argued that this was for the benefit of the technology-using community as a whole, but to me it seemed like an incessant grab for geek mindshare.

Eventually, people started to catch on that Google are potentially a very scary organisation. After all, they know what you research on the internet, what you read online, who you send mails to, who you meet with and why. In fact, they probably know as much about you as any given organisation possibly could, and you gave them permission!

However, many months and years of bombardment with applications and the need to be a part of the software community has meant that it is now virtually impossible for me to function without using Google’s tools. They have started to suck the resistance out of me - I’m becoming accustomed to the root beer (or the Kool-Aid, to mix metaphors).

The scariest thing was when I tried out Google Reader, and people had already shared 51 news articles with me, assuming all along that I used it. Gah! I’ve made myself paranoid all over again, just by writing this post. Time to block google.com cookies again.

Your software team is made up of developers (cooks) and often headed up by a manager (chef de cuisine) sometimes with one or more technical leads (sous chefs). They produce applications (dishes) or libraries (portions) that are used to create a larger product (meal) that form part of a suite (menu).

Sometimes the applications have the same implementation underneath, but look different to the end user (re-arrange the food on the plate) or even feel different (change the garnish or sauce). Sometimes the application will work the same on the outside, but have a different implementation underneath (the recipe for any given portion might change but the meal will still be the same).

Different people are good at different areas. For example, someone might have great knowledge in developing the GUI (saucier), someone else is good with databases (pastry chef) and so forth. Some people will specialize in Java (Italian) or .Net (Chinese), and within those might have a lot of knowledge about for example Servlets (pizza).

We have design patterns (recipes) that make it easier for people to produce good quality apps (dishes). If you need to write an app (cook a dish), you can start with what you know. You know that a web app (pizza) will need some HTML (tomato sauce), maybe some JavaScript (pepperoni) and of course a web server (bread) and some kind of CGI mechanism (cheese). Of course, once you dig into things a bit more you may discover that your customer really wants a doughnut

Google like to use Python. They purchased Jaiku over Twitter because Jaiku was Python and Twitter was Ruby (I’m sure there were other reasons too. A lot of their APIs are in Python, as are many of their own apps.

Google only releases big scale apps. They released Google Calendar and it allegedly had over 1 million signups in the first week. Google Analytics likewise had stupid numbers of signups (so much so that they couldn’t cope with the volume and had to shut down registration). In fact, this kind of “Instant-One-Million-Users” (that needs its own acronym) means that Google can’t afford to release anything unless it is massively scaleable.

Calendar was a home-grown app for them, whereas Analytics was an acquisition. Maybe this is one reason why the former was able to cope with IOMU and the latter wasn’t. With this in mind, enter App Engine.

Now you can write apps that meet Google’s criteria: they are Pythonic, massively scaleable and best yet: already run on Google’s infrastructure. So, when someone writes the next big web app, it just got a whole lot easier for Google to acquire them and then avoid death by IOMU.

Developers solve problems. This is their raison d’etre. If you have a technological itch that’s bugging you, a developer is the person who wants to scratch it. Developers have the answers to things. They like to be able to say “Oh yeah, I can fix that. No problem.” They’re movers and shakers, heavy lifters, the Intelligentsia. Developers rock.

It’s therefore an unusual trait in a developer for them to say “There’s a problem, and I can’t fix it.” Other developers will look down their noses, or gasp in astonishment to think that someone might betray the Brotherhood by making it publicly known for even an instant that there might be something that just isn’t known.

OK, I exaggerate, but you get the point.

Sometimes the most useful person in the project is the one who stands up and points and says “There’s something bad happening.” You don’t have to know what the root cause of the problem is, you don’t have to know how to fix it - you just have to spot the symptoms. And that courage should be cherished, because without it you can end up with a scenario where everyone blithely carries on doing things in a broken way because no-one had the courage to stand up and say it was broken, simply because they didn’t also have a solution.

Wise Fools sometimes only make themselves heard at retrospectives, which is one good reason to have them, and a great reason to have Heartbeat Retrospectives (a mini-retro, held at any time with any group of collaborators). Give those folks a chance to speak up and be heard, in a safe environment free from retribution or condemnation. In fact, I would go so far as to say that the safer your retrospective environment is, the more likely that you’ll get the benefit of a Fool’s Wisdom.

Anyway, I’ve rambled on a bit. Better stop. My grandda used to say “You can keep quiet and let the world think you’re a fool, or you can open your mouth and prove them all right.”

• The tools for building are readily available and free (though there’s a £50 charge for the certificate)
• Due to the App Store distribution, the customers are accessible and many of them are looking for new software to load
• The hype machine is already built

.

I think this outlook on the existing mobile gaming market is misleading. The tools for building games are free and stable (Java Mobile has been out for over five years, and is supported on every modern handset) and virtually every carrier has their own equivalent to the App Store. While in the UK, I downloaded about 10 games from Vodafone Live, because it was simple and built into my phone.

Most of them are quite complex games. Yes, they are not up to the standard that we’re used to from desktop or console gaming, nor even necessarily as good as what I got from my DS Lite, but most of that was because of the form factor of the phone, not limitations of the tools or the publishers. Given the cost of the game was a fraction of what a game costs for any of those platforms (between 1 and 5 GBP as opposed to 30-50) it lowered the barrier of entry for me to buy - having it easily available and categorized made it simpler still.

However, MJ’s second and third points are the critical ones. People with iPhones are early adopters and are keen to try new things, and there is a lot of hype. Someone with a great game has the potential to have a huge following in a very short space of time. Having an entry point at $5 (or something similar) means that for most people they won’t even think about the spend - that’s the same price as a large cappuccino - and given how easy it will be to communicate about how good the games are (you’re using the ultimate communicator after all) I would expect that several games will swiftly become a staple on everyone’s iPhone.

A word of caution: iPhone development is not like any other platform, not even the Mac. Game development is not like developing any other type of software. And this cross-section of markets will likely be very cutthroat.

(The astute among you will notice some similarities with SWOT Analysis).

To use the window, just fill in something in each of the first three boxes. Don’t worry about filling them in in order, just put them in whatever order occurs to you.

Strengths

This area includes the skills you use on a daily basis, or that people come to you ask questions about. Often (especially with software folks) we think in terms of technical skills - i.e. the skills where we actually do something or produce something, so don’t forget the so-called softer skills: communication, planning, leadership, etc.

Areas for Improvement

Things that you want to get better at. This might be particular skills that you want to learn, or some area of other knowledge you want to acquire. Many people find that they want to improve in many things, so sometimes this area gets crowded - don’t worry, that’s normal.

Goals

Goals differ from Areas for Improvement in that they are things that you can check off to say you’ve accomplished. For example “Learn to program in Objective-C” is an Area for Improvement, but “Write a commercial app in Objective-C and sell a copy to someone I don’t know” is a goal. Also, goals tend to include things that are much longer in time span than Areas for Improvement - e.g. “I want to become CEO of a company with more than 100 employees”. Make sure it’s easy to measure that you’ve accomplished them - ‘checkbox’ style items work best in my experience.

Tasks

Once you’ve finished with the first three sections, put a time frame on the Tasks section (I usually say three months) and then put specific tasks in there that you can accomplish in the next three months. These tasks must help you improve in one of your Areas or help you achieve one of your goals (or both!). Often you use your Strengths to help accomplish these tasks.

OK, so now what?

I get each of my team members to do this every three months. Then every two weeks we have a chat about how things are going (those chats are not solely about this Window, but it does come up - my job is to help them achieve all their tasks) just to make sure there aren’t any roadblocks and that all the tasks still make sense. If you’re doing this for self-development, it’s probably worth looking at this every week to see if you can accomplish any Task in the week, or work on it. Make sure you:

• check off any Task or Goal that gets accomplished
• do the exercise again after your allotted Task time elapses (i.e. every 3 months in my case)
• move Areas for Improvement into Strengths once you’ve learned what you set to learn
• look back over your Windows for the year to see what you’ve accomplished and to help motivate for the next year

I’m not sure if the form-factor of a Window actually makes any difference: it evolved from my need to write it all on a whiteboard. I do think it’s useful to have all four areas up on the board at once because sometimes your mind goes blank and writing other things helps jog your memory.

• are university degrees worth the bother?
• are universities correctly servicing the IT industry (and specifically the games dev market) with skills, knowledge, toolsets?
• why have IT graduates decreased from 1900 in 2004 to 600 in 2007?
• are we seeing a knock on effect from technology failures in the province, e.g. Nortel, Seagate
• with the improvement of toolsets, a lone hobbyist can create ‘flickr’ or ‘facebook’. Is this relevant?
• will we see an upsurge again with demand from Citigroup, Aepona, ATG etc?

Degrees are only useful to get you your first job. If you’ve got your first IT job without a degree, then you don’t need one. After that, it should be possible to achieve what you want with a bit of hard work. At least that’s what I’ve found.

I don’t think universities can be blamed (too much) for not servicing the industry, just given the nature of each. A degree takes 3-4 years to complete, and the content of it is usually created before the degree starts. 3-4 years is a long time in computer terms: 2-3 generations of processor speeds, anywhere from 1-4 major releases of software/language/OS. Really, the best a degree can hope to do is teach good guiding principles and a reasonably relevant language (and yes, I do think Java is probably the best language to learn at Uni).

As a recruiting manager, I’ve found that IT graduates are decreasing for two reasons: the pay is not what it used to be, and you can’t become a millionaire overnight any more. Ironic, given that starting pay has now gone up and some 2.0 companies *are* becoming overnight millionaires. This same trend in hiring is across the world, not just Northern Ireland.

Technology failures: maybe - however, both of those companies are large multi-nationals who opened an outsourced hardware plant in the province. To jump ahead to your last bullet point, these new companies are doing the same but for software/services, which (arguably) has a lower capital investment and, given the more dynamic nature of it, a higher chance of success. I think Northern Ireland really needs some more home-grown successes, and preferably ones that aren’t as staid as Lagan.

Toolsets: it’s semi-relevant. See my earlier post.

This is both good news and bad news. Given how easy it is today to create any kind of app (and it’s getting easier, with Apple, Amazon, Google and Yahoo! all pushing open source frameworks and cheap services to lower the barrier of entry) the bad news is that your cash cow is easily copied by a Small Team with a tight focus. The good news is that if you are doing things right, it’s not about your software it’s about your relationships. So, once Small Team has created a faster, more scaleable, prettier version of your app but fails to get anywhere because you have your market sewn up, why not just buy them instead of spending money trying to compete on features? That works for Small Team too, because they get to continue to focus on what they do best (innovating) while someone else handles the money.

This approach seems to work well for non-software companies. I’ve seen software companies acquired by more “brick-and-mortar” enterprises, simply because said enterprise needed the technology to compete and didn’t want their competitors to be able to buy it.

If I forget myself and accidentally order one I certainly never order a second (I usually drink hot chocolate in Starbucks).

2 - You have to pay for wi-fi so I’m never distracted by IM/IRC/RSS

In the UK, all the wi-fi at Starbucks is through T-mobile who charge £30 ($60!) a month to use their hotspots. With a 1Gb download limit.

3 - The ‘comfy’ chairs are really uncomfortable after an hour or so

One of the biggest issues I had back when I was working in a coffee shop all day was that I’d get too comfortable in the chair and not move around as much as I should (eventually I got tendonitis). At least this way I always get up and leave after an hour.

I think this is all just jitters.  The people who rush out and by Leopard on day 1 are all early adopters - they have the “bleeding edge” gene anyway, and will understand if it takes a week or two for their favourite app to work correctly.  Sure, things will change between the last seed and what’s shipped, but it’s not going to be anything major.  And yes, your apps might break within the first few days of Leopard being released.  But realistically, if you’ve run your app on the seed at all, I find it hard to believe that it will take long to get it working against the release version.

The other main concern is that developers who get the software as part of their ADC membership don’t get it the same day the general public gets it.  Yeah, that’s a bummer but it’s not really that big a deal.  Chances are good your software will work as intended, and if it doesn’t, it’s only a few weeks’ wait.