Book Review: The ThoughtWorks Anthology – Essays on Software Technology and Innovation

The Thoughtworks Anthology provides a peek into a diverse set of topics, views and perspectives held by some of the Thoughtworks firm members. The book consists of thirteen insightful essays on modern software development practices, most of them challenging some long held views. The book is aimed at several different audiences right from Project Managers to Business Analysts to Developers to Testers. There is no single central idea to the book, and all the thirteen essays touch a wide range of topics. Not having technical expertise in some of the topics hampered my understanding and I skipped those; I wouldn’t comment much on them in this review. The quality of the different essays varies widely but in a word, for anybody in the software industry: Recommended

Various Chapter Highlights:

1) Solving the Business Software “Last Mile” – by Roy Singham, Founder and Chairman, and Michael Robinson, Technology Principal.

While newer processes like Agile, SCRUM and TDD have allowed us to deliver high-quality software quickly, it still hasn’t helped us resolve the problem of “the last mile”. In the author’s words “This “last mile” is the part of the process that happens after the software satisfies the functional requirements but before the software goes into production and starts to deliver value to the business”. This essay was easily my best pick in the entire group of essays, and was worth the entire book alone. How many projects that we have worked in go “live” as quickly as it is produced?

2) One Lair and Twenty Ruby DSLs – by Martin Fowler, Chief Scientist

3) The Lush Landscape of Languages – by Rebecca J. Parsons, CTO

Nothing too new. If you need to refresh your memory about the difference between various programming language, then read through this essay.

4) Polyglot Programming – by Neal Ford
The author in this essay start off by explaining what polygot programming is by saying "The word polyglot means speaking many languages. Polyglot programming leverages the separation of language and platform in Java (and in C# as well), allowing developers to use specialized languages to solve specific problems. We now have hundreds of languages that run on the Java virtual machine and the .NET managed runtime. Yet, as developers, we don’t leverage this capability enough.". In the next few sections, they show us some examples of applying polygot programming. Didn’t understand much.

5) Object Calisthenics – by Jeff Bay, Technology Principal
A really thought provoking essay. While we all code in our day-to-day lives, the author suggests nine rules to code, which could make programming easier to understand and large project code respositories easier to handle:
i. Use only one level of indentation per method
ii. Don’t use the else keyword
iii. Wrap all primitives and strings
iv. Use only one dot per line
v. Don’t abbreviate
vi. Keep all entities small
vii. Don’t use any classes with more than two instance variables
viii. Use first-class collections
ix. Don’t use any getters/setters/properties.

6) What is an Iteration Manager anyways? – by Tiffany Lentz, Project Manager

This essay provided some new insights into the role of the SCRUM Masters and Iteration Managers as opposed to the traditional Project Managers. It talks about the roles and responsibilities and restrictions with an IM. While many people believe that the IM is just a weaker version of the Project Manager, this essay explains how this is not true, and how the two roles are quite independent in their job profiles

7) Project Vital Signs – by Stelios Pantazopoulos, Iteration Manager

If you are reviewing a project, in the middle of, say, the 10th iteration, when the project is a 20 iteration project, how do you gauge the “health” of the project? The author here comes up with some quantitative metrics, called Project Vital Signs, which help an outsider identify the “health” of the project:
i. Scope burn-up: The state of scope delivery for a deadline
ii. Delivery quality: The state of the end product being delivered
iii. Budget burn-down: The state of the budget in terms of scope delivery
iv. Current state of implementation: The real-time state of the system delivery
v. Team perceptions: The team perspective on the state of the project (Personally, my favorite...something new)

8) Consumer-Driven Contracts: A Service Evolution Pattern – by Ian Robinson, Architect

Do your SOA from the consumer side not the provider side, excellent idea.

9) Domain Annotations – by Erik Doernenburg, Technology Principal
This essay advocates the use of domain-driven design, which follows the idea that during development, the primary focus should be on the domain and the domain logic. Should be very interesting for those into domain-driven design

10) Refactoring Ant Build Files – by Julian Simpson, Build Architect

11) Single-Click Software Release – by Dave Farley, Technology Principal

If you are planning on building an end-to-end continuous integration release systems that will deploy large, complex applications to whichever environment we choose at the click of a button, then this is the chapter you need to read. The essay had some good points for the deployment process

12) Agile vs. Waterfall Testing for Enterprise Web Apps – by Kristan Vingrys, QA Consultant

This essay gives a good overview of the testing life cycle, the different types of testing, and testing environments. The first few sections narrating this should help refresh the testing news and views that are well known. The author then covers topics such as issue management, the tools you need to use for testing purposes, reports and metrics. The essay is concluded with discussing the testing roles for different members.

13) Pragmatic Performance Testing – by James Bull, QA Consultant

This essay gives us an insight about what performance testing is, and gives detailed explanation about the four key elements: requirements, product performance data, communication, and process. The author concludes this essay by explaining how to link all these together, how not to drop behind, and finally how to bring an issue resolution process to close. Again, nothing new, something we have been hearing for long, but do not imbibe quite frequently in our day-to-day proceedings.

Altogether, some really good essays, some just fillers, but overall the book is quite relevant, timely and definitely recommended.