Leaving your Laptop at Home
I’m traveling in the US this week to go to the Microsoft Convergence 2012 conference in Houston and then to Las Vegas to meet some vendors. This is the first time I have consciously travelled without my laptop on a business trip, and instead, brought my iPhone and iPad.
It’s day 3 and I don’t miss my laptop one bit!
It’s quite amazing what can be achieved with just an iPad. Apart from answering emails, I have been taking notes at the conference, both typed and handwritten using my new Bamboo Stylus that I bought here yesterday. I have been surfing the web, working on design documents (scribbling architecture out on my iPad) and have even started working on a presentation that I’d didn’t finish back […]
The Wonder of Connections of Social Networks
I recently attended a presentation where an interestying graphic was presented. It was a map of the world where each? of the lines represented a social connection of significance. The darker the line, the more significant the connection.
But there were some interesting visualisations here;
Firstly is the obvious dominace of Nth America & Europe
But so is the lack of China, except for Beijing
Also the significance of Sth America and India as well as Sth East Asia
Quite an interesting insight into what is impacting social networking today, and justifiable why Facebook is the 3rd largest country on Earth now!
Getting to “Done”
How do you know when you are finished? This can be quite difficult.
You are working on something and you need to get that deliverable finished; a document, a piece of code, a project, a building or a Lego creation. But when do you now you are done?
This can be extra hard if you consider yourself to be a perfectionist!
There are a four rules that I would suggest to follow;
Visualize “done” from the start. Before you get started define what getting it done means. What is that end state, and ask yourself the question “could I get to ‘done’ earlier?”, “what compromises can I make to get finished sooner?”
Use tools to test being finished. Test Driven Development does this well. Coders are encouraged to write […]
Understanding Technical Debt
Technical Debt is a concept that was introduced in Agile project delivery as a way to understand how to make better software development decisions. I think it’s just as relevant in any technology based decisions.
So much so that I propose that there is a mathematical formula to explain it.
The first part of the equation describes that the more strategic decisions you make and less tactical, the less it will influence the end result (smaller number). But you need to understand that time makes technical debt worse, so that needs to be added as a multipler.
But what is technical debt?
We are very familiar with the concept of borrowing money to buy a car or a house. In a […]
My First (well overdue) Post from Echo!!
2012 has started and so has my 5th month at Echo Entertainment, and I must admit, I’m having a ball!!!
For those that don’t know, Echo Entertainment was the result of a demerger of the casino business in TabCorp. We own & operate 4 casinos in Australia; The Star in Sydney, Jupiters on the Gold Coast, Treasury in Brisbane & Jupiters in Townsville. Although our core business is casinos and everything gaming related, we as IT, pretty much run everything; casino systems, hotel systems, restaurant, point of sale and even car parks. This is what makes it fun, you have so much variety.
The other thing that I totally love about this place is how we behave. For a public company with over […]
Visitor Retention: Infographic
Came across this really interesting infographic about customer retention. The focus is on gaming, but at a high level, the key points are critical and most often forgotten.
Source: From the great mixpanel blog on gaming, http://blog.mixpanel.com/2011/09/16/infographic-what-you-should-know-about-visitor-retention/
Architectural Deck – A great example
The other day I talked about the concept of an Architectural deck to describe a blueprint for making decisions. And there is a great example of a well architected solution that we can test the hypothesis of the Architectural Deck against – The Human Body.
Just a reminder, there are 3 layers to our deck;
Foundational – The core and basis that we have to work with
Functional – The tried and tested solutions
Innovational – The things that make the solution different or special
If we try and correlate this to the human body, or more specifically a component of the human body such as the legs. This may be described in the following way;
Foundational
If we look at the human legs, there are some very specific core capabilities that […]
The Architecture Deck – An Introduction
Enterprise Architecture is an important practice that has come out in the last 10 years. To me, its an attempt at the ‘grand unified theory‘ in business & technology. And of the most important models within Enterprise Architecture is to derive the Business Architecture which sits at the top of this tree. After discussing this with a number of people, I have got some traction to a concept I have been talking about for a while that I call it the “Architecture Deck”.
The Architecture Deck is a framework to try and conceptualise the layers of an architecture that helps make business decisions. What is great about this deck is that can quite […]
Startups: The importance of the Founder Chemistry
I have been involved in some interesting conversations recently, where technical founders are struggling to find business co-founders and vice versa. Additionally, there seems to be the search for the holy grail of what defines an effective founder. Everything from age analysis, to combinations and structures. But I wonder if there is a magic bullet theory that could be derived here?
In my limited experience, these are the elements that I found critically important.
1) A respected and aligned knowledge base
Maybe unusual to be at the top of my list, but I believe this is one of the culprits for many […]
Don’t assume the most obvious problem is THE problem
When solving a problem, we come across what seems the most obvious issue, and fix it. We then assume that the problem has gone. But there are many instances when there are a deeper set of problems that don’t appear so obvious.
Take for example debugging code. When it is determined that there is a bug, we may go through the code and find something blindingly obvious to us that is the problem. We may then do the rights things; write a test that checks for this, fails and then we fix the bug and push to be deployed. Woila! Problem fixed! But is it?
Many a time, this assumption can get us unstuck. We should actually check whether there was more to the problem. This […]
