Wednesday, May 14

HIring Staff

This is a skill that most people believe they can do without training and yet most hiring managers do not get the results they desire.

There are studies that show that unstructured interviews do worse than chance ( most interviewers would be better off tossing a coin). The authors of these studies generally then go on to recommend some form of structured interviewing technique.

The main advice I would add would be to keep metrics on the success of your hiring process, continually refine the process based on those metrics and understand the needs of the role you are hiring for.

I have been collecting metrics and statistics on not only my hiring decisions but my co-workers hiring decisions for 14 years and my personal experience is in total agreement with the scientific literature. Hiring is easy to get wrong and it is rare that hiring managers get any training.

The biggest mistakes I see are :-

Mistake 1: Trying to hire someone who would be good for any role - you need to start from a good understanding of the day to day needs of the role you are hiring for. Concentrating on the most common and most important and most error prone tasks.

Mistake 2: Choosing between soft and hard skills - The employee needs to both be able to do the job AND to work with others. Deciding based on one half of the equation and thinking you will train them up on the other is the road to heartbreak.

Mistake 3: Talking and not listening. If there is information they must know encourage them to ask questions. Their questions will tell you something. You talking will not.

Mistake 4: Assessing based on the type of questions you were assessed on at school. You are not interviewing them for the position of university student. The assessment needs to be as close to the real life tasks and behaviours the role requires as possible. 

Mistake 5: Assessing on too many criteria - The passing grade for each criteria will be lowered and the time assessing fit for each criteria will be shortened if you try to fit to many in. Prioritise, Prioritise, Prioritise.

I usually go for a technical test that is realistic and as practical as possible for the hard skill component. In theory their is no difference between practise but in practise there is. 

Plus Behavioural Interviewing questions for the soft skills.

Failing on either the hard skills or soft skills is a fail.

I prefer depth to breadth. Hauling them over the coals on a few questions rather than let them bluff their way through a dozen. Remember in school how easy it was to bluff your teacher? Alternatively do you help your children with their homework and watch them bluff their way through? Be tough and drill down into the details.

Common mistakes when capturing the needs of the role :-
  • Recency Bias. People overestimate the frequency of events that are recent.
  • Capturing everything. Some activities are more important than others. Some are easier to learn. Some are more frequent than others. Prioritise.
  • Should do vs actually do. People will report that they are behaving the way they think they should behave rather than what they are actually doing. Sometimes their actual behaviour is more practical and productive than the rule they think they should be following. Either way encourage people to reflect on their experiences.
The biggest mistake of all - Thinking that you can not do better.

Sunday, March 18

Created an interactive book for new readers on the iPhone / iPad

I have released my first iOS App A is for Ant

Designing and implementing this App has  been a fun exercise that has allowed me to get up to speed on Objective C and to explore a few ideas I have had about educational software.

For $0.99 you get:

A beginner reader story book (with easy, medium, and  hard versions) plus 13 games.
Easy version of the Story
Screen shots is from version 1.6.4 and the video is from version 1.4.5

Medium version of the Story
Hard version of the Story

Colour in Drawing

Solve jigsaws 
based on each page of the story
Matching game stimulates memory
 and letter recognition
Sound matching game promotes listening skills 
and phonemic awareness
Tracing game 
to help practice writing letters

Picture and Sound Game promotes listening
 and letter recognition. 

Word finding game promotes spelling
 and word recognition

Picture game that promotes creativity
Word Matching Game 

Match words with sounds

Match words with pictures
Sliding Puzzle
Flash Cards

What it looks like on an iPhone (YouTube Video)

What it looks like on an iPad (YouTube Video)

Apple taking a while to review the app this time.

Tuesday, October 4

Smoothing the rough edges from life

f you are like me, if you are like most people; you are plagued by a slew of irritations, annoyances and frustrations throughout your day.

You ignore the frustration as you find workarounds and coping mechanism to overcome the road blocks placed in your way, in order to achieve your immediate goals.

Instead of ignoring these irritations I urge you to treat them as important signals that show where you can improve your life: that you isolate each of these annoyances and, remove them permanently from your life by applying a complete solution to the root cause of the problem, instead of engineering temporary workarounds to alleviate the symptoms. In this way your life is gradually improving as some of those repetitive issues stop reoccurring.

One technique that I have found personally useful is asking why five times. It has been made famous by Toyota which introduced it in the 1970's. Toyota credits the 5 why's technique with accelerating their process improvements.

As an example of how this can be used, many years ago I found that I was constantly tired, pushed to the point of exhaustion. I asked myself,
  • 1st Why "Why was I tired?" 
    • 1st answer "I was stressed"
  • 2nd Why "Why was I stressed?" 
    • 2nd answer "I was not sleeping well"
  • 3rd Why "Why was I not sleeping well?" 
    • 3rd answer "I was stressed, also I was exercising less than I used to"
  • 4th Why "Why was I was exercising less than I used to?" 
    • 4th answer "I had fallen out of the habit"
  • 5th Why "Why had I fallen out of the habit of exercising" 
    • 5th answer "I did not have I regular time scheduled time for exercise"
If you ask the 5 whys at a different time you often come up with different answers. Some people think this is a weakness, personally I think it is a strength.
Let's ask the 5 whys a couple more times.
  • 1st Why "Why was I tired?" 
    • 1st answer "I was stressed"
  • 2nd Why "Why was I stressed?" 
    • 2nd answer ""I had too much to do"
  • 3rd Why "Why did I have too much to do?" 
    • 3rd answer "I was not prioritizing my task enough"
  • 4th Why "Why was I not prioritizing my task enough?"
    • 4th answer "Too many the tasks were rated as important"
  • 5th Why "Why were too many the tasks were rated as important "
    • 5th answer ""I had trouble letting go and accepting that some tasks would have to be done latter"
And again.
  • 1st Why "Why was I tired?" 
    • 1st answer "I was stressed"
  • 2nd Why "Why was I stressed?" 
    • 2nd answer ""I had too much to do"
  • 3rd Why "Why did I have too much to do?" 
    • 3rd answer "I said yes too often when I should have said no"
  • 4th Why "Why was I not saying no?
    • 4th answer "I did not want to disappoint people"
  • 5th Why "Why did I not want to disappoint other people"
    • 5th answer "I needed to tell myself that it was better to disappoint them now rather that rise their expectations then disappoint them latter.
I turned these why's into solutions. I started seeing improvement after I
  • started exercising at the same time every morning
  • made sure that only limited number of tasks were highest priority and
  • I only accept new tasks when I had either completed old tasks or downgraded old tasks in priority.

You do not have to be Toyota to benefit from root cause analysis. Anyone can do it. When faced with a repeated annoyance, just ask why five times.

Thursday, August 11

Online Resources for Software Developers

I facilitated a brown bag lunch for the company's developers today. The topic for the brown bag was online resources that are useful for software developer in their work. We came up with a list of which I have recorded in the following section. It is far from a comprehensive list, however it contains some interesting and useful resources.

Code Katas and Koan

These are exercises to help you to learn elements and features of programming languages.
Examples as follows


These are Internet radio shows often in either a interview style or a panel discussion style
Examples as follows>


These are screen capture videos of people demonstrating technology.
Examples as follows


These are Internet TV shows often in a interview style.
Examples as follows
  • FLOSS Weekly about open source software
  • InfoQ Tracking change and innovation in the enterprise software development community


MOOC stands for a Massive Open Online Course.
Examples as follows.


These are thread based discussion groups often centred around a particular technology
Often better for answering questions if the technology is niche.
Examples as follows

Question and Answer Sites

The members of these sites help each other by asking and answering questions
Often better for answering questions if the technology is common.
Examples as follows
  • StackOverflowis a programming Q&A site that’s free. 
  • Anyone can ask, answer, or edit questions on  Quora
  • ServerFault is a Q&A site for system administrators and desktop support professionals that’s free.


Rants, tips and tricks from those in the know.
Examples as follows

Events and Meetups

These sites help you find out what is happening in Melbourne

Sample Code and Code Projects

These sites give a more in depth treatment of problems
Examples as follows


  • The Wayback Machine. Have a broken link? An important resource that has disappeared? Go back in time and find it. 
Does anyone have some useful online resource that they would like to through into the mix?

Wednesday, April 13

Two Scrum Events this April

Yesterdays Scrum Event went very well with a record 70 people turning up. Craig did a splendid job of adjusting this planned talk on the fly to cope with the large number of Scrum beginners in the audience.

Wednesday 13th April 2011
Topic: Understanding and working with the uncertainty at the beginning of a project.
Craig will be using the use the backlog of concerns, problems and topics that the Scrum SIG members have constructed in previous meeting as an example of a project startup.
He will also facilitate a series of small work-group discussions that will highlight the difficulties and possible solutions of understanding and working with the uncertainty at the beginning of a project.

Wednesday 27th April 2011
Topic: Agile Business Intelligence and Data Warehousing by Ralph Hughes
While Agile approaches for the development of transaction- and data capture-applications have been around since before the publication of the Agile Manifesto  10 years ago, employing Agile methods such as Scrum and XP to build large, data-driven systems such as data warehouses is new.  New, but luckily just as effective. This briefing will provide an overview of how agile concepts can be applied to data warehousing and business intelligence projects to significantly shorten the development cycle from traditional waterfall-based methods.

Friday, October 22

Mob SIG Event on Mon 25th October

indows Phone 7 - has Microsoft got mobile right this time?
This is Microsoft's latest approach at the mobile phone market. It is a drastic shift away from their previous attempts at trying to bring Windows XP feel into the palm of your hand.

The entire WP7 experience has been standardised to follow the "Metro" theme which embraces concepts such as discoverability, content over chrome, and touch as the primary input (without the fiddly stylus).

Join David Burela and Jarred Sargent as they give an overview of what the Windows Phone 7 platform is and how to get started with it.
David will take us through a demonstration of the phone platform and how it differs from previous Windows Mobile phones. He will also talk about the UI design considerations of the "Metro" theme that permeates through the entire phone.
Jarred Sargent will give an overview of what it takes to easily build applications for the phone and will demonstrate some easy hello world applications and his experiences as a developer.
For more details

Wednesday, September 29

Endless Iterations

S ome time ago I sat in on two iteration meetings for an adjacent team. There was a possibility that I would join the team on a part time basis, a possibility that never eventuated.

The project they were working on was fairly far along. They claimed they were using extreme programming, they claimed that they were agile, they claimed that they were using two week iterations. However
  • The team were not asked to commit to completing the tasks scheduled the iteration planning meeting.
  • The instead of scheduling based on the historical progress of the team in previous iterations the capacity of the iteration is simply assumed to be 80 hours times the number of developers.
  • Deflects arising from tasks failing acceptance tests were saved for the end of the release, leading to a final test and fix phase.
  • Instead of using rolling wave planning and progressive elaboration all stories were assigned to an iteration during the release planning phase.
-->There was no ceremony or activity to close the iteration (no demonstration of completed functionality, no interim retrospective), the uncompleted tasks were just moved to the next iteration and the new iteration planning meeting commenced.
There was no learning in this process. Any mistakes made during one iteration were repeated during the next. Any lessons learned forgotten in the mad dash to grind out tasks.

The point of time boxing is to
  •  provide risk management 
  •  limit the amount of time consumed by a task.
  •  habituate the team to meet deadlines.
  •  prevent endless chasing of sunk costs.
None of these objectives were being met. 
They were continually starting but never finishing

Monday, September 27

Sticky Code

was working with though some legacy code when I discovered that the original coder had
  • avoided magic numbers by using Macros which was good
  • defined the Macros in multiple places which was bad
The Root Cause

I started asking myself "why" questions in order to discover the reasons behind this failure.

Question: Why has this duplication occurred?
Answer: The original location of the definition was poorly chosen and subsequent coders where reluctant to move the definition.

Question: Why were coders reluctant to move the definition?
Answer: Because to move code you need to delete it from its original location.

Question: Why are coders reluctant to delete code?
Answer: Either :-
  • they do not have source control
  • their source control software does not clean up after itself (files deleted in the repository are not delete in the workspace)
  • or they do not have decent code coverage.
The importance of moving definitions and implementation between different modules and libraries.
If code sticks to its original location and is not moved then over time you will find that you will get duplications or circular dependencies. Usually both.