on Tuesday, 28 January 2014
This snippet will produce a zip archive that includes the artifacts of the subprojects.
on Monday, 20 January 2014
Here's my interpretation of the following presentation from Daniel Kahneman.

Thinking fast, and slow - Daniel Kahneman

What do you see as the key points?

System 1 is our fast thinking self, the one that makes decisions based on intuition, is influenced by emotions, uses tacit knowledge, and operates out of habit.

System 2 is the part of us that analyses situations, considers alternatives, plans for the future, and does the math. Whenever we find ourselves pausing to consider something carefully, its like switching from autopilot to manual mode; our analytical mind takes over from our intuition and works out rational choices.

What are the pros and cons of System 1 and 2?

System 1 is intuitive and moves easily, adjusting rapidly to changes. It has a lot of experience in its speciality areas and is comfortable trusting its expertise and intuition to guide actions.

System 2 analyses situations before acting. It knows that the best decisions are those based on evidence. System 2 would run experiments, gather data, and weigh the impact of various choices before making a decision.

System 1 proved its weakness with the baseball riddle. There was a moment where system 1 assumed it knew the answer but was incorrect.

System 2 is slow and less effective in agile situations.

How do you get the best out of both?

Modifying a mindset will require deliberate effort and considerable time as with breaking any habitual characteristic.

What are the challenges for you - what should you watch out for in tackling PoD challenges?

I am heavily driven by System 1 and don't often weigh the impact of various choices before making a decision. I'm hugely passionate about driving technical change, but often get blinded by my experience and sometimes provide a solution before fully understanding the problem.
What are your views on the clip?

The most interesting part of this clip was how captivating Ken was during this presentation. He used humour to get his point across instead of ranting. He commanded attention within the first few moments of being on stage and held that attention until the end.

What do you see as the key points?

School had a pretty lousy system for recognizing talented students.

Does it resonate - if so, how ?

Research has shown that talent is not something people are born with; it is something that is developed over time with hard work and diligent practice. Once students are “tracked” as low-potential, they will not be
assigned challenging classes, as Gradillas discovered. Tracking can start very early and be based on little more than a student’s command of English. (Jaime Escalante and Jack Dirmann, “The Jaime Escalante Math Program,” Journal of Negro Education59, no. 3 (Summer 1990): 407–23)

Will you do anything differently as a result of watching it?

I think its important to nurture creativity in the same way as academia. However, its important not to force one on the other unwillingly.
on Friday, 10 January 2014
This is a fun one - how many times have you been close to a deadline and the customer asks you to squeeze another feature in, the delivery manager commits to it and we're all working till midnight to make sure the feature is delivered? Well, for this one we like to use the term shoehorn - is it ironic the delivery manager got one in his xmas cracker this year?


on Thursday, 9 January 2014
This is not a smart quote, but rather something that really pisses me off!

How many times have you had a deadline nearing and you find a test failure at the last minute? Well, unfortunately for me this happens most releases. What's worse is that rather than push the date and ensure we have a good delivery - the PM decides to pull out the "Risk Acceptance" card. If you're fortunate enough not to have heard this term it basically involves asking the customer to risk accept the defect - or as I like to say, accept that we are delivering a steaming pile of turd.... what's worse is 90% of the time the customer drives the delivery, not the quality.

The real shame of all this is you can guarantee a user will raise a defect, place it in the queue, then complain that it takes 6 months to deliver.


on Wednesday, 8 January 2014
"If we dont have a target, we cant take aim. If we dont have a destination, we cant leave home or well be driving around in circles for hours. If we dont have a definition, how can we monitor or judge success"
Richard Templar, The Rules of Money and How to make it


on Tuesday, 7 January 2014

I recently watched a technical presentation from Sean O'Connor of bitly where he discussed how they achieved up to 20 deployments a day. Whilst much of their techniques are publicized and well known - one of the interesting points he raised was how they only have a single source repository. I don't think this is new; I've heard rumours that Google do the same, and have done for years.

My eyes always light up when I hear these types of stories. They're bold and clever, but I only wish I could do the same......Unfortunately, for me my business is insurance, and not technology - so getting a project manager to accept additional costs that don't immediately result in cash is difficult.

So, why do I think this is a good move?

Its much easier to track and baseline your systems when all of the source is in a single location. Modern version control systems offer a lot of flexibility in this area, and provided you have a bunch of well disciplined developers - you wont have to worry about things like commit messages.

I do still see problems.

My biggest concern would be that unless you start doing some clever tracking on sections of your source tree instead of the tree as a whole, you could be constantly hammering your CI resulting in queues. This could potentially cause long feedback cycles which is an anti-pattern of continuous delivery.
on Monday, 6 January 2014



"A good plan today is better than a perfect plan tomorrow" - General Paton

This is an interesting quote, and one I feel can also be dangerous.

We all know that in technology time is money. The longer we spend trying to make the perfect plan, the more money we stand to loose. That being said, a plan that has not been thought out well or had the best people involved can equally be as costly. All too often I've seen management take a path of least resistance only for it to turn around and bite them in the ass.
on Sunday, 5 January 2014


"Quite frankly, I'd rather weed out the people who don't start being careful early rather than late. That sounds callous,and by God, it is callous. But it's not the kind of "if you can't stand the heat, get out of the kitchen" kind of remark that some people take it for. No, it's something much more deeper: I'd rather not work with people who aren't careful. It's Darwinism in software development."
-Linus Torvalds on kernel debuggers, Linux Kernel Mailing list

I'm a huge fan of Linus, but this solidifies his position as one of the greats in my mind. There's no excuse for not being careful and I believe its every software engineers responsibility to ensure the work they have done is to a high standard. Unfortunately, I've witnessed a workplace where the strong carry the weak, and its not good. The weak are not challenged and so become unhappy, and the strong get overloaded and become unhappy. I believe its every managers responsibility to kill this kind of behaviour early and without fail.