[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.

Thank dog we’re going.

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.

(Creative Commons Attribution license)