Friday, 7 September 2018

Book Review: Pivot – Real Cut Through Stories by Experts at the Frontline of Agility and Transformation

This was an alright read. Some of the contributions I thought were a bit on the theoretical side which wasn't what I was expecting judging by the title but there were some good real life examples mixed in. Some of the points that stood out for me were (1) the importance of differentiating between Agile the process and agility as a mindset, (2) understanding that being agile and willing to change a product's direction is a good thing but changing direction doesn't come for free and (3) having a hero culture in an organisation is bad without exception.

Below is a small selection of excerpts from the book:
"Having even just a few people in hero positions can be a sign of bad leadership."
"Leaders should foster environments where the team as a whole is valued and appreciated. It is not to say that we shouldn't acknowledge individual efforts. After a job well done and recognising the team, if you feel someone deserves more, tell them in person."
"I recommend replacing the demand for heroism and sacrifice to setting a goal of sustainable goals. As a result, the team becomes confident in their abilities without the hero of the team."
"The traditional image of heroism does not fit all-stars agile team."
"A leader should be equipped to spot both a culture of hero worship and individuals who engage in self-sacrificial behaviour at the cost of long-term sustainability."
"No more heroes."
"Knowing your organisations purpose and creating a unified vision spanning organisational silo together with cross-team collaboration is essential to delivering value and maintaining market relevance. Nokia's high performing Agile teams, did not stop it from losing huge market share to Apple and Google in the upper end of the smart phone market.  Being Agile is not enough."
"There is no world where feedback doesn't take time to implement. If this is a project with an agreed delivery date, when the client gives you feedback, you need to manage expectations and move the goalposts. Change doesn't come for free. Adapting to change is a two-way thing."

Friday, 11 May 2018

Types of Test Doubles

Think of a test double as a kind of pretend object used in place of a real object for testing purposes. Below are the different kinds of test doubles that you may encounter.


  • An object that is passed around but never used.
  • Used to help fill parameter lists or fulfil mandatory field requirements where the object will never get used but gets the code to run.
  • In many cases it's just an empty or null object.


  • An object that always returns the same canned response.
  • Used when you want to replace a real implementation with an object that will return the same response every time.


  • An actual working implementation (close to but not of production quality or configuration) that can replace the real implementation.
  • Can be seen as an enhanced stub that almost does the same work as the production code but takes a few shortcuts in order to fulfil the testing requirements.
  • An example is an in-memory database (used instead of a real, persistent database).


  • An object that represents a series of expectations and provides canned responses.
  • Can be seen as a programmable stub which can be told the sequence of calls to expect and how it should respond to each one.
  • Combines well with Dependency Injection in that it allows pretend objects to be injected that will behave in precisely known ways.

(Source: The Well-Grounded Java Developer, by Benjamin J. Evans and Martijn Verburg)

Friday, 9 February 2018

Book Review: The Well-Grounded Java Developer, by Benjamin J Evans and Martin Verburg

Although Java 9 is now out and this book was written way back when Java 7 was new I still found this to be a very useful and educational read. The book explains the fundamentals of the Java platform (e.g. bytecode, garbage collection) and programming principles in general (e.g. concurrency, dependency injection, functional programming) in a way that I've not seen in any other book. The introduction and contrast of the Groovy, Scala and Clojure JVM languages I also thought was done well. Some aspects of the book are now dated but it's still worthwhile skimming over for a historical context of how the platform has developed. If you're new to programming and new to Java development however this probably isn't the right book to start with.

Sunday, 21 January 2018

Types of programming languages

Interpreted vs Compiled

  • In an interpreted language each step of the source code is executed as is.
  • A compiled language uses a compiler to convert the human-readable source code into a binary form as an initial task.

Dynamic vs Static

  • In a dynamic language a variable can contain different types at different times.
  • In a static language the type information is all about the variable itself, not the value in the variable.

Imperative vs Functional

  • An imperative language models the running state of a program as mutable data and issues a list of instructions that transform that running state.
  • A functional language operates on values but, instead of altering the inputs, functions act like mathematical functions and return new values.
(Source: The Well-Grounded Java Developer, by Benjamin J. Evans and Martijn Verburg)

Wednesday, 20 December 2017

Book Review: The Elements of Scrum, by Chris Sims and Hillary Louise Johnson

I got this book after reading the abridged version by the same authors. Like the abridged version this book is well written and the concepts well explained. The book opens with a good comparison of "waterfall" vs "agile" development. Following this is a very enjoyable exposition of the agile values and principles (individuals and interactions over processes and tools etc etc). Following this is the core part of the book: explanations of the roles (product owner, scrum master, team member), ceremonies (sprint planning, daily standup, sprint review, sprint retrospective, backlog grooming, story time) and artifacts (product backlog, sprint backlog, burn charts, task board, definition of done) that make up scrum. Within the core part of the book is a good explanation of what user stories are and how they help with understanding what needs to be built, for who and, importantly, why. And closing out the core part of the book is a discussion on some tried and tested strategies for estimating stories.

I've not read any other books on scrum so I can't compare but I'd be very very amazed to find a better one out there than this one. This book covered absolutely lots of ground whilst remaining compact and, most importantly, very readable.

Below is a small selection of quotes from the book:
"...only by demonstrating working software to your customer can you find out what they really want... agile processes include constant feedback from customers, projects stay relevant and on track..."
"...The main idea behind the agile approach is to deliver business value immediately, in the form of working software, and to continue delivering value in regular increments..."
"...Document as you go, and only as needed..."
"...It’s only human nature to become attached to something you worked hard to produce; if you spend the same amount of time drafting your documentation as Tolstoy spent writing War and Peace, you may find yourself treating your masterpiece as if it were the work product itself..."
"...In order to be successful, a contributor-scrum master must put the needs and success of the team above the desire to directly contribute..."
"...Being a scrum team member isn’t about getting your job done, it’s about getting the job done..."
"...Velocity should never be used as a performance metric: it’s not about demonstrating to management that you’re working fast enough; it’s about gaining predictability of schedule..."

Friday, 29 September 2017

Book Review: Scrum: A Breathtakingly Brief and Agile Introduction, by Chris Sims and Hillary Louise Johnson

Good, concise, to-the-point introduction and summary of the Scrum way of working for teams and companies. The book covers the Roles (Product Owner, Scrum Master, Team Member), the Artifacts (Product Backlog, Sprint Backlog, Burn Charts etc) and the Sprint Cycle elements (Daily Scrum, Story Time, Sprint Review etc) that make up a Scrum workflow.

Book Summary: Clean Code, by Robert C Martin

An absolute must-read for all software engineers and programmers and especially so if you work with Java or any such programming language. The first half of the book explains the concepts (naming, formatting, testing etc) that make up clean code and lays down the foundation. The second half of the book contains examples of the author working through and cleaning and refactoring code. It all comes together nicely and I've found it to be really impactful in influencing how I think about code.

I've included below a summary of the core messages that I took away from the book.

  • Honesty in small things is not a small thing.
  • Cleanliness is next to godliness.
  • Leave the campground cleaner than you found it.
  • LeBlanc's law: Later equals never.
  • The fault is not in our stars but in ourselves.
  • A building with broken windows looks like nobody cares about it.
  • One broken window starts the process toward decay.
  • Bad code tries to do too much, it has muddled intent and ambiguity of purpose. Clean code is focused. Each function/class/module exposes a single-minded attitude that remains entirely undistracted, and polluted, by the surrounding details.
  • Readers of our code should perceive us to have been decisive.
  • There is a difference between code that is easy to read and code that is easy to change.
  • When the same thing is done over and over, it's a sign that there is an idea in our mind that is not well represented in the code.
  • Can you imagine working on a project where the code simply got better as time passed? Do you believe that any other option is professional?
  • You should name a variable using the same care with which you name a first-born child.
  • Choosing good names takes time but saves more than it takes.
  • Don't be afraid to spend time choosing a name.
  • Hunting for a good name often results in a favourable restructuring of the code.
  • If we cannot derive a concise name for a class or function, then it's likely too large. The more ambiguous the class or function name, the more likely it has too many responsibilities.
  • Take care with your names and change them when you find better ones.
  • One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king.
  • The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.
  • Functions should do one thing. They should do it well. They should do it only.
  • You know you are working on clean code when each routine turns out to be pretty much what you expected.
  • The ideal number of arguments for a function is zero. Next comes one, followed closely by two. Three arguments should be avoided where possible.
  • Passing a boolean into a function is a terrible practice. It proclaims that the function does more than one thing: one thing if the flag is true and another if the flag is false.
  • Output arguments should be avoided. If your function must change the state of something, have it change the state of its owning object.
  • Don't comment bad code – rewrite it.
  • The proper use of comments is to compensate for our failure to express ourself in code.
  • Inaccurate comments are far worse than no comments at all. They delude and mislead.
  • When people look under the hood, we want them to be impressed with the neatness, consistency, and attention to detail that they perceive. We want them to be struck by the orderliness. We want them to perceive that professionals have been at work.
  • We want the software to have a consistent style. We don't want it to appear to have been written by a bunch of disagreeing individuals.
  • There is a reason that we keep our variables private [and not exposed through getters and setters]. We don't want anyone else to depend on them. We want to keep the freedom to change their type or implementation on a whim or an impulse.
  • Law of Demeter: a module should not know about the innards of the objects it manipulates.
Error handling
  • Error handling should be complete. This goes to the discipline of paying attention to details.
  • Code, without tests, is not clean. No matter how elegant or readable it is.
  • Don't rely on your intuition. Look for every boundary condition and write a test for it.
  • Without a test suite we cannot ensure that changes in one part of our system do not break other parts of the system.
  • If you have tests, you do not fear making changes to the code. Without tests every change is a possible bug.
  • Tests enable change.
  • Having dirty tests is equivalent to, if not worse than, having no tests.
  • The dirtier the tests, the harder they are to change.
  • Test code is just as important as production code. It is not a second-class citizen. It requires thought, design, and care. It must be kept as clean as production code.
  • There are things that you might never do in a production environment that are perfectly fine in a test environment. Usually they involve issues of memory or CPU efficiency. But they never involve issues of cleanliness.
  • The number of asserts in a test ought to be minimised.
  • Minimise the number of asserts per concept and test just one concept per test function.
  • Tests should be F.I.R.S.T: Fast, Independent, Repeatable, Self-Validating, Timely.
  • Testing does not guarantee correctness. However, good testing can minimise risk.
  • The first rule of classes is that they should be small. The second rule of classes is that they should be smaller than that. 
  • Smaller is the primary rule when it comes to designing classes.
  • We should be able to write a brief description of the class in about 25 words, without using the words "if", "and", "or, or "but".
  • A class or module should have one, and only one, reason to change.
  • Classes should have one responsibility – one reason to change.
  • When classes lose cohesion, split them.
  • A system that is comprehensively tested and passes all of its tests all of the time is a testable system.
  • Systems that aren't testable aren't verifiable. A system that cannot be verified should never be deployed.
  • Making our systems testable pushes us toward a design where our classes are small and single purpose.
  • Tight coupling makes it difficult to write tests.