Who is looking at your code?

We’re software developers and we take our art form seriously.  Our palette is the editor to which we lay down our beautifully crafted code.   How we name variables, how we shape methods and how we format code, leaves its own unique DNA sequence that can quickly identify the owner.   Even after running code through a standardized formatter, the author is not immune from detection.

Software development has always been a group effort.   If you write code that is never seen by another pair of eyes, then you aren’t really a software developer.  A hacker at best maybe.  The worse thing you could ever find yourself in is being the only developer in the company.

I bet some of you are thinking that sounds wonderful.  No one telling what to code, how to code, silly release procedures having to be followed, tickets to be created/updated, what language to use, the list can go on.   However, how would you know if you are any good?   How would you know if what you are creating is top quality?

The simple answer is you wouldn’t.   Sure you can read as many forums, mailing lists and books on coding as you wish, but since no one is forcing you to follow any of the process, no one is keeping you in check and challenging your ideas and thoughts.

Developing software is like having sex – best enjoyed in at least a pair, if not more, but never a solo affair.

The best developers in the world have that one person in their lives that they can go do and have them say “yeah, that is not bad, but what if…” and leave you wondering if the solution you just designed was as good as you thought it was when you first presented it.

Challenges is what makes our designs great.  A challenge will ask the questions we never dared to ask or even thought to ask.  A challenge will let you tighten up areas that you assumed wouldn’t need any explanation (“I mean that section is obvious isn’t it?”).

If you write code that is never seen by another pair of eyes, then you aren’t really a software developer.

A challenge doesn’t necessarily have to be a complete interrogation under the spotlight.  It can be as passive as a code review with a simple question “why did you do it this way?”.   That question can quieten even the most hardened developer as they try to recall the reason they have constructed a method/loop like that because while it made complete sense at 2am in the midst of a caffeine induced coding marathon, 3 weeks later, in the cold sober light of day, it makes little sense now.   What is even more baffling, is that it works!

Your code needs eyes.  The more eyes you can get to look at it the better it will be.  Who knows, you may have got it right it from scratch, but at least with more eyes looking at it, you will have that validation.

A good code review isn’t pouring over single line of code, determining if they have used the right method or API call – an experienced developer will be able to see that quickly with a quick glance.   It isn’t about how the code looks in the editor either, chances are you should be all using a standard code formatting template that brings everyone’s code to look’n’feel the same.

A good code review is making sure all the components are put together in a logical manner that is maintainable, readable and flexible enough for the future requirements that may be made of the component under review.   In most cases, code reviews will always result in code being removed, rarely added, due to the fact that developers have a natural tendency to over complicate instead of over simplify.

The next time you write a piece of code, or design a system, invite someone over to take a look at it and let you walk them through your thinking to see if they agree with your conclusion.   If they agree with you, then thank them kindly and ask them to move along.  You want to find that person that will disagree with you on at least one point.

Once you find that person, keep them close, they will make you a better developer.

How’s your Software Insurance Policy?

Ask any software developer a list of things they dislike doing the most and chances are testing and documentation will make the top 2.

Testing is one of those necessary evils that every software developer must wrestle with.  Software developers have a unique confidence (read arrogance) that the code they write is error free and production ready as soon as their fingers leave the keyboard.  We don’t need to test – it is perfect as it is!

Wouldn’t the world be a nicer place if that was the case? Sadly such hubris and confidence has killed many projects success and dented many a teams or individuals reputation.

There are many types of testing available, but the one developers are usually most familiar with is that of unit testing.   This is when you take a small piece of code/method/class and subject it to many different inputs observing its behavior and output for anything out of the ordinary.

There are two major trains of thought when it comes to unit testing; test-driven development versus post-development testing.   It doesn’t really matter which one that is employed, but one thing is for sure, we never can do enough of it.

Unit testing is a bit like buying fire insurance.  Fire insurance is there to help pick up the pieces when the worst happens and your house catches on fire.   The vast majority of people will never experience a fire in their time and as tempting as it is to stop buying the insurance, we still can’t bring ourselves from canceling the policy.  Yet should fire strike, we may find that we are woefully under insured.

Unit testing is like that. You can go for long periods of time, with your unit tests never highlighting any problem.  You get lulled into a false sense of security, that the code you are writing is perfect and the sprinkling of testing you are doing is merely confirming that.  Of course, there is the huge possibility that your test code is not as thorough as it could be.

But every so often, our insurance policy kicks in.  And when it does, we feel a joy and sense of occasion that all our efforts and work in the past have paid off.  We’ve been saved.

A unit test, is coding for the future – you hope your unit test will never fail, but should it, then you have just saved yourself from a huge and potentially embarrassing problem.

Image and video hosting by HilariousGIFs.com

Unit testing is one of the most important insurance policies a developer can purchase and while tempting as it is to let your payments slip, one day you will wish you had paid more into the insurance fund.

“Scotch: The Whisky of Scotland in Fact and Story” by Robert Bruce Lockhart

If you are mildly interested in the history of Scottish whisky then you can go no wrong with this book written by Sir Robert Bruce Lockhart.

Lockhart, died 20 years ago, and was from a completely different era with a word play that you would expect from the upper-class snobbish of an old boy that can only bring a smile to your face.   To give you a hint of how he sees the world, here is an excerpt that had me in titters …

  • On my way back from a fishing expedition, my hired car broke down outside a tiny cottage on the Grantown-Tomintoul road. Before the door stood a tall spare man who lent my driver a bicycle and, while the driver went off to get another car, I talked with the man.

Creeps up on you doesn’t it?  Written as if he had broken down while driving around the roads of the Scottish Highlands, but no, it wasn’t he that was put out, but his driver!  Classic.

This attitude is to be embraced and enriches the journey Lockhart takes us on as he charts the history of whisky from its humbling beginnings in the Highlands to the international drink of choice it has become today.

Lockhart takes a look at the make up and personality of the expert whisky drinker with some classic lines:

  • ‘One whisky is all right, two is too much, and three is too few.’ Two makes you want another and after three you can’t stop.
  • I would define the average whisky drinker’s attitude towards his favourite drink as a wobble between what he really likes and what he thinks he ought to like.

  • Scotch malt is a he-man’s drink and goes with hard toil and strenuous exercise in the open air. Blended Scotch is for weaker stomachs.

He takes us through the process of how whisky is made and highlights some interesting facts that the average drinker is probably not aware of.

  • Malt whisky, which emerges from the spirit still as clear as gin, has to be matured in order to rid it of impurities and to improve its flavour.

  • Sherry in the wood which gave the malt whisky its rich amber colour, and depending on the size of the cask, malt whisky is at its best between the ages of eight and 15 years.

  • Nowadays, in order to obtain standardisation of colour the big whisky firms who control the trade use a solution of caramel

  • Contrary to a widespread belief, whisky does not improve in the bottle.

  • The use of the sherry cask and the consequent colouring of the whisky were probably accidental, and whatever the advertising wizards may say, the colouring in itself has only a small effect on the flavour.

Another interesting tale he talks to us about is the consumption of whisky in England, Ireland and Scotland … showing the Scottish know how to drink (which still holds by the way in 2013!).

  • In 1842 England with a population of 15,000,000 consumed 7,956,054 gallons of spirit (mainly brandy, gin and rum) or approximately half a gallon per mouth of population.

    Ireland with a population of just over 8,000,000 consumed 5,290,650 gallons; roughly two-thirds of a gallon per mouth.

    Scotland with a population of 3,620,184 drank 5,595,186 gallons, mostly whisky, or more than two gallons per mouth of population!

The book is packed full of interesting tidbits, including the differences with American whiskey (note the extra ‘e’) and how he believes that it shouldn’t be called anything near whisky as it is not made from barley but instead corn or rye/grain.   Now that said, Lockhart is so loyal to the Highland single malt that he barely recognizes the Lowlands as officially in Scotland (and he considers Edinburgh to be in the Lowlands!).

I loved this book and thoroughly enjoyed the tone, including the very detailed account of the Burns Supper in Dumfries as he toured the infamous Globe Inn and local spots.

If you enjoy a good single malt (here is where I do agree with him, blended malts are not to be even considered whisky) then this book will have you tittering and give you an insight into that beautiful, smooth, silky liquid that you hold in your hand.

“Scotch: The Whisky of Scotland in Fact and Story” by Robert Bruce Lockhart

“Made to Stick: Why Some Ideas Survive and Others Die” by Chip Heath, Dan Heath

This book was recommended by my trusted colleague, Stefan Bauer, as a bit of light reading over the weekend.  Weighing in at only 291 pages, it was a book that proved very hard to put down once started.

The authors take a look at what it takes to make ideas and messages resonate and stick with people.   By using lots of case studies they illustrate just how easy it is to manipulate people’s minds by simply rearranging words and challenging the conventional wisdom of what you would think should work.

An example they use is getting people to choose a given outcome.  First they present 2 choices, and then run the study again and offer 3 choices.

Suppose, instead, you had been given three choices: 1. Attend the lecture. 2. Go to the library and study. 3. Watch a foreign film that you’ve been wanting to see. Does your answer differ? Remarkably, when a different group of students were given the three choices, 40 percent decided to study—double the number who did before. Giving students two good alternatives to studying, rather than one, paradoxically makes them less likely to choose either. This behavior isn’t “rational,” but it is human.

Another idea they discuss in depth is how we tend to over indulge our audience with facts and figures, we tend to give too much information.   It is a natural effect but the key is to be aware of it and break it.

People are tempted to tell you everything, with perfect accuracy, right up front, when they should be giving you just enough info to be useful, then a little more, then a little more


Becoming an expert in something means that we become more and more fascinated by nuance and complexity. That’s when the Curse of Knowledge kicks in, and we start to forget what it’s like not to know what we know.


If you want your ideas to be stickier, you’ve got to break someone’s guessing machine and then fix it

One of the most fascinating things that the authors illustrated was how positive thinking wasn’t always the best way of making us better.  In fact they argue that replaying every single step that laid up to the poor outcome should be re-imagined.  The idea being that you need to be aware of the conditions so you can recognize the signs and take steps to avoid them.

It turns out that a positive mental attitude isn’t quite enough to get the job done. Maybe financial gurus shouldn’t be telling us to imagine that we’re filthy rich; instead, they should be telling us to replay the steps that led to our being poor.

There are lots of great examples of how urban myths and proverbs stick in our minds.  How have those ideas lasted thousands of years and makes people want to repeat them.  They pick apart the process and how you can manage that with the messages you are trying to sell.

I have read a number of books like this and it still amazes me how we think we have “free will”.  Humans really are just programmable bots and if you know the right words to use you can get them thinking whatever it is you want for a particular subject.

While this book won’t give you the secret code, it will help you hone your message and make your ideas stick with people for a bit longer.  Well worth the read.

“Made to Stick: Why Some Ideas Survive and Others Die” by Chip Heath, Dan Heath

“Brick by Brick: How LEGO Rewrote the Rules of Innovation” by David Robertson

We all know (and love?) the humble LEGO brick – that 4 pegged indestructible plastic cube, that come a nuclear attack, along with the the cockroach will be the only things that will survive.   I have always been intrigued in the history of this company and how it got a foot hold in the lives of children and adults alike.

This book takes a look at the history from the very first wooden toy, to the revolutionary and risky step of investing in the new emerging plastic industry to the licensing deals that saved LEGO from going under.

The book is written in a slightly different style from most company biographies.  More akin to a business tutorial than a story.  The authors slip into a tone every so often that is very parent-like scolding a child for doing something so obviously wrong.

Though you can forgive the authors for such a tone because looking back on it you do wonder how arrogant or naive was LEGO’s management that they failed to keep up with the times.  They failed to embrace the change of digital, keeping their heads in the sand that the last 40 years children still wanted to play with bricks and they will continue to play with bricks for the next 40.

They lost market share quickly as they tried to do too much with their brand.  They opened failed theme parks (that they later then sold off keeping only a minority stake), they cannibalized their distribution channel (WalMart/Target/ToysRus) by opening failed LEGO only retail stores and squandered millions on failed digital projects.

One of the biggest revelations what struck me was how poor accountants they were.  LEGO had no idea which lines were profitable and which lines were money losers.  They knew they had three strong markets, Germany, UK and America, but they didn’t have any real handle on why these markets were strong.

LEGO was going under.  Sales had flattened and costs were rising. Except most of their management couldn’t see it.  They were in disbelief and refused to stray off their current thinking.  

One of the biggest things that they fought against was licensing.   The now infamous StarWars LEGO nearly never happened.   The board was so against the idea of this as something that would dilute the brand and cheapen their offering that they dismissed it for nearly 18 months.

When they finally relented the next couple of years, StarWars accounted for a large percentage of their turnover, their tunes changed.   Suddenly everyone was behind the genius of licensing.   However, they then began to rely on the cash-cow that was StarWars to bail them out, and when StarWars stopped releasing movies, they noticed another flattening of growth.  In recent years they have secured the rights to the likes of Lord Of The Rings and Harry Potter to great profitability.

One of the things that LEGO was guilty of was unmetered creativity.  They allowed their engineers and designers to create whatever kits they wanted, with no thought to the cost of tooling injection molds to create the said kits.   When this was finally realized (after installing their new cost tracking software) they started to make big changes to their products, removing all the expensive to make kits and low sellers.

“…strip complexity out of the business by taking such cost-reducing steps as halving the number of components in the company’s product portfolio”

That was when the 13.5% metric was introduced.  Every new product had to prove it was going to be at least 13.5% profitable or it wouldn’t even be started.   This included everything from inception, prototyping, manufacturing, distributing and support.  Product teams had to evolve to encompass multidisciplinary skill sets to be able to assure the success of a product.

In another drive, LEGO started to notice that adults were as passionate about the humble brick as the excited 6 year old.  They failed to capitalize on the millions of online fans in the early days of the Internet, but with a change of management, these online communities soon were harnessed to help design, alpha test what was referred to as open-source LEGO kits.

LEGO had an unnerving attention to quality.  They felt that if it was not good enough it shouldn’t be released.  They literally spent millions on products (the doomed online Universe multi-player game sucked up $30M for example) seeking perfection.  However, the world wasn’t prepared to wait.

The crowd-sourcing nature of product development meant that “good enough” is what customers really wanted.   They were completely blind sided that a single developer working on his own, built an online collaborative universe of building blocks (Minecraft) when their own online gaming world was so buggy in their eyes (they actually wrote into the contract with the software company the software would be delivered “bug free”).

What’s certain is that Universe’s failure and Minecraft’s success demonstrate that to create a low-end disruptor, it’s far more effective to put a tight lid on resources, free the development group from outside distractions, kick the product into the market before it’s completely “finished,” learn from customers’ feedback, and make improvements in real time. 

What LEGO didn’t figure out that in the virtual world there is no assurances and guarantees.   There wasn’t enough time to go through all the different permutations to reach perfection.   They fixated on insisting the LEGO logo rendered on the end of each peg on the block to create that authenticate feel in a 3D Universe.

The history of this much loved Danish icon is absolutely fascinating and this book presents it in a very digestible format that doesn’t require a huge amount of effort.

“Brick by Brick: How LEGO Rewrote the Rules of Innovation” by David Robertson

“Sam Walton: Made In America” by Sam Walton

I’ve recently finished a fascinating book on the history of Walmart, as told by its founder, Sam Walton.  Written in the last year before he died in 1992.  At that time Walmart was a $53billion turnover company, and for some context, if you had bought $100 shares at its initial IPO in the early 1970’s, they would be worth $3.8million today (the shares split so many times over the years).

This is a very easy read with no effort required, but offers a great insight into how he managed the growth of such a large corporate.   He had some wonderful ideas and asked a lot from his managers – namely keeping the customer in mind at all times.   He wanted everyone (and I mean everyone) to be on the shop floor at least once a week and engaging with a shopper.

There are lots of “ah ha” moments in the book (history of Sams club), why Walmart has greeters (very surprising reason), and how he is proud to say he has the biggest fleet of millionaire trucker drivers in the country (everyone has stocks in Walmart).  Also beautiful tales of how he stole ideas from all the other retailers including Kroger, Target and JCPenny.  

He held all his management meetings on a Saturday morning as he didn’t believe real retailers worked 9-to-5.   He also wasn’t a believer in having the company pay for things – so when the corporate headquarters got a new gym and sports centre, he said that the $3M should come out of his pocket and not out of the shoppers pocket.   To this day (1992), he is proud that their offices in Bentoville will never win any design awards.

This book was on the short list for Jeff Bezos as he was inspired by Sam’s attention to the customer that he “stole” that idea for Amazon.

“Sam Walton: Made In America” by Sam Walton