November 16, 2010
Norway - the land of opportunity?
It shows the relative income differences from one generation to the next (US=1). And it turns out Norway scores very well on this metric, so maybe state funding of educational loans and a pretty egalitarian society pays off in the end. The income mobility is almost 3 times that in the US and the UK.
Interestingly enough, the UK scores just as well as the US. I guess it is just prejudice, but I have always thought of the US as the classical meritocracy - if you are good, you can succeed no matter your background - while my oversimplification of the UK society is as more of a gentlemen's club where the right school, connections and parents are all a necessity to do well.
So the American Dream might just as well happen in Norway, today? I guess still lawyers breed lawyers more often than others, but on a macro level it does not look too bad. Anyway, I think it is a graph to be proud of (still a pity to be beaten by the Danes again, of course).
October 5, 2010
Vintage Code on a New Canvas
August 28, 2010
Getting beyond the first sale for a micro ISV
June 11, 2010
Internet as an application platform - even for HD movie editing?
May 21, 2010
Fast mobile and fun TV...
In short, the new and faster version of Google´s OS for mobile devices, Android version 2.2 codenamed Froyo, was launched as expected. There was some picking at Apple with references to their famous "1984" superbowl commercial calling their approach Draconian, push APIs were launched "not to address basic shortcomings in the operating system of the device, such as lack of multitasking", demonstrating tethering in Android with the words "now let´s turn to a device that doesn´t have connectivity, how about that iPad?", etc.
The Android momentum is high, with 100 000 activations per day. The Flash plugin (10.1 public beta) was announced as expected. I am looking forward to see how it performs, as pointed out yesterday Flash on the mobile has yet to deliver (when I supervised a MSc-student in 2005 doing context-based mobile app that it was supposed to be half year away from being great, which I think it has been since...). Hopefully this will be it!
Google TV was also launched, not quite as pre-announced as the Android Froyo, but not unexpected either. Personally I am more interested in "Chrome OS for TV" - to have a lightweight connected OS with browser (for public screens etc.) in TVs than the PVRish and EPG aspects that it was focused on in the announcement, but I guess it can be used for both.
It will be interesting to see if Google will be the ones to get voice control right. It has been tried (several times) before, including getting similar wow-demo-effects to the ones we saw in the keynote working. With all the data to improve their algorithms, they might just be.
Oh and to leave you with a maybe non-exciting note that I forgot yesterday: App Engine are getting SLAs and standard SQL databases, which might in fact be of the more important announcements for CIOs considering running apps in Google´s cloud.
May 20, 2010
Quick reflections on today's Google IO keynote announcements
May 8, 2010
Startup idea generator
- Worst thing about the subject: That we have to have it!
- Best thing about the subject: That we are done with it!
March 23, 2010
Old, grumpy and agile – the ideal combination?
This is a thought that I have been struggling with for a while: Are agile methods working better for managers and developers "born agile", i.e. that was never exposed to more ‘waterfallish’ structured approaches, or is the real power of agile only reaped when you have exactly that background?
Last week my interest in the issue was resparked. I had a discussion about Scrum with the students in the e-business class that I lecture. It was really inspiring to see the eager contributions (not always the case, I must admit...) and the students' experience and opinions about Scrum. Nevertheless, I also felt that compared to when discussing agile principles with my colleagues (not all grumpy and old, but you get the idea...), we were missing some common ground and viewpoints that are useful having as a background when consciously deciding to work in an agile fashion on a project. Thus I wonder if those never exposed to such documentation-heavy methods miss out on something, even if we all agree agile methods are "better"?
I find it a bit hard to pinpoint and be specific about the relatively vague feeling/postulate. I’ll try with two, maybe relatively random, examples: If you have grown up with carefully designing an architecture before starting to code, you’ll know which parts to include in the “vertical part" of a broad prototype/first-sprint-end-version. Or, if you have experienced the often large gaps in understanding of a formal specification, you can use that knowledge to document just the right stuff in your user stories - knowing when to formalize to clarify. That kind of knowledge, in my opinion, goes beyond just being "experience" - it is also tied to the more documentation-heavy approaches and how to work with the shortcomings of those.
It is also my opinion that, at this point in time, the vendor side of most projects is often more keen on working with agile methods than the customer side. In that regard I also think the grumpy old fellows have an easier time, knowing how to smooth things a bit out by providing the linkage between structured reporting and the measurement of progress in terms of pure increments of working code.
My preliminary conclusion is that currently it is certainly no disadvantage to have been exposed to more classical project management and software development methods before moving to agile. Rather the contrary. But, I also have a positive outlook towards more and more buyers of software projects specifically wanting to work using agile methods. When that happens I might end up just grumpy with no advantages of it at all. Well, I guess I can resort to thinking about how much better things were in "the good old days" (well, not really - but "If you take away make-believe from the average man, you take away his happiness as well").
 - It is my strong opinion that the first deliverable should as broad as possible in terms of functionality, but as indicated in the above paragraph I think it also makes sense to select some narrow (and often tricky) parts of the solution for a full vertical proof-of-concept as early as possible. Selecting these is often more an art than a science, and my little fear is that this skill is not as well nurtured for the "born agile" colleagues that are currently graduating.
But I might be wrong and just "not getting it", because of my somewhat old-fashioned mindset... I also wonder if it is wise or misled to use sprint N for "architecture of X" or "design of X" and sprint N+1 for "implementing X"- isn't this just waterfall in disguise? That was a sidetrack (in a footnote!); maybe a post on that later.
 - Of course, being born in the late seventies, I don't know the really good old days, when everything actually was better. Or so I've heard.