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."

The Four Types of Test Double: Dummy, Stub, Fake, Mock

A test double is a pretend object used in place of a real object for testing purposes. The four types of test double are as follows:

Dummy

• 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.

Stub

• 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.

Fake

• 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).

Mock

• 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)

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.

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)