Mark Needham

Nate Silver is famous for having correctly predicted the winner of all 50 states in the 2012 United States elections and Sid recommended his book so I could learn more about statistics for the A/B tests that we were running.

I thought the book was a really good introduction to applied statistics and by using real life examples which most people would be able to relate to it makes a potentially dull subject interesting.

Reasonably early on the author points out that there’s a difference between making a prediction and making a forecast:

• Prediction – a definitive and specific statement about when and where something will happen e.g. a major earthquake will hit Kyoto, Japan, on June 28.
• Forecast – a probabilistic statement over a longer time scale e.g. there is a 60% chance of an earthquake in Southern California over the next 30 years.

The book mainly focuses on the latter.

We then move onto quite an interesting section about over fitting which is where we mistake noise for signal in our data.

I first came across this term when Jen and I were working through one of the Kaggle problems and were using a random forest of deliberately over fitted Decision Trees to do digit recognition.

It’s not a problem when we combine lots of decision trees together and use a majority wins algorithm to make our prediction but if we use just one of them its predictions on any new data will be completely wrong.

Later on in the book he points out that a lot of conspiracy theories come when we look at data retrospectively and can easily detect signal from noise in data when at the time it was much more difficult.

He also points out that sometimes there isn’t actually any signal, it’s all noise, and we can fall into the trap of looking for something that isn’t there. I think this ‘noise’ is what we’d refer to as random variation in the context of an A/B test.

Silver also encourages us to make sure that we understand the theory behind any inference we make:

Statistical inferences are much stronger when backed up by theory or at least some deeper thinking about their root causes.

When we were running A/B tests Sid encouraged people to think whether a theory about why conversion had changed made logical sense before assuming it was true which I think covers similar ground.

A big chunk of the book covers Bayes’ theorem and how often when we’re making forecasts we have prior beliefs which it forces us to make explicit.

For example there is a section which talks about the probability a lady is being cheated on given that she’s found some underwear that she doesn’t recognise in her house.

In order to work out the probability she’s being cheated on we need to know the probability that she was being cheated on before she found the underwear. Silver suggests that since 4% of married partners cheat on their spouses that would be a good number to use.

He then goes on to show multiple other problems throughout the book that we can apply Bayes’ theorem to.

Some other interesting things I picked up are that if we’re good at forecasting then being given more information should make our forecast better and that when we don’t have any special information we’re better off following the opinion of the crowd.

Silver also showed a clever trick for inferring data points on a data set which follows a power law i.e. the long tail distribution where there are very few massive events but lots of really small ones.

We have a power law distribution when modelling the number of terrorists attacks vs number of fatalities but if we change both scales to be logarithmic we can come up with a probability of how likely more deadly attacks are.

There is then some discussion of how we can make changes in the way that we treat terrorism to try and impact the shape of the chart e.g. in Israel Silver suggests that they really want to avoid a very deadly attack but at the expense of there being more smaller attacks.

A lot of the book is spent discussing weather/earthquake forecasting which is very interesting to read about but I couldn’t quite see a link back to the software context.

Overall though I found it an interesting read although there are probably a few places that you can skim over the detail and still get the gist of what he’s saying.

My colleague Pat Kua recently published a book he’s been working on for the first half of the year titled ‘The Retrospective Handbook‘ – a book in which Pat shares his experiences with retrospectives and gives advice to budding facilitators.

I was intrigued what the book would be like because the skill gap between Pat and me with respect to facilitating retrospectives is huge and I’ve often found that experts in a subject can have a tendency to be a bit preachy when writing about their subject!

In actual fact Pat has done a great job making the topic accessible to all skill levels and several times covers typical problems with retrospectives before describing possible solutions.

These were some of the things that I took away:

• One of the most interesting parts of the book was a section titled ‘Be Aware of Cultural Dimensions’ where Pat covers some of the different challenges we have when people from different cultures work together.

  I found the power distance index (PDI) especially interesting:

  The extent to which the less powerful members of organisations and institutions accept and expect that power is distributed unequally

  If you come from a culture with a low PDI you’re more likely to challenge something someone else said regardless of their role but if you’re from a culture with a high PDI you probably won’t say anything.

  The US/UK tend to have low PDI whereas India has a high PDI – something I found fascinating when participating in retrospectives in India in 2010/2011. I think the facilitator needs to be aware of this otherwise they might make someone very uncomfortable by pushing them too hard to share their opinion.

• A theme across the book is that retrospectives aren’t about the facilitator – the facilitator’s role is to help guide the team through the process and keep things moving, they shouldn’t be the focal point. In my opinion if a facilitator is doing that well then they’d be almost invisible much like a football referee when they’re having a good game!
• The ‘First-Time Facilitation Tips’ chapter is particularly worth reading and reminded me that part of the facilitator’s role is to encourage equal participation from the group:
  

  A common, shared picture is only possible if all participants give their input freely and share their view of the story. This is difficult if one or two people are allowed to dominate discussions. Part of your role as a facilitator is to use whatever techniques you can to ensure a balanced conversation occurs.

  I think this is much easier for an external facilitator to do as they won’t have the burden of inter team politics/hierarchy to deal with.

  Pat goes on to suggests splitting the group up into smaller groups as one technique to get people involved, an approach I’ve found works and from my experience this works really well and gets around the problem that many people aren’t comfortable discussing things in big groups.

• There’s nothing more boring than doing the same retrospective week after week, nor is there a quicker way to completely put people off them, so I was pleased to see that Pat dedicated a chapter to keeping retrospectives fresh.

  He suggests a variety of different techniques including bringing food or running the retrospective in a different location to normal to keep it interesting. I’ve heard of colleagues in Brazil doing their retrospectives outside which is another angle on this theme!

• Another good tip is that when creating actions we don’t need to spend time getting someone to sign up for them right there and then – an alternative is to encourage people to walk the wall and pick ones they feel they can take care of.

I think this book compliments Esther Derby/Diana Larsen’s ‘Agile Retrospectives‘ really well.

I find their book really useful for finding exercises to use in retrospectives to keep it interesting whereas Pat’s book is more about the challenges you’re likely to face during the retrospective itself.

There’s lots of other useful tips and tricks in the book – these are just a few of the ones that stood out for me – it’s well worth a read if you’re a participant/facilitator in retrospectives on your team.

I’d heard about The Lean Startup for a long time before I actually read it, mainly from following the ‘Startup Lessons Learned‘ blog, but I didn’t get the book until a colleague suggested a meetup to discuss how we might apply the ideas on our projects.

My general learning from the book is that we need to take the idea of creating tight feedback loops, which we’ve learnt in the agile/lean worlds, and apply it to product development.

Eric Ries talks about the ideas of the Minimum Viable Product (MVP), which is something that I’ve heard mentioned a lot in the last few projects I’ve worked on so I thought I knew what it meant.

I’d always considered the MVP to effectively be the first release of any product you were building but Ries’ frames it as the minimum product you can release to get feedback on whether your idea is viable or not. For example Dropbox’s MVP was a video demonstrating how it would work when the team had written the code to sync files on all operating systems.

On a lot of the projects that I’ve worked on we start after the point at which the business has decided what their product vision is and we’re responsible for implementing it. They haven’t necessarily then gone on to make a big return from building the product which I always found strange.

The most frequent argument I’ve heard against releasing an ‘incomplete’ product early in the organisations that I’ve worked for is that it could ruin their brand if they took this approach. One suggestion the book makes is to release the product under a spin off subsidiary if we’re worried about that.

The book also discussed the ways that we need to treat early adopters of a product and mainstream customers differently.

For example early adopters won’t mind/may actually prefer to play with an unfinished product if they can help influence its future direction.

By the time we have proved that we have a viable product and are looking to aim it at the mainstream market it will need to be more feature complete and polished in order to please that crowd.

There is a big focus on making data driven decisions such that we gather metrics showing how our product is actually being used by customers rather than just guessing/going on intuition as to what we should be doing next.

Facebook released an interesting video where towards the end they describe the metrics which they have around their application such that they can tell whether a deployment is losing them money and therefore needs to be rolled back.

One particular thing that the book talks about is cohort analysis:

A cohort analysis is a tool that helps measure user engagement over time. It helps UX designers know whether user engagement is actually getting better over time or is only appearing to improve because of growth.

We tend to use metrics to help us see the quality of code and which things we might want to work on there but I think the idea of using it to measure user engagement is really cool and should help us to build a more useful product.

I especially enjoyed the parts of the book where Ries talks about ways that some of the ideas have been applied with startups which are doing well at the moment although I think it’d be fair to say that the lean startup framework has been retrospectively fitted to explain these stories.

I think the danger of thinking that they were following lean startup principles is that it can lead to us not thinking through problems ourselves which I guess is the same problem with any framework/methodology.

I’m intrigued as to whether it will make a difference to the overall success rate of startups or not if they follow the ideas from the book.

I imagine we’ll see some ideas failing much more quickly than they might have otherwise and the suggestion is that when this happens we need to pivot and try and find another approach that will make money. Despite that, there there will come a point when the startup runs out of money without finding a way to monetise their product and it’ll be game over.

Overall the book is quite easy reading and worth a flick through as it has some cool ideas which can help us to spend less time building products which don’t actually get used.

I came across the work of Chris Argyris at the start of the year and in a twitter conversation with Benjamin Mitchell he suggested that Bill Noonan’s ‘Discussing the Undiscussable‘ was the most accessible text for someone new to the subject.

In the book Noonan runs through a series of different tools that Chris Argyris originally came up with for helping people to handle difficult conversational situations more effectively.

I really like the way the book is written.

A lot of books of this ilk come across to me as being very idealistic but Noonan avoids that by describing his own mistakes in trying to implement Argyris’ ideas. This makes the book much more accessible to me.

He also repeatedly points out that even though you might understand the tools that doesn’t mean that you’ll be an expert in using them unless you spend a significant amount of time practicing.

These were some of the ideas that stood out for me from my reading over the last few months:

• Advocacy/Inquiry – Noonan suggests that when we’re discussing a topic it’s important to advocate our opinion but also be open to people challenging it so that we can learn if there are any gaps in our understanding or anything that we’re missing.

  This seems quite similar to Bob Sutton’s ‘Strong Opinions, Weakly Held‘ which I’ve come across several times in the past.

  One anti pattern which comes from not doing this is known as ‘easing in‘ where we try to get the other person to advocate our opinion through the use of various leading questions.

  The problem is that they tend to know exactly what we’re doing and it can come across as being quite manipulative.

• The Ladder of Inference – I’ve written about this previously and it describes the way that humans tend to very quickly draw conclusions about other people based on fairly minimal data and without even talking to the other person first!

  When Jim and I worked together at ThoughtWorks University we were constantly pointing out when the other was climbing the inference ladder and it was quite surprising to me how often you end up doing so even when you don’t realise it!

  What I find most interesting is that even when I was absolutely sure that my inference about a situation was correct it was still frequently wrong when I discussed it with the other person. They nearly always had a different perception of what was going on than I did.

  I think it’s a step too far to believe that I won’t ever climb the inference ladder again but it’s useful to know how frequently I do it so at least I’m aware that I might need to climb down from time to time.

• Recovery time – There is constant reference throughout the book to our recovery time i.e. how quickly do we realise that we’ve made a mistake by participating in a defensive routine.

  Argyris’ tools are quite useful for helping us to reduce our recovery time because they are reflective in nature and when we reflect on a situation we tend to see where we’ve gone wrong!

  Noonan suggests that it’s inevitable we’ll make mistakes but the key is to try and detect our mistakes sooner and then hopefully reduce the number that we make.

Of course there are several other tools that Noonan describes, such as the left hand right hand case study approach, double loop learning, espoused theory vs theory in action and the mutual learning model.

I still make loads of the mistakes that the book points out and I’ve noticed that I only really reflect on how my conversations are going when I’ve been flicking through the book relatively recently.

It’s also useful to be hanging around other people who are studying Argyris’ work as you can then help each other out.

One of the initial books that Chris Argyris published describing these tools was ‘Action Science‘ (available as a free PDF).

I initially tried reading that before this book but I found it a bit hard to follow but I’ll probably try it again at some stage.

Something which I frequently forget while reading books is that it’s actually quite useful to know exactly why you’re reading it i.e. what knowledge are you trying to gain by doing so.

I noticed this again recently while reading The Agile Samurai – it’s one of the books we ask ThoughtWorks University participants to read before they come to India.

Implicitly I knew that I just wanted to get a rough idea of what sort of things it’s telling people but I somewhat foolishly just started reading it cover to cover.

I only realised that I’d been doing this when I’d got a third of the way through and realised that I hadn’t really learnt that much since the book effectively describes the way that ThoughtWorks delivers projects.

In Pragmatic Learning and Thinking Andy Hunt suggests the SQ3R reading comprehension method which I always forget about!

• Survey – scan the table of contents and chapter summaries
• Question – note any questions you have
• Read – read in entirety
• Recite – Summarise and take notes in your own words
• Review – Re-read, expand notes, discuss with colleagues

I don’t think it always needs to be quite as organised as this but I’ve certainly found it useful to scan the chapter headings and see which ones interest me and then skip the ones which don’t seem worth reading.

When reading The Art of Unix Programming I felt that I was learning a lot of different things for the first ten chapters or so but then it started to get quite boring for me so I skimmed the rest of the book and ended up reading just half of the chapters completely.

The amusing thing for me is that I knew about this technique a couple of years ago but I still don’t use it which I think that comes down to having a bit of a psychological thing about needing to finish books.

At the moment I have around 15 books which I’ve partially read and at the back of my mind I know that I want to go and read the rest of them even though there will undoubtably be varying returns from doing that!

I need to just let them go…

I read Dan Pink’s A Whole New Mind earlier in the year but I hadn’t heard of The Adventures of Johnny Bunko until my colleague Sumeet Moghe mentioned it in a conversation during ThoughtWorks India’s XConf, an internal conference run here.

The book is written in the Manga format so it’s incredibly quick to read and it gives 6 ideas around building a career.

I’m generally not a fan of the idea of ‘building a career’ – generally when I hear that phrase it involves having a ‘five year’ plan and other such concepts which I consider to be pointless.

I much prefer to just focus on what I’m most interested in at the moment and then have the flexibility to be able to focus on something else if that interests me more.

Luckily this book is not at all like that and these are the ideas Dan Pink suggests:

There is no plan

The most interesting part of this piece of advice is Pink’s suggestion that when we make career decisions we make them for two different types of reasons:

• Instrumental reasons – we do something because we think it’s going to lead to something else regardless of whether we enjoy it or think it’s worthwhile.
• Fundamental reasons – we so something because it’s inherently valuable regardless of what it may or may not lead to.

I think this pretty much makes sense – it’s very difficult to predict what’s going to happen so you might as well make sure you’re doing what you want at any given time.

Think strengths not weaknesses

Marcus Buckingham has several books on this subject but the general idea is that we should look to focus on things that we’re good at or are really motivated to become good at.

By inference this means that we want to avoid spending time on things that we’re not good at and/or not interested in becoming good at.

I recently came across a blog post written by Robbie Maciver where he suggests that we can use a retrospective to help us identify team member’s strengths and work out how best to utilise them.

I think there’s sometimes a reluctance for people to volunteer their strengths so we end up with people working on tasks that they hate that other people in the same team would enjoy.

It’s not about you

Pink then goes on to point out that even if we do work out how to play to our strengths we still need to ensure that we’re focusing on our customer/client.

Pink calls this focusing outward not inward.

In terms of working in technology consulting that would therefore be along the lines of ensuring that we’re focused on solving our clients’ problems in the best way for them rather than the most interesting way for us.

Persistence trumps talent

This idea has been covered in several books including Outliers, Talent is Overrated and The Talent Code.

The underlying idea is that people aren’t born brilliant at any skill, it only comes through practice and if we’re intrinsically motivated to do something then we’re much more likely to put in the time it requires to become really good.

To add to that I think intrinsic motivation is highest when we’re focusing on our strengths so this piece of advice is linked with the earlier one.

Make excellent mistakes

Pink talks about making excellent mistakes which he describes as ‘mistakes that come from having high aspirations, from trying to do something nobody else has done’.

I think this is somewhat linked to the idea of failing fast although it seems to be perhaps one level beyond that.

Sumeet gave a talk at XConf where he described the new approach to ThoughtWorks University and pointed out that one of the most important goals was to allow attendees to make ‘excellent mistakes’

One observation I have here is that smaller companies seems more willing to make excellent mistakes. As organisations grow the aversion to risk because of worries about loss of reputation increases which makes excellent mistakes less likely.

I find Eric Ries’ lean startup ideas particularly interesting with respect to failing fast and my former colleague Antonio Terreno recently linked to a video where the General Manager of Forward 3D explains how they do this.

Leave an imprint

Pink talks about the importance of doing work which actually has some meaning or leaves the world in a better place than it was before.

This is probably the one that I can relate to least. I’m writing software which is what I’m passionate about but I wouldn’t say the problems I work on are having much impact on the world.

This one therefore leaves me with the most to think about.

I’ve read a couple of Seth Godin’s other books – Tribes and The Dip – and found them fairly readable so I figured his latest offering, Linchpin, would probably be worth a read too.

This is the first book that I’ve read on the iPad’s Kindle application and it was a reasonably good reading experience – I particularly like the fact that you can make notes and highlight certain parts of the text.

It’s also possible to see which areas of the book other Kindle users have highlighted and you can see your highlights/notes via the Kindle website.

The Review

The sub-title of the book: ‘Are you indispensable? How to drive your career and create a remarkable future’ didn’t really appeal to me all that much but I’ve found that these types of things are often just for provocation and don’t necessarily detract from the message.

As with the other Godin books I’ve read, he spends a lot of time making his original point and in this one it felt like I’d already agreed with what he was saying for at least 50 pages before we moved onto something else.

Despite that I think there were some good points made in the book. These were some of the more interesting ones for me:

• One of my favourite quotes from the book is the following about fire:
  

  Fire is hot. That’s what it does. If you get burned by fire, you can be annoyed at yourself, but being angry at the fire doesn’t do you much good. And trying to teach the fire a lesson so it won’t be hot next time is certainly not time well spent.

  Our inclination is to give fire a pass, because it’s not human. But human beings are similar, in that they’re not going to change any time soon either.

  One of the things I’ve noticed over time is that it’s very unlikely that the core way a person behaves is likely to change regardless of the feedback that they get from other people.

  Pat touches on this in a post where he points out that we need to be prepared for feedback to not be accepted.

  I don’t think this means we should stop giving feedback to people if we think it will help them be more effective but it does seem useful to keep in mind and help us avoid frustration when we can’t change a person to behave in the way we’d like them to.

• Godin makes an interesting point about the value of the work that we do:
  

  A day’s work for a day’s pay (work <=> pay). I hate this approach to life. It cheapens us.

  This is exactly the consulting model – billing by the hour or by the day – and although I’ve come across a couple of alternative approaches I’m not sure that they work better than this model.

  Value based pricing is something which I’ve read about but it seems to me that there needs to be a certain degree of trust between the two parties for that to work out. The other is risk/reward pricing and I’ve heard good/bad stories about this approach.

  It seems to me that we’d need to have a situation where both parties were really involved in the long term outcome of the project/system so if one party is only invested for a short % of this time then it’s going to be difficult to make it work.

• Shipping is another area he touches on in a way that makes sense to me:
  

  I think the discipline of shipping is essential in the long-term path to becoming indispensable.

  The only purpose of starting is to finish, and while the projects we do are never really finished, they must ship. Shipping means hitting the publish button on your blog, showing a presentation to the sales team, answering the phone, selling the muffins, sending out your references. Shipping is the collision between your work and the outside world.

  While this is just generally applicable, in software terms this would be about the sort of thing that my colleagues Rolf Russell & Andy Duncan cover in their talk ‘Rapid and Reliable Releases‘.

  I also had an interesting discussion with Jon Spalding about the importance of just getting something out there with respect to the ‘Invisible Hand‘ browser plugin that he’s currently working on. Jon pointed out that it’s often best to ship and then rollback if there are problems rather than spending a lot of time trying to make sure something is perfect before shipping.

• Godin spends a lot of time pointing out how important human interactions and relationships are and I think this is something that is very important for software delivery teams. One of the most revealing quotes is this:
  

  You might be parroting the words from that negotiation book or the public-speaking training you went to, but every smart person you encounter knows that you’re winging it or putting us on.

  Virtually all of us make our living engaging directly with other people. When the interactions are genuine and transparent, they usually work. When they are artificial or manipulative, they fail.

  I attended a consulting training course when I first started working at ThoughtWorks 4 years ago and I’ve always found it impossible to actually use any of the ideas because it doesn’t feel natural. It’s interesting that Godin points out why this is!

Overall this book feels to me like a more general version of Chad Fowler’s ‘The Passionate Programmer‘ which is probably a more applicable book for software developers.

This one is still an interesting read although it primarily points out stuff that you probably already knew in a very clear and obvious way.

My colleagues Frankie and Danilo have been recommending ‘Maverick‘ to me for a long time and I finally got around to reading it.

In this book Ricardo Semler, the CEO of Semco, tells the story of the company and how he helped evolved the organisation into one which is more employee led and embraces ideas such as open & self set salaries while encouraging civil obedience in the workforce as a necessity to alert the organisation to its problems.

These were some of the ideas that I found the most interesting:

• Early on Semler points out that Semco doesn’t have a culture of looking busy. He describes how a sales manager spends a lot of his day just reading the newspaper but then as soon as there’s a problem for him to handle that’s when he earns his salary. Even though this book isn’t specifically about systems thinking, the description of this situation suggests to me that they are able to look at the bigger picture at Semco.

  In software teams we can often feel quite guilty if we’re not busy but a bit of slack time is often useful for thinking about better ways to do things or to spike out new ideas.

• Semler emphasises the need to have small business units of under 150 people while matches up quite well with research done by Robin Dunbar which indicates that 150 is the ‘theoretical cognitive limit to the number of people with whom one can maintain stable social relationships.’ Semler also adds that keeping the units small ‘keeps them human’.

  I know ThoughtWorks keeps this in mind with respect to our offices and will look to open a new one if the number of people in one is getting close to the 150-200 mark.

• Semco have a culture of what Semler refers to as ‘absolute trust‘ which he suggests is a more natural way. They implemented this at Semco by removing security checks on the gates into/out from the plants.

  He almost then predicts the inevitable question in the reader’s mind with the following statement:

  2 or 3% will take advantage of an employer’s trust. Is this a valid reason to subject 97% to a ritual of humiliation?

  Have thefts increased or decreased?

  I don’t know and I don’t care. It’s not worth it to me to have a company at which you don’t trust the people with whom you work.

  He promotes an approach of common sense amongst his employees, suggesting that ‘rules freeze companies inside a glacier; innovation lets them ride sleighs over it’.

  The general idea seems to be that the small details aren’t really that important and only serve to distract from the bigger objectives that the company are trying to achieve.

• I was quite surprised to read how strongly Semler recommends job rotation:

  Man is by nature restless. When left too long in one place he will inevitably grow bored, unmotivated, and unproductive. The cure, I believed, was to encourage managers to exchange jobs with one another

  He goes on to point out that this type of rotation forces people to learn new skills which makes them more valuable but also discourages empire building because people don’t stay in the same place for too long.

  I think we do this to some extent in the software industry between some roles but probably not as much as we could do. Having said that there is a lot to learn as a developer anyway so perhaps it’s not so applicable here.

• Perhaps the most controversial idea in the book is that of transparent/self set salaries. There was initially resistance to the latter idea as cynics believed that a few people would take advantage and award themselves massive pay increases. However, they found that having those salaries public served as a strong disincentive.

  He also identifies the fact that people have a stake in the success of the company as being key for allowing this to work:

  The third reason our people tended to be modest about salaries has to do with self preservation…Our people know salaries account for most of our operating costs, and they think about our budgets when they set them. It’s easy to solve a budget problem by eliminating a salary that seems too high, and noone wants to stick out.

• The underlying reason behind why a lot of the ideas Semler implements seem to be about unhiding information as described by the following quote:

  There is power in knowing something someone else doesn’t…but when cards are held close to the chest, communication will be faulty and anxieties, misunderstandings, insecurity, and eventually hostility will manifest itself…which is why when we started sharing information at Semco it has such a profound effect. People in the higher echelons could no longer rely on the conventional symbols and had to develop leadership skills and knowledge to inspire respect.

  Spreading responsibility for problem solving across the organisation is another idea Semler strongly encourages and I think this partly explains why it’s more fun working in an agile environment.

  Information in general is more accessible and because of that people have more opportunity to solve problems than they otherwise would.

• Semler discusses the need to keep the organisation lean even when times are good which he acknowledges is much more difficult than trying to keep it lean when times are hard! For Semco this involves being careful when hiring people to work on product lines which they knew had a short life span as well as ensuring that they didn’t add any unnecessary roles just because sales were strong.

Towards the end of the book Semler suggests that his goal with Semco was to ‘make people look forward to coming to work in the morning‘ which seems like quite a noble objective!

I found it quite interesting that although a lot of these ideas seem a bit radical, they made sense in Semco’s context because they were introduced incrementally and only after some other ideas had been introduced which helped smooth the way.

It’s certainly an interesting read and the ideas expressed at quite different than what is typical in most organisations.

I recently came across 37 Signals ‘Getting Real‘ book where they go through their approach to building web applications and there have certainly been some good reminders and ideas on the best way to do this.

These are some of my favourite parts:

• Ship it!
  

  If there are minor bugs, ship it as soon you have the core scenarios nailed and ship the bug fixes to web gradually after that. The faster you get the user feedback the better.

  Often on projects I’ve worked on we’ve taken the approach that bugs get worked on before new stories which makes sense in a way because it means that we are fixing problems quickly and keeping the quality of the application high.

  In reality what often happens is that low priority bugs just end up not getting looked at but I like the fact that we can choose to make that an explicit approach rather than just allowing it to happen to us.

  Prioritize your bugs (and even ignore some of them)

  Just because you discover a bug in your product, doesn’t mean it’s time to panic. All software has bugs – it’s just a fact of life.

  I find it interesting that there might be more value in getting something out the door and then getting feedback on it rather than spending extra time perfecting it up front.

• Fix Time and Budget, Flex Scope
  

  You have to figure out what’s really important. What’s going to make it into this initial release? This forces a constraint on you which will push you to make tough decisions instead of hemming and hawing.

  From my experience a lot of times we end up implementing features just because that’s what was agreed in the initial release plan and there is often a reluctance to change that even if a feature isn’t really that useful anymore.

  It becomes even more problematic if we get to the stage where it’s not possible to deliver all the features promised in the remaining time so it certainly makes sense to me that in that situation we would look to focus on getting the absolutely essential things in first.

• Choose any enemy
  

  Sometimes the best way to know what your app should be is to know what it shouldn’t be. Figure out your app’s enemy and you’ll shine a light on where you need to go.

  This seems to be a much better idea than just copying the ideas of your competitor which might seem the obvious thing to do if you’re working in the same area.

  The problem with that approach of course is that when you do copy you have no actual vision of what you’re doing with your application anyway so you’ll always be playing catch up.

• Don’t overcomplicate the application

  There are a few parts of the book where the authors talk about keeping the application simple and then letting the users play with it:

  The harder we tighten things down, the less room there is for a creative, emergent solution. Whether it’s locking down requirements before they are well understood or prematurely optimizing code, or inventing complex navigation and workflow scenarios before letting end users play with the system, the result is the same: an overly complicated, stupid system instead of a clean, elegant system that harnesses emergence.

  Keep it small. Keep it simple. Let it happen.

  Andrew Hunt, The Pragmatic Programmers

  The users can then decide for us where we need to fill in more details:

  Details reveal themselves as you use what you’re building. You’ll see what needs more attention. You’ll feel what’s missing. You’ll know which potholes to pave over because you’ll keep hitting them. That’s when you need to pay attention, not sooner.

  In particular they suggest that focusing on very specific details about the page layout/colour/wording can be left until later because it will only serve to hinder forward progress if we concentrate on it too early.

• Scaling an application
  

  You don’t have a scaling problem yet

  “Will my app scale when millions of people start using it?”

  Ya know what? Wait until that actually happens.

  On several projects that I’ve worked on there often seems to be a desire to focus on performance and scaling an application very early on which seems wasteful when we could be focusing on actually building something that has so many users that we need to scale it later on. I think this advice is spot on.

• Write less software

  A common theme throughout the book is that of writing less software to achieve our goals:

  The best designers and the best programmers…are the ones that can determine what just doesn’t matter.

  That’s where the real gains are made.

  Most of the time you spend is wasted on things that just don’t matter. If you can cut out the work and thinking that just don’t matter, you’ll achieve productivity you’ve never imagined.

  Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features.

  Throw away customer feature requests – if they’re really important then they’ll come back anyway

  Don’t worry about tracking and saving each request that comes in. Let your customers be your memory. If it’s really worth remembering, they’ll remind you until you can’t forget.

  The authors ideas around preferences were particularly interesting to me:

  Preferences are also evil because they create more software.

  More options require more code. And there’s all the extra testing and designing you need to do too.

  I hadn’t appreciated until recently quite how much complexity we can add to an application by allowing users to play around with the display of information on a screen.

  It seems like a nice feature to have but it would be interesting to see statistics that could tell us what percentage of users actually that type of thing when it’s not the core idea of the application.

  I also quite liked the following and I think it’s something that we need to do more often on teams:

  Encourage programmers to make counteroffers.You want to hear: “The way you suggested will take 12 hours. But there’s a way I can do it that will only take one hour. It won’t do x but it will do y.” Let the software push back. Tell programmers to fight for what they think is the best way.

• Decisions are temporary so make the call and move on
  

  So don’t do the “paralysis through analysis” thing. That only slows progress and saps morale.

  Instead, value the importance of moving on and moving forward. Get in the rhythm of making decisions. Make a quick, simple call and then go back and change that decision if it doesn’t work out.

  I think a big part of this is getting the mentality that it’s fine to make changes after we’ve ‘finished’ something. Any other approach doesn’t work from my experience.

• Reduce meetings
  

  Meetings usually arise when a concept isn’t clear enough. Instead of resorting to a meeting, try to simplify the concept so you can discuss it quickly via email or im or Campfire.

  I find it interesting that they prefer communicating by email because I’ve often found that it’s not the best communication mechanism since it’s really easy to misinterpret what people mean.

  Having said that if we can make concepts clearer and the need for a meeting is an indicator that we need to do that then perhaps we can still meet in person and just make the meeting much shorter.

• Design the interface before you start programming
  

  Too many apps start with a program-first mentality. That’s a bad idea. Programming is the heaviest component of building an app, meaning it’s the most expensive and hardest to change. Instead, start by designing first.

  I’ve certainly fallen into this trap a lot but I’ve been trying to follow the outside in approach more strictly recently and so far I’m finding that it reduces the feedback cycle quite substantially which is only a good thing.

• Design for regular, blank, and error states
  

  For each screen, you need to consider three possible states:

  Regular
  The screen people see when everything’s working fine and your app is flush with data.

  Blank
  The screen people see when using the app for the first time, before data is entered.

  Error
  The screen people see when something goes wrong.

  I’d never even though of this at all and I’m certainly guilty of only ever considering applications when all the data is filled in so this is certainly something else to consider.

• Tear down the walls between support and development
  

  In the restaurant business, there’s a world of difference between those working in the kitchen and those out front who deal with customers. It’s important for both sides to understand and empathize with the other. That’s why cooking schools and restaurants will often have chefs work out front as waiters so the kitchen staff can interact with customers and see what it’s actually like on the front lines.

  My colleague Chris Read and some others seem to be trying to close this gap with the devops movement which also has a track at QCon London this week.

  The idea of working in support to see what an application is like from that perspective is something that more experienced colleagues often recommend although I’ve not done it as yet.

Overall I found this book a really interesting and quick read and although many of the ideas suggested seem like common sense it’s strange that we often don’t do all of them.

The 37 Signals guys also have a new book coming out in the UK tomorrow titled ‘Rework‘ which sounds like it could be quite a good read as well.

I recently watched Randy Pausch’s ‘Last Lecture: Achieving Your Childhood Dreams‘ and read the corresponding book and although it’s not directly related to software development I think that some of the points that he makes are really intriguing.

These were some of the parts that particularly stood out for me:

• Introduce the elephant in the room – whatever it is that people are really thinking about, put it out in the open. I think on development teams there is often a distrust of the way that other people write code because it’s different to the way that we do. If we can get this out in the open more frequently and agree on a shared approach then it should result in a more consistent code base.
• Get the fundamentals down – Pausch suggests that we need to understand the fundamentals because otherwise the fancy stuff isn’t going to work. In Apprenticeship Patterns Ade Oshineye and Dave Hoover suggest that we should ‘Study the Classics‘ which is a similar idea.

  While I think they’re certainly right I’m not sure that learning theory before putting it into practice is the most effective way to learn. I think we need to do a bit of both at the same time alternating between the two so that we actually have a frame of reference when we’re learning the fundamentals.

• The brick walls are there for a reason – Pausch describes how we’ll often come across obstacles stopping or blocking us from what we want to do but that we shouldn’t be discouraged, they are there so that we can see how much we really want something. I think this is just generally true and not just related to software development.
• The skill of self assessment – Pausch suggests that we need know what we don’t know which I think is perhaps the best advice in the book. We need to recognise our true abilities but also have a sense of our flaws and create feedback loops to allow this to happen.

  My colleague Liz Douglass has come up with the idea of Feedback Frenzies to help create this feedback loop and this is one of the best ideas I’ve come across for doing this.

• One of my favourite quotes from the book is the following which I believe was originally from Dan Stanford:
  

  Experience is what you get when you didn’t get what you wanted

  …

  It’s a phrase worth considering at every brick wall we encounter, and at every disappointment. It’s also a reminder that failure is not just acceptable, it’s often essential.

  I think we can do this much more in the software world. There sometimes seems to be a stigma with identifying things which fail but I think it’s really useful for others to learn from mistakes that have been made.

The Last Lecture is one of the best presentations I’ve had the chance to watch – I’d certainly recommend it.