The first is the assumption that you could create something with the same quality level as the existing solution in the stated number of days; most likely you will be lucky to have a functional prototype with minimal functionality.  It is highly unlikely that you will have produced something that is as well tested, optimised and documented as the existing solution.

Secondly, as developers writing software which we intend to sell to users to pay the bills, we should be focused on the core features that define our product.  It is these core features we should be pouring our energy and time into designing, building and testing.  Developing alternatives to existing technology that is not in our core feature set is a waste of valuable time and energy and will not differentiate our product from that of our competitors.

We should instead be looking to leverage as many established technologies or components as possible when developing new systems as this lets us spend most of our time where it matters most on our core differentiating features.

“The perfect is the enemy of the good.” – Voltaire.

The pursuit of perfection is counter to the pursuit of a working product.  To build the perfect product takes time: lots of time, more time than most companies can afford.  To produce a good enough product takes significantly less time which increases the chances of actually getting it to market, making a profit and surviving long enough as a business to make a second improved iteration of the product.

“For many events, roughly 80% of the effects come from 20% of the causes.” – Pareto Principle.

According to the Pareto Principle (also known as the 80-20 rule) the first eighty percent of the output (effects) comes from only twenty percent of the work (causes).  This eighty percent output is the ‘good enough’ product, therefore to produce the perfect product takes five times as long as the merely good enough.

The question you should ask is ‘Do we need perfection?’.  I suspect unless you are programming medical, industrial or military equipment or software the answer is likely to be ‘No’.

Hat tip to Cliff for pointing this video out to me.

Consider yourself warned if you are using an RSS reader!

Update: I didn’t move the RSS feeds in the end.

Despite being almost an hour long this is a very insightful video that I’d recommend any Software Engineer watches. I find it fascinating that so many programmers want to erase their perceived (or actual) mistakes in source control systems. I guess everyone secretly wants to be the perfect super programmer. However I typically learn more from my failures than my successes: perhaps it is natural to be more introspective about failure than success?

If you find the title or video too pretentious then the question and answers session (around 42:40) is still quite interesting as the presenters get grilled by the audience.

Here is a little script to change a mac’s desktop wallpaper to the file specified as the first argument of the script:

import subprocess,sys,os

# Raw apple script
Script = """/usr/bin/osascript<<END
tell application "Finder"
set desktop picture to POSIX file "%s"
end tell
END"""

# get the file name which is the first argument passed to this script
filename = sys.argv[1] 

# run the apple script inserting the filename
subprocess.Popen(Script%filename,shell=True)

Or using the nifty appscript module for python:

import sys
from appscript import app, mactypes

# get the file name which is the first argument passed to this script
fileName = sys.argv[1]

# use the appscript module to change the desktop wallpaper
app('Finder').desktop_picture.set(mactypes.File(fileName))

The more I use Python the more I like it.  I used to think Python was at a similar level to C# in terms of how high a level a programming language it is.  After using Python for a bit I now realise that Python is a higher level programming language than C#.  Out of the languages I use reguarally it would seem that Python is the highest level language followed by C# then C++ and finally C.

The awareness of what I don’t know helps keep me humble, humility makes working as part of a team easier:  as there is no pressure to have to know everything or not make mistakes.  In fact I tend to expect to make mistakes more now than when I first started programming.  Perhaps it is the years I have spent shipping games that finally proved to me that I too write software that contains bugs (the horror!).

I remember a professor at university telling me that the main difference between a professor and a first year student working on a programming task is that the student will start working immediately and also start making mistakes immediately, the professor will think for a while then start work and start making mistakes as well.  I have found this observation to have a surprising amount of truth in it,:whether it is at university, work or even sports.

Mistakes are healthy: without mistakes we would have not reason to every really think about what we are doing e.g. why didn’t that work?  By continually pushing (or stretching) ourselves to failure we discover our boundaries, once we know where are our boundaries are we can then start to work on pushing them further.  However if we always play it safe and never push ourselves (which can be scary) we will never discover our boundaries which makes improvement much harder and also makes approaching those boundaries harder due to fear (typically of loss of control).

An excellent example of this is people learning to ice skate: young children will tend to fling themselves around the rink with wild abandon falling all over the place (as failure is expected but irrelevant due to lack of social stigma), yet adult beginners typically skate in a much more conservative fashion taking less risks (as there is social stigma against falling as an adult: falling is seen as failure).  Interestingly when observing ice hockey players, it is noticeable that those with the best skating technique are typically falling more than the other the non-beginner players on the ice, as they do not fear falling.

As most of us are not engaged in high risk activities on a daily basis we can easily begin to revise how we think about failure and to learn to embrace it as a powerful tool for self improvement.

This balance can be seen in most projects involving more than a couple of participants.  A team’s experience distribution can typically be visualised as a pyramid with the most experienced individuals at the top of the pyramid and the most numerous and least experienced group of individuals at the bottom.  There is the occasional team where the experience pyramid is inverted but I have yet to have the opportunity to work with such a group.

The experience composition of a typical team usually works quite well, with the more experienced members directing those that are less experienced than them.  This helps to explain why the more experienced you become the more time you seem to spend in meetings planning, discussing and thinking about the design of the product.

The breakdown of the project tasks based on individual experience levels also means that each individual should be supplied with tasks that are mostly within their capabilities.  Some stretch tasks should also be set (with sufficient support from more experienced team members) to ensure each individual continues to develop their skills.  This should mean that the tasks you work on should be within your capabilities and as your capabilities increase so should the complexity of the tasks you are set, to prevent stagnation.

It should be noted that if an individual fails at a task then their next task should be something that is well within their capabilities. To do otherwise is to risk a loss of confidence, as multiple failures in a row can seriously undermine an individual’s confidence and ability (see negative reinforcement).  This is why most modern coaches will not allow their athletes to finish a training session with a failure.

Tasks that stretch or challenge you as an individual are a good thing but they should not be forced upon you and they should not be chained together, some respite is required between challenges.  More experienced team members are an essential resource to those undertaking stretch tasks due to the advice and moral support they can offer.

• What did you do yesterday?
• What are you doing today?
• Are you blocked by anything?

The first type is the concise answer which is in my mind the ideal answer, one that provides the necessary information in the minimum amount of time without any excess fluff.

The other type  is the rambling answer that attempts to contextualise itself but really just drowns in excess information.  I have even witnessed people using the questions as a chance to rant at their (effectively) captive audience or as a chance to start discussion.  Discussion is a good thing but not during a daily stand-up with the whole team listening into to a few individuals discuss something, that gets old fast.  Have your discussion after the meeting to spare those that are not required.

These two different styles of answers can make or break the scrum experience for the participants: too many ramblers in a stand-up meeting can make the daily meetings feel like a sentence instead of a chance to find out what everyone else is doing.  The purpose of these daily stand-up meetings is to: update the rest of your team on your state: what you did yesterday, what you are working on today and any work blocking issues you are experiencing.

The goal is team wide visibility into the state of development and the corner stone of it is quick efficient short daily meetings.  So keep those answers as concise as possible, this will require thought on your part to compose your answers before its your turn but your co-workers will appreciate it!