Like many engineers I have trouble with throwing out things that are potentially useful. I’ve got several containers stuffed with computer parts, a few more laden with electronics bits and a shed full of other miscellanea that I have a hard time writing off as completely useless. Thankfully at least once a year I’ll do a clean out of the entire house and any of the real trash will get tossed at that point, meaning that most of the stuff I have actually has some potential to be used. My hoarder tendencies have also led me down the rather unexpected path of self discovery and brought insight into some of our societal norms.
One of the things I find hard to let go of are my socks. Like anyone I’d do a wash only to find myself one or two socks short, leaving me with at best mismatched pairs and at worst socks that were never to be used again. For the longest time I can remember just quietly cursing under my breath and tossing them into a pile, never to be looked at again. Then one day I accidentally chucked that entire pile of socks into my regular wash and interestingly enough I came out of it with many more pairs of socks than what came in. It was then I realised that for the most part my missing socks weren’t missing at all, they had either been misplaced or a complete pair had been sitting in the lost socks pile for however long. From then on I have continued the ritual of rifling through my lost sock drawer every time I find myself coming up short and around 75% of the time I find myself with a completed pair once again.
This experience got me thinking about how we as a society come to accept certain inevitabilities simply because the are accepted by everyone. It’s a well known “fact” that washing machines somehow eat a sock every so often and with that idea firmly implanted in your head you don’t think twice about it when you come up short in the wash every week. Of course most people are rational beings and if you really push the topic they’ll eventually cave and say that they’ve probably misplaced them somewhere but rarely do I hear of anyone trying to figure out a solution to it.
I hadn’t really considered the idea passed “Hey I can find most of my lost socks if I just keep them all” until I watched TED Talk by Kathryn Schulz titled On Being Wrong:
At its heart the idea that a washing machine can magically disappear socks is wrong, they’re simply not designed that way. Realistically the blame lies with us for having misplaced them but admitting that to ourselves is much harder than laying blame on some external, uncontrollable factor. We’re much more comfortable believing we’re right about the washing machines working against us than taking that leap into thinking we’re wrong and working out a solution. Taking this one step further its easy to see when people become trapped in these notions that they believe are right when objectively they’re completely wrong and there’s usually a path to follow to remedy it.
Just like my Straight Line Theory before it the Lost Sock Theory came about not through hours of philosophical study but just a realisation through going about my normal, everyday life. Perhaps its my engineering bent that causes me to seek out problems like this and work on their solutions as I often find myself seeing analogies in everyday life to philosophical ideals. Indeed it is my hope that in sharing these ideas with you that you too will embark on a similar path of self discovery, or at least find some of those socks that have gone walk about.
I was a beautifully warm night in late December down in Jervis Bay. My friends and I had rented a holiday house for the New Years weekend and we had spent most of the day drinking and soaking in the sun, our professional lives a million miles away. We had been enjoying all manner of activities from annoying our significant others with 4 hour bouts of Magic: The Gathering to spending hours talking on whatever subject crossed our minds. Late into the evening, in a booze fueled conversation (only on my end, mind you), we got onto the subject of Agile development methodologies and almost instantly I jumped on the negative bandwagon, something that drew the ire of one my good mates.
You see I’m a fan of more traditional development methodologies, or at least what I thought were traditional ideas. You see I began my software development career back in 2004, 3 years after the Agile Manifesto was brought into existence. Many of the programming methodologies I was taught back then centered around iterative and incremental methods and using them in our projects seemed to fit the bill quite well. There was some talk of the newer agile methods but most of it was written off as being experimentation and my professional experience as a software developer mirrored this.
My viewpoint in that boozy conversation was that Agile methodologies were a house of cards, beautiful and seemingly robust if there’s no external factors on them. This hinged heavily on the idea that some of the core Agile ideals (scrum, pair programming and it’s inherit inability to document well) are detrimental in an environment with skilled programmers. The research done seems to support this however it also shows that there are significant benefits for average programmers, which you are more likely to encounter. I do consider myself to be a decently skilled programmer (how anyone can be called a programmer and still fail FizzBuzz is beyond me) which is probably why I saw Agile as being more of a detriment to my ability to write good code.
After taking a step back however, I realised I was more agile than I previously thought.
There are two methodologies I use when programming that are included in the Agile manifesto. The first of these is Extreme Programming which underpins the idea of “release early release often”, something I consider to be necessary to produce good working code. Even though I don’t announce it on this blog every time I get a new feature working I push it straight into product to see how it fairs in the real world. I also carry with me a copy of the latest iPhone client for testing in the wild to make sure the program will function as expected once its deployed. Whilst I don’t yet have any customers other than myself to get feedback from it still keeps me in the mindset of making sure whatever I produce is workable and viable.
The second is Feature Driven Development, a methodology I believe that goes hand in hand with Extreme Programming. I usually have a notepad filled with feature ideas sitting in front of me and when I get time to code I’ll pick one of them and set about getting it implemented. This helps in keeping me from being distracted from pursuing too many goals at once, making sure that they can all be completed within a certain time frame. Since I’m often coding on the weekends I’ll usually aim to get at least one feature implemented per weekend, accelerating towards multiple features per weekend as the project approaches maturity.
Whilst I haven’t yet formally conceded to my friend that Agile has its merits (you can take this post as such, Eamon ;)) after doing my research into what actually constitutes an Agile methodology I was surprised to find how much in common I shared with them. Since I’m only programming on my own at the moment many of the methods don’t apply but I can’t honestly say now that when I go about forming a team that I won’t consider using all of the Agile Manifesto to start off with. I still have my reservations about it for large scale solutions, but for startups and small teams I’m beginning to think it could be quite valuable. Heck it might even be the only viable solution for small scale enterprises.
Man I hate being wrong sometimes.