Archive for February, 2011
Predicting the future of technology and business software development has never been more difficult, do I play safe and follow where others have gone before (and enter the world of ever increasing patent infringement!), or do I try something different with possibly higher risk?
I’ve been a follower of SaaS and Cloud since the very beginning and often reflect on where it will go next. I’ve said before that I believe Cloud will change our industry forever and now that bandwidth has caught up it offers some clear benefits. However, despite a decade of trying, real success is still limited to just a few vendors. But predicting Cloud adoption is the easy bit… how will SaaS develop in the future?
Some of the architectural patterns and technologies which were state of the art a few years ago are rapidly becoming long in the tooth and new breed of technologies and tools are emerging… Should I be restricted by the current world of SaaS, or should I go in pursuit of “Super SaaS” the next generation of SaaS?
To understand this better we first need to cut through the huge amount of noise, hype, and ‘snake oil’ from software vendors to understand where we are headed. But for the sake of simplicity let’s say SaaS its defined as accessing applications via a web browser running on a server in someone else’s datacenter.
So what might Super SaaS look like? Will browser based software stand the test of time? Does browser based software really deliver the claimed benefits? Are browsers really platform independent? Is the browser experience good enough for users of the future? Will the on-device ‘Appstore’ style connected applications accessing cloud based ‘back ends’ continue to evolve at lightning speed? Will we see a blend of both in a hybrid style approach? or will something else emerge in the meantime?
Questions, questions, questions… but no answers… so here’s a thought, what if we look at the real innovators of the computing industry… no not the Cloud or SaaS application vendors, but to the online gaming vendors?
Online gaming was with us long before online business software. How many of us remember playing Doom way back in 1993, the granddaddy of many of the networked multiplayer games we see today.
The gaming industry were using the web as a platform long before anyone else, they introduced online forums before anyone else, they had online chat before anyone else, they had monthly subscriptions before anyone else, and they embraced the concept of communities before anyone else. All of which are only now being touted as unique innovations in the world of business software today.
So, In the gaming industry why are the most successful games still ‘on device’? Why aren’t more successful online games delivered via SaaS? Is the desktop really dying? Is Client Server an obsolete architecture? Is multi-tenant the only answer? What of the Social Cloud? and can collaboration work outside of the cloud?
Things have moved on somewhat since the Doom years, and we now have Massively Multiplayer Online Role-Playing Games (MMORPG) in which a very large number of players interact with one another within virtual game worlds.
The technology behind most MMORPGs is interesting, whilst they use the Cloud and the internet to facilitate play, they aren’t SaaS applications; these games are deployed using the more traditional client–server system architecture. The server software runs in the cloud and generates a persistent instance of the virtual world that runs continuously, and players connect to it via desktop client software.
Let’s have a look at this example, my son’s favorite online experience: World of Warcraft, is a popular online multiplayer game with over 12,000,000 (Twelve Million) subscribers as of October, 2010 and the fastest selling game of all time:
Why have the likes of Blizzard Entertainment chosen this model? Well quite simply the cloud isn’t powerful enough to provide the experience that players demand. They want high quality graphics and immediate interaction, a millisecond delay and they’re dead… not good!
So the online vendors have chosen a deployment model that provides the best possible experience to the player by harnessing the processing power and performance of 12 million desktop PC’s to run the game locally, and backs this up with the processing power of some of the most powerful supercomputers in the world.
This isn’t a SaaS application whereby the user runs everything from the cloud, but does go one step further than SaaS by harnessing the combined power of the desktop and Cloud and it shares many characteristics of SaaS at the same time:
- The software is downloaded and installed from the Web
- Players access the game via an online identity and account
- The game is consumed on a monthly subscription basis
- Upgrades are controlled from the server when purchased to allow access to certain areas of the game
- Updates are rolled out online to all users (and cleverly using each user as a peer to peer server for mass updates)
- It facilitates multi person (player) collaboration
- Game data are backed up automatically
So one might imagine a world where the Cloud and SaaS and the Desktop all come together to provide a better experience for the user, why would you rule anything out?
Continuing with the game theme for just a little longer… looking to the future, here are some really interesting developments which are present in gaming software today that might someday transfer to business software:
- Social interaction and in-game culture within the game – it’s here already
- The ability for players to sell an item to each other for in-game (virtual) currency.
- Bartering for items between players for items of similar value.
- The purchase of in-game items for real-world currency.
- Exchanges of real-world currencies for virtual currencies.
- Team working for parts of the game. These tasks usually require players to take on roles in the group, such as those protecting other players from damage (called tanking), “healing” damage done to other players or damaging enemies.
Tomorrows business software user is todays gamer, so wouldn’t it be good to transition some of these ideas from games to the world of business software? I’m sure Business Software vendors would love their software to be as addictive as games like World of Warcraft. Well, it may all come true one day… enter stage left the new buzz word in computing ‘Gamification’ …
Gamification is the use of game play mechanics for non-game applications, particularly consumer-oriented web and mobile sites, in order to encourage people to adopt the applications. It also strives to encourage users to engage in desired behaviors in connection with the applications. Gamification works by making technology more engaging, and by encouraging desired behaviors, taking advantage of humans’ psychological predisposition to engage in gaming. The technique can encourage people to perform chores that they ordinarily consider boring, such as completing surveys, shopping, or reading web sites.
Food for thought? Yes indeed, but enough for one post… more later…
A few weeks back I wrote this post on How to make Agile work for Product Development. As a build on that post I’d like to share how I’ve used Agile to successfully deliver ‘Business’ challenges outside of Product Development.
Consider this scenario, there is a problem in the business and despite many efforts to solve the problem the situation continues to get worse. I’m sure you’ve come across this before and it normally happens when a lot of people are involved in solving the problem but they aren’t working for a common purpose, they are trying to resolve the symptoms rather than the cause, and very often their efforts cancel each other out or make the problem worse.
So how can Agile help?
Well the Scrum process works just as well in this situation as it does for Product Development; here is the process I’ve used:
- Establish a Framework: Break the problem down into its component parts, identify the deliverables and the priority of each deliverable. Sound familiar, yes? This is our backlog.
- Identify Clear Focus and Accountability: Chunk the backlog up into a number of time bound sprints, identify clear accountability for who’s going to lead each sprint, who’s going to work on each sprint, and what needs to be accomplished in each sprint.
- Trust the process and the people: Let the sprint team get on with it. If you’ve given accountability to the right people then you don’t need to do their job. Instead provide support and help them by removing any barriers and keep distractions away.
I know what you’re thinking… Does, this mean you’re abdicating accountability? Absolutely not, you still have accountability for the entire thing and you need to be there if the sprint team need you. Does this mean that you won’t know what’s going on? Absolutely not, Scrum is an open process… anyone can drop into a sprint meeting to hear what’s going on, but remember not to interfere if you’re not part of the sprint team.
As with Product Development, It’s a good habit for the sprint team to use their Friday review meeting for more formal progress update, i.e. if you have a short project with one week sprints, this will be the end of sprint retrospective meeting, if you have two weekly sprints then this would be the mid sprint review, and so on. Personally, I favour Friday as it’s a good way to celebrate progress at the end the week and to retain focus on what the plan is for the next week. This is also a good technique to kill two birds with one stone, e.g. if you need to provide visibility to an external or higher level sponsor.
This really is a very simple and effective process which I’ve used this countless times to very good effect. However, as with Product Development, the formula for success is all down to having a clear framework that everyone understands, a strong focus always, and good people who are willing to take accountability.
There is of course a fourth ingredient to the formula that I haven’t mentioned here, anyone like to tell me what it is?
I’ve been an iPad supporter for some time now and just this week acquired a Kindle for the first time. Taking it out of the packaging I was surprised to find it was fully charged and ready to use. It’s fair to say I can’t remember ever getting an electronic device that has come ready to run, great start.
Connecting it to the network was very easy, in fact I was in proximity of an open wireless connection and it took less than a couple of seconds. So, I’m switched on and connected, the screen looks excellent, black and white yes, but good contrast and very easy to read.
All, good so far, but having a rummage around the options I’m finding it hard work… I’m so used to the touch screen of the iPad, I keep forgetting I have the use the keyboard and buttons to navigate. Anyway, I persist and after a little while I get the hang of it, so it’s time to get hold of a book.
Actually, I already have purchased some books as I’ve been using Kindle for the iPad and what happens next is very cool. When I open the book on the Kindle, it takes me to the place in the book that I’m up to on the iPad… now that’s very clever, a big well done to the designers.
Next time I pick it up I discover the Experimental options under the main menu. Here I find a web browser, which is good enough to use for basic browsing and I’ve used it to access my webmail. Like the iPad though it doesn’t support flash. Also, It’s a bit restrictive viewing web pages in portrait mode and whilst you can change the orientation to be landscape it doesn’t really work as the keyboard is then in the wrong place, but hey… It’s a freebie; I didn’t even know the Kindle had a web browser.
In summary, I like it… it does what it says on the tin plus some unexpected surprises. What’s more it’s less than half the size and weighs a fraction of the iPad. If I want a device to take with me on holiday to read books then the Kindle would win hands down.
I wonder how good it is a squishing mosquitoes?
Well until last week when my 10 year old daughter asked me to help with her homework, I’d never heard of him either. However what happened next really intrigued me… here’s a definition of the Monty Hall Problem from Wikipedia:
The Monty Hall problem is a probability puzzle loosely based on the American television game show Let’s Make a Deal. The name comes from the show’s original host, Monty Hall. The problem is also called the Monty Hall paradox, as it is a veridical paradox in that the result appears absurd but is demonstrably true.
And here’s the problem:
Imagine that the set of Monty Hall’s game show Let’s Make a Deal has three closed doors. Behind one of these doors is a car; behind the other two are goats. The contestant does not know where the car is, but Monty Hall does.
The contestant picks a door and Monty opens one of the remaining doors, one he knows doesn’t hide the car. If the contestant has already chosen the correct door, Monty is equally likely to open either of the two remaining doors.
After Monty has shown a goat behind the door that he opens, the contestant is always given the option to switch doors. What is the probability of winning the car if the contestant stays with their first choice? What if the contestant decides to switch?
Now, like millions of others my instinct… and I have to disclose that I studied statistics as part of my education… was to say the probability is 50:50 and therefore it makes no difference which one of the remaining two doors the contestant chooses next… However, if like me you think this then you’d be wrong:
If the player switches from their original choice then they double the overall probability of winning the car from 1/3 to 2/3.
Amazing isn’t it, and it’s mathematically proven so… sadly, I’m not going to try and explain it here, instead I suggest you look here on wikipedia if you want to understand the science.
So the moral of this story is … always change your mind if a bloke opens a door and there is a goat behind… you might just win a car…. !!!
Around the same time that I wrote my last post “How to make Agile work for product development… It’s all about the people” a colleague sent me a link to an interesting and insightful post by @yeeguy on “How Facebook Ships Code”
I found this post fascinating and I’d recommend you take a few minutes to read it. So why not just retweet the link? Well, I wanted to add my own observations. On whether Facebook have turned Agile into some sort of Ultra Agile concept or if this is more akin to Anarchy?
As an engineer myself, it’s interesting to hear that 50% of the Facebook workforce work in engineering and Operations:
The two largest teams are Engineering and Ops, with roughly 400-500 team members each. Between the two they make up about 50% of the company.
So, they are heavily investing in the platform which is a good, or is it? I have to tell you that when I look at Facebook I can’t help wondering what a team of this size is actually delivering, unless of course one assumes they are working behind the scenes on the next generation. Anyway, let’s not get hung up on that, when you value the company at $50Billion you can afford to set fire to a pile of cash along the way. This next bit is even more interesting:
Very engineering driven culture. ”product managers are essentially useless here.” is a quote from an engineer. Engineers can modify specs mid-process, re-order work projects, and inject new feature ideas anytime
WHAT!!!!!!!, now whilst I openly profess that developers should take accountability for their own work, if we take this insight on face value what Facebook engineers are doing here is not Agile, it’s scary, very scary, especially if it’s pervasive across such a large workforce… I can only assume that anarchy prevails in parts… or that for every piece of code that makes it to the live environment a bucket load of wasted development goes down the drain.
I would also strongly contest the statement that “product managers are essentially useless here.” On the grounds that if people think that, and unfortunately I’ve met many engineers who do, then they don’t understand the function or purpose of Product Management.
In my experience this normally stems from an internal power struggle whereby the Product Manager believes they call the shots, and are opposed by an Engineering Manager who believes they call the shots. I’ve even heard Product Managers say, “we are the conscience of R&D” sounds great doesn’t it… erm no!!! A “we are watching you comment in any guise” says loud and clear that we don’t trust you and it kills relationships. My stern advice to these types of people on both sides would be to grow up and get over yourselves… My belief is that Product Management isn’t about the role it’s about the function, in exactly the same way that Development Management isn’t about the role it’s about the function.
However, all is not lost with Facebook, as another quote seems to support Product Management:
Product managers have a lot of independence and freedom. The key to being influential is to have really good relationships with engineering managers. Need to be technical enough not to suggest stupid ideas
I really like the good relationships piece, albeit the last bit seems to make this somewhat of a backhanded compliment. Whilst I believe there is no such thing as a stupid idea, I also believe that Product Managers and Development Managers need intimate knowledge of their customers, their platforms and their organisation… if they have this then they work really well together and you tend not to get stupid ideas.
So all that said, someone somewhere in Facebook must believe in Product Management, because get this:
Product manager to engineer ratio is roughly 1-to-7 or 1-to-10
Wow, for a company that doesn’t seem to value Product Management they sure have a lot of them on the payroll. From my experience American companies tend to have a higher ratio of Product Managers to developers than European Companies, but this seems high even by that standard.
Facebook sounds like an interesting place to work, I wonder what the holidays are like?