Coding for the kids

There has been some discussion lately here and also abroad (see Oct 2013 Wired and the president of Estonia for BBC news) on whether kids should be taught computer programming already during the first years at elementary school, or even in kindergarten. I don't know about the latter, but definitely programming languages should be easier to grasp than any natural language due to the more limited syntax and vocabulary, so if a 7 year-old can figure out the basics of a foreign language, programming shouldn't be any harder.

Myself I was introduced to coding with Sinclair ZX81, and since my dad had bought only the computer and not any programs, the only option was to either type in a program from a magazine or book - or to write it yourself. I was about nine years old at that time, I think. Come on, writing BASIC is like writing English, which I was introduced to at school around the same time.

Of course not all kids (neither when they are young nor when they grow up) need to get deep into coding, but I have to agree with writer Elina Lappalainen and Ilkka Paananen of Supercell (both in Talouselämä 38/2013) on that knowing the basics of how computers are made to work is something that can be of incredible benefit later on as dealing with computers has become so everyday thing that it would take an effort to not to use any for even a single day. I've long been thinking that the fact that buyers in software projects don't actually know anything about what software really is (or how it is made) is one big reason for why software projects go as they tend to go (i.e. badly). If they had had a peek at how things operate within computers in school, things might have been different later on.

After all, I think kids are still today taught in Finnish elementary schools the basics of handicraft (both with wood and textiles) and cooking, not to mention sports and arts, why shouldn't we be teaching them also something about computers - it would be potentially just as important for their future.

Consumer services going corporate

Lately I've been involved in implementing Google's services in an enterprise setting. It has been rather amusing at times, and rather irritating at other times. Somehow I have had the feeling, that the enterprise service model is still so new that it hasn't made it's mark on the services yet, or maybe it is Google's willful decision to be primarily a consumer service company.

(image by Bartosz Kaszubowski)

I base my claim on the fact that everything is always tied to a personal account (and even though you can use an account in multiple devices or for multiple users, the policies forbid that kind of usage), so we eventually need to sync our Android user base to Google's cloud and manage them there as individuals (although grouping is possible). You also need to adjust to certain things like using a (personal) credit card to pay for e.g. the developer console (after which the card is attached to the account from time to eternity) which to an European feels awkward compared to invoicing, and when communicating with a retailer they - obviously - insist on using Google Hangouts which just doesn't work if you don't have an Google+ account - so you end up either using your personal account or creating a new one for that purpose. In fact, I have currently five Google accounts including the corporate one, I don't know if that is much but it is a ridiculous amount of accounts to have as a user for using the services of a single company. Of course that is partly due to my explicit wish to separate some things, like not have my personal account tied to my work celly (or maybe an Android celly of any kind, to make it easier not to accidentally sync loads of stuff in there). At least now I can ditch the one I created specifically for work purposes, since the corporate account replaces it.

Also, Google does seem to be pushing their services pretty hard, even though I wonder how many enterprise customers (and I'm talking about medium or large companies here) are interested in having corporate Gmail account enabled for their employees (or Google's calendar, address book, instant messaging, document management & file sharing etc). It was some work to adjust the 70+ services so that they didn't seem awfully wrong...

That being said, I must admit that at least Google is trying hard. They have a wealth of support documentation on-line, which seems to be pretty correct and helpful at least if you're using English language for your services. When we finally got the Google Apps for Business up and running, there was such a huge amount of stuff in there to adjust that it made some kind of an impression to at least this systems nerd. The web based admin UI is a bit slowish at times, and it is also complex as hell but then again so is the service offering.

We also ended up transferring the developer console (that we had opened already earlier not knowing we shouldn't do it quite yet) to the matching enterprise account and while the process was incredibly difficult from the user point of view (had to consult both the support docs and the retailer to get through it) and while it required paying another $25 for opening the enterprise developer console, it also allowed requesting a refund on the previous payment and moving all data between the accounts (even though most of the services didn't seem to support the automatic transfer, including dev console). I'd bet that not all similar services offer that possibility.

Currently we have entered the pilot phase with Google's enterprise offering, and it will be interesting to see how things go. At least there are plenty of possibilities to be reaped for the per device license fee... And the users seem to be interested on getting Android devices as their everyday tools.