Notes & Learnings from Q Con London 2014 - Day 2

Tim Lister - Forty Years of Teams

Or... "Forty years of playing well with others".  A really uplifting talk by Tim introduced us to day two, where we looked at Tim's very interesting career.  The alternative title was given because "one person cannot do anything substantial" and even if you could it's more satisfying saying "we did this!"

His IT career started by chance, when he found himself living with Fred Wang at University.  Fred's father, An Wang, was founder of Wang Laboratories which meant him and Fred had access to more computing power than his entire University.  They used this to analyse data from their fruit fly breeding as part of his Biology degree.

Tim was also lucky enough to be mentored by computer scientist Michael Jackson who was a "software poet" and produced code so beautiful and lucid, it was as if it were written by aliens.

The term "Best practices" can undermine the intellectual work.  I interpret this point as not blindly following rules regardless of circumstances e.g. "all code released to production must be performance tested".

Tim (with his friend Tom Marco) wrote the very popular book Peopleware now in it's third edition.  On the subject of writing "I think I am a sharper thinker when I write and then re-read it".  I couldn't agree more.

What I took away...Writing helps you gather your thoughts.  If you don't get innate pleasure from IT, move on.

Michael Nygard - Manoeuvrable Architecture

I love aviation so was pleased to see Michael relate aircraft design which win dog fights to an architecture that succeeds in business.

• A plane that can fly fastest and highest will not necessarily win a dog fight - According to military strategist John Boyd.
• The plane most likely to win is the one that can change it's speed and direction the quickest.
• In military strategy, you need to set the tempo of engagement so your enemy adjusts to you.
• In IT, this means you need to be able to scale up and down fast.  
• The F16 was almost given a ladder which would have hampered its ability to accelerate/decelerate -   Make sure your projects don't fail due to incremental compromises.

One of Boyd's key concepts is the OODA loop... Observe, Orient, Decide, Act.  The quicker you can do this, the higher the chance of success.

The concepts Michael discussed:

Plurality - It's ok to have multiple services in multiple styles with multiple versions existing at the same time.  Darwinian evolution can be applied to determine what survives.

Use URIs with abandon - This has many advantages.  For example, the terms and conditions on any website frequently change.  If a user registers on a given date, the T's and C's URI can be stored against that user keeping a record of what they agreed to.  Also, the URI stores the reference and complete context (as opposed to a mere id).

I spoke to Michael at the end of his talk as I was keen to get a book recommendation on some of his subjects, his response was "I really should write one".

Dan North - Deliberate advice from an accidental career

Contributor to 97 Things Every Programmer Should Know and creator of first ever BDD framework JBehave.  Much like the day's first talk, Dan reflected on his career so far.  His talk was divided into the following points.

• Today we are going to learn about DB restores - I missed the start (was talking to Michael, see above) but gathered that Dan once shut down a production DB.  What was memorable about this was his manager's reaction... calmly saying "today is the day we learn about database restores".
• "It's a fantastic feeling to have someone believe in you" - This sounds corny but I can definitely point to a few things people have said to me that have had a huge impact, the same goes for Dan.
• They're not pairing, they're just helping each other... at their own desks.  Some developers will resist collaboration (pair programming), but when people are prepared to meet each other half way, collaboration can flow.
• The stacktrace - Code for the person who supports it... always!  A colleague tried to interpret the root cause of a stacktrace and found it hard despite being told by Dan that it was work in progress.  
• The Product - Think about the value you add to the product when you code.  Ugly code in live could be giving the business value, beautiful code in development offers none.  
• The Leader - "You'll have to teach me" - A culture of not being afraid to admit you don't know something is very healthy.  Put the organisation ahead of your ego.
• Don't hire yourself - We are not rational people and we are biased to like people that are similar to ourselves.  Hiring is one of the most important things in business so read Peopleware (see above).
• You are what you do, not what you say.  This is especially relevant when under pressure.

Trisha Gee - HTML5, Angular.js, Groovy, Java, MongoDB all together - what could possibly go wrong?

Trisha was able to create all tiers of a web application in-front of a few hundred IT professionals.  She was brave to take this on and skilled to pull it off.

What I took away...Get your IDE keyboard shortcuts sorted!  Trisha was so quick at using hers I could hardly keep up at times. AngularJS looks awesome.

Adrian Cockcroft - Migrating to Microservices

Probably one of the best talks of QCon.  I just wished I could press the pause button as keeping up was hard at times.  Warning - there is a lot of relevant info missing from this.

A brief timeline of Netflix's architecture:

• 2009 - People said Netflix were crazy.
• 2010 - What Netflix is doing won't work.
• 2011 - It only works for unicorns like Netflix (This explains Adrian's twitter avatar)
• 2012 - OK but we can't do that.
• 2013 - We're on our way using Netflix OSS code.

A few principles Adrian shared with us:

• Speed to marketplace is paramount - Netflix learns fast.
• High trust low process facilitates this.
• Don't create your own, when something already created will do the job.  Don't create your own voltage regulator for your servers...
• Favour open source - There is no procurement overhead.
• Reverse Conway's law - Decide on the architecture you want and then create/structure the teams.

Microservices:

• Additive model - don't edit or drop an existing service, just create a new version of it.
• Roll out your changes gradually with small sections of users.  Netflix use the EU as their testing ground!  

Further reading:

Adrian recommended the book Lean Enterprise which is due to be released in May of this year.  To convert from your old architecture read Refactoring Databases.  To look at how some of these new data stores really perform, have a look here.

Bodil Stokke - What Every Hipster Should Know About Functional Reactive Programming

Bodil created an interactive game using the RxJS set of libraries during the talk... very impressive.  Source code available here.  

Linda Risling - Organizational Change Myths

The author of Fearless Change spoke to us about the following myths....

• "Smart people are rational" - They are definitely not as rational as you'd think.  See Thinking fast and slow
• "Good always triumphs evil" - Just because your idea is good, doesn't mean it will succeed.  You have to fight for your idea.  Linda recommends giving people food in meetings to convince them.
• "If I just had enough power I could make people change" - If you had the power, all you can hope for is getting compliance, this is not change.  For change, people need to be convinced.
• "Skeptics, cynics and resistors must be stupid or bad" - Treat these people as valued partners in the change effort, not enemies.
• "I'm a smart person, I don't need help from others.  After all it's my idea." - The change must not be all about you.

A lot more of this good stuff available in Linda's book Fearless Change.