London Software Craftsmanship - Robot Tournament

To usher in the new format for LSCC Hands On Sessions we had an all evening session at the Google Campus!

WHAT WENT DOWN

The kata of the night was a straightforward implementation of a TicTacToe robot. The driving principles behind the night were around releasing early and regularly. At the end of each 5 minute round, each pair's robot would play all other robots. Along with doing TDD, this all meant we got fast feedback on how well our code/strategy was performing :)

I was lucky enough to pair with Sandro and it was really interesting working with him! I've forked the original repository and upgraded the code to use Java 8 Lambdas here:

https://github.com/arkangelofkaos/lscc_robot

MY IMPRESSIONS

Listening to feedback is invaluable

Actually paying attention to feedback is incredibly important. There were loads of problems with our Java 6/7 setup which regular and quick releases highlighted. Sadly we didn't pay more attention to the problem and we could have solved it sooner!

Focus on value

Whenever you are doing any coding, it is very important to understand why you are doing things and how you can measure the benefit. Software development is very intangible but it is our duty as software craftsman to deliver tangible value!

LESSONS LEARNT

Design upfront!
I think from now on I'm going to practice the Green Cross Code everything I under take a kata: 

1. Stop - Think about the problem and check your understanding with your pair.
2. Look - See if the problem has been solved or has a simple solution.
3. Listen - Discuss ideas for how to tackle the problem and agree a path only after listening!
4. Go - Write your first test! :P

A quick sketch of things never hurts either!

Rushing gets you nowhere fast

As the anti-thesis of the above, blindly rushing in "Leeeeroy" style really isn't beneficial at all, especially when time is tight!

Skimmer's Guide - Behaviour Driven Development with JavaScript

“BDD has many different aspects. Which of them are important depends on your perspective.”

WHAT IS THE ABOUT? 

Marco Emrich brings us a mature and enlightening insight into Behaviour Driven Development with JavaScript. Absolutely rammed full of excellent information, the book is nevertheless extremely well paced and reads very easily.

Beginning in earnest with a quick refresher on JavaScript, we are soon introduced to Jasmine, our JavaScript BDD weapon of choice ;) The underlying mechanics of BDD are explored (i.e. Red-Green-Refactor) before we are shown novel ways of generating data for our tests.

Particular attention is then spent on advising us how to organise/write our tests to maximise readability/maintainability. Following this we dive into Outside-In Development and how we can use it to flush out uncertainty. Use cases of the various types of 'test doubles' are covered, extensively so for mocks.

We finish by addressing the difficult question of "what is BDD?", bringing together everything we learnt into a formal methodology. The most important aspects are brought into focus and pointed in the direction of possible next steps into the BDD world.

WHAT STOOD OUT? 

JavaScript refresher (p. 7) 

Covering modern and functional aspects of JavaScript, this introductory chapter is incredible helpful for anyone rusty with JavaScript. Anyone experienced in JavaScript should probably simply skim/skip this though. 

Specs should be readable (p. 27) 

Great coverage of the DAMP/DRY principles here and throughout the chapter. Sound advice with warnings every developer should heed! 

Organising by feature or by fixture (p. 35) 

Interesting techniques for keeping tests cohesive and making them read naturally, through intelligent organisation and custom code tools. 

Using test doubles (p. 53) & Advantages and disadvantages of mocks (p. 61) 

Fantastic coverage on how and when to use dummy, stub and mock objects, including views on the pros and cons of mocking. 

Vocabulary (p. 61) 

A resonating account of the pitfalls of TDD for beginners and how an improved vocabulary better enables proper testing. 

IF YOU READ NOTHING ELSE... 

Baby Steps (p. 23) 
Wonderful teaching on the importance of having a "tight feedback loop". Emphasis it placed on how the longer it takes to find a problem, the harder it is to solve it. Taking baby steps when changing code will let you go faster! 

Triangulation (p. 42) 
A wonderful technique for "faking it until you make it", forcing you to test all the relevant paths through your code. 

Gerkin language (p. 66) & Goals and benefits (p. 67) 
Covers the fabled "Given Then When" syntax of BDD and how it isn't necessarily central to BDD.

CONCLUSION 

At less than £2.60 ($3.99) this book is insanely good value and I would highly recommend it to anyone starting to learn BDD, even if they have limited JS experience. Despite centring around JavaScript, the core concepts of BDD are covered magnificently and can be applied to any language. 

Highly accessible and easy to reference, this book definitely warrants inclusion on any developer's digital bookshelf.

Agile In A Day - Training Summary

Yesterday I was luckily enough to go on a day course on Agile, which covered a multitude of topics and gave me a nice refresher on the topic.

Experiential Learning

Although it sounds like another bad buzz word, the concept of "experiential learning" was employed throughout the day. I actually really enjoyed it and I would definitely agree that the whole "learning by doing" concept.

Do Less... And Do It Better?

One of our first lessons was around one of the core tenants of Agile: uncovering problems and adapting to change faster. Our exercise basically illustrated that doing less work all at once meant you:

1. Had less work to throw away if it all went wrong.
2. Could find better ways to do the rest of the work.

Obviously doing things better doesn't magically happen, the techniques for continously improving is kind of what Agile is all about. The main technique/framework we focussed on was Scrum.

Scrum

A famous diagram I recall from my university days, sadly I have never really done Scrum in anger :( The biggest take away I had was the emphasis on "knowing what 'done' looks like". All your tasks in your product backlog should have concrete acceptance criteria, which ideally should be an automated test.

Another revelation was on the actual Daily Scrum meeting. Contrary to my experience, these meetings are actually supposed to last 15 minutes max and any problems should be discussed offline. Being strict with time and strict with your processes is very important in Agile, perhaps more so than in waterfall?

Finally we were reminded that Scrum is a framework which is abstracted from Software Development. You can in fact use Scrum for any project in any discipline! How you actually "turn backlog into product" is completely up to you, Scrum is a doughnut and it is up to you to find the jam to fill it with (your own processes/methodologies, e.g. TDD).

Understanding Requirements

We were shown some really useful techniques for gathering and understanding requirements:

• 5 Why's - This is basically trying to get to what someone really needs, going beyond what they think they want to do to get it.
• Clarification - Focussing on quantifying requirements and trying to put metrics against them so everyone understands what needs to be done.
• Suggestions - When you understand what the real need is, at this point we can use our expertise to figure out the most effect way to deliver that need. At this point you want to remember things like KISS and YAGNI ;)

Retrospectives

One of the greatest takeaways I had from the training was the whole concept of linking retrospectives. So in every retrospective you follow these rough steps:

1. What did we say we would change in our last retrospective?
• Did the change go well?
• Are we going to keep/disregard this change?
2. What went well this iteration?
3. What went badly this iteration?
4. Name a few things we can change for the next iteration.

The whole idea of actually coming up with actions, recording them and trying to measure their effects is very refreshing. Whilst my experience of retrospectives is limited, actually trying to quantify changes beyond vague pieces of advice is stupidly obvious to me now.

Conclusion

As with any lesson, it is only useful if you put it into practice. Doing Scrum/Agile in isolation just doesn't work, although I can keep being disciplined in using XP techniques. Got to do more Test Driven DESIGN like I mean it!

London Code Dojo 22

Another outing to the London Code Dojo and I've come away with a treasure trove of lessons... now just to remember and apply them!

What Went Down

The dojo was a Checkout scenario, where we were given various fruits as input and we had to return the running total cost.

Whilst the problem was fairly straightforward, the challenge came in handling the shortened 15 minute pomodoro time limit and "requirements changes" in the middle of them!

Before the dojo, I set myself the goal of ensuring I did TDD like I meant it, which I had neglected in my previous dojo. This time I was pairing with Alexandra and I've posted my refactored take on what we did on GitHub (https://github.com/arkangelofkaos/CodeDojo22_Checkout). Once again I have used Java 8 in the code, luckily the collection manipulation leant itself nicely to Lambdas XD

My Impressions & Lessons Learnt

• Practise is tantamount to improvement, even after the last few dojos I can see that I am improving (long way to go still!)
• Advice on how to become a master at anything: "All you need to do is not give up!" (Keep practising!)
• Simple design is incredibly powerful but incredibly difficult to get right.
• In my experience, I still need to do a little design upfront, due to my lack of experience :P
• I still need to be more disciplined in refactoring after EVERY test pasts.
• Don't let technical debt build up, ever.
• Ensure tests are not fragile, remember tests are code too!
• Single Responsibility Principle is your friend, brilliant for creating "agile" code.
• As a goal, I want to do the Gilded Rose Kata which covers "Anti-If patterns"
• Pairing isn't supposed to make you twice as smart but half as stupid! :D
• Failing all else: KISS XD

London Code Dojo 19

*update* Added my basic Scala implementation of FizzBuzz here: https://github.com/arkangelofkaos/FizzBuzz

Recently I was introduced to the London Code Dojo by a good friend and on Monday I attended my first code dojo!

What is the Code Dojo?

A dojo is a place to practice an art and a code dojo is no different! The purpose of it is to allow developers to practice and learn. The first rule of code dojo is you are there to "do it right"!

Everyone has probably heard it takes practice to make perfect and in theory you need to do 10,000 hours of practice to become an expert in anything! This practice has to be done properly though, specifically it must:

• Be focussed
• Be goal-Directed
• Be stretching (aka not easy)
• Include continuous feedback
• Include self-reflection

To get this kind of practice at the dojo, we all participate in a kata. This is basically a coding exercise with very specific rules.

• The goal is to do things correctly, not to simply get everything done.
• You must do Test-Driven Development (this is taken to the extreme)
• You must do pair programming
• You must commit/revert every 5 minutes!
• Commits must be meaningful with a simple and descriptive one-line comment.
• After 20 minutes a quick retrospective is held and new requirements maybe added.

My Impressions & Lessons Learnt

Our Kata for the night revolved around implementing Fizz Buzz, which is non-trivial given the TDD constraints.

The dojo really gave me a baptism of fire. As no one wanted to write in Java,  I took it upon myself to try to code in Scala for the very first time. Simply reading the Scala chapter in my book club book had given me a decent start though :) Apologies to my pairing partners for the frustration!

@sleepyfox who runs the dojo made a great pitch for TDD and how it saves time in developing long AND short projects! From my point of view, I suppose it follows the whole "fail fast" methodology. Mistakes are always made and by doing TDD you ensure you catch mistakes quickly, rather than having to hunt for them.

However I still reckon the age old "it depends" answer applies to whether or not you should use TDD. Part of my 'homework' is to research "Spike and Stabilise" which sounds interesting...

One thing I did get pulled up on was my when I answered too quickly. Remember: "Respond don't react!". Polymorphism is not necessarily always the answer to replacing a bunch of "if - instanceof" statements!

My favourite phrase for the evening was: "If you are 'refactoring' but everything ends up broken, you are actually 'ref**ktoring' your code" XD

The biggest takeaway was the emphasis on ALWAYS being simple, concise and expressive. Doing things in a complicated fashion is easy, any idiot can do it. But being simple is tough, in both your code and your commit comments.

Really learnt a lot from the dojo and look forward to future ones!