book-review – ://ewernli

Drive

drive The key message of “Drive“, from Daniel H. Pink, is that people are best engaged in a task when they understand the purpose of the job, they can develop the necessary mastery to realise the job, and they have sufficient autonomy to direct things their way.

That’s a very simple framework — purpose, mastery, autonomy — and I very much like it.

The problem with the book is that beside this simple message, there’s little more. The book presents scientific studies to backup the ideas and tries to trace the evolution of these ideas. It’s entertaining but very annectodical. The second half of the book has a “toolkit” to reflect on motivation, summaries of the book, a glossary, and even conversation starters. In themselves, these are creative ideas. But it did feel a bit like milking the content.

One idea that is somehow developped in the book and that differ from the main framework is the difference between intrinsic and extrasinc motivation. Instinsic motivation is way stronger. If the activity, like playing a game, is the reward itself, there’s no need of an external reward. Or maybe the activity is not the reward itself, but we understand the reward ourselves, without external inputs. We know how to kill intrisinc motivation (pay somebody to do what he would do for free), but how to foster it is very challenging.

The question of how to develop engagement is actually a very intersting one. It’s not only interesting in the context of the workplace, but also in education, or social community.

This book has a nice message. I just wished it had more depth.

Masterminds of Programming

Masterminds of Programming features exclusive interviews with the creators of popular programming languages. Over 400+ pages, the book collects the views of these inventors over varying topics such as language design, backward compatibility, software complexity, developer productivity, or innovation.

Interestingly, there isn’t so much about language design in the book. The creation of a language seems to happen out of necessity, and the design itself is mostly the realization of an intuitive vision based on gut feelings and bold opinions. The authors’ judgments about trade-offs (e.g. static or dynamic typing, or security vs performance) are surprisingly unbalanced, and when asked to explain the rationale for some design choices, explanation tends to be rather scarce.

Instead, the authors describe with passion the influences that led them to a particular design. The book contains thus a good deal of historical information about the context in which each language was born.

C++ was invented to enable system programming with objects
Awk was invented to easily process data in a UNIX fashion
Basic was invented to teach students programming
LUA was invented to easily script components
Haskell was invented to unify the functional programming language community
SQL was invented to query relational database with an approachable language
Objective-C was invented to bring objects to the C world
Java was invented to provide a secure language in a networked world
C# was invented as the strategic language for the modern Microsoft platform .NET
UML was invented as the unification of modeling languages
Postscript was invented to enable flexible typesetting and printing
Eiffel was invented to make objects robust with contracts

Both the interviewers and interviewees are knowledgeable and articulate. The inventors smoothly distill their experience and insights during semi-structured interviews. Throughout the book, discussions remain mostly general, which both a plus and a minus: the material is accessible to all, but multiple sections have a low information density. The book could be easily shortened with a better editing.

Discussion about software engineering in general turned out to be the one I enjoyed most. Some of the interesting ideas touched in the book were for instance:

Simulating projects help acquire experience faster, p.254
Classes are units of progress in a system, p.255
We need of an economic model of software, p.266
Object-oriented programming and immutability are compatible, p.315
What UML is good for: useful for data modelling, moderately useful for system decomposition, not so useful for dynamic things, p.342
Generating code from UML is a terrible idea, p.339
There’s no software crisis; it’s overplayed for shock value, p.354
How broken HTML is, and how better it would have been if the web had started with a typesetting language like postscript, p.405

These points come from the late interviews, but there are similarly nice bits and pieces in all chapters; it just turned out that I starting taking notes only half through the book.

Amongst the recurring themes, the notion of simplicity pops out and is discussed multiple times, at the language level and a the software level. Several interviewees quote Einstein’s “Simple as possible, but not simpler”, and emphasize the concepts of minimalism and purity, each in their own way.

The book is also very good at instilling curiosity about unknown languages. I was initially tempted to skip chapters about languages I didn’t know, and am glad that I didn’t. Stack-based languages like Forth and Postscript appear as examples of a powerful but underlooked paradigm; the chapter about awk almost reconciled me with bash scripting; and the discussion about UML made me reconsider its success—the fact that the whole industry agreed on a common notation for basic language constructs shouldn’t be taken for granted.

In conclusion, this book isn’t essential, but it is enjoyable if you are an all-rounder with some time ahead, you appreciate thinking aloud, and good discussions around a cup of coffee.

The New Digital Age

The New Digital Age explores the impact of internet connectivity and digital media on society. The book witnesses changes that have already occurred, reviews current trends, and tries to predict some future moves.

Written by Eric Schmidt, a tech executive, and Jared Cohen, a former foreign policy advisor, the book focuses on the impact of technology at the political and societal level, not so much at the individual level (only the first chapter “Our future selves” is about it). I applaud this ambitious agenda.

People interested in technology and cyber criminality (e.g. TED talks, Wired) might be familiar with some of the observations and speculations in the book. The novelty that it carries will depend on the background of the reader. Some of the predictions are however unique to the authors, and they do not hesitate to give their personal opinions. This gives a special edge to the matter.

The trends and predictions are usually backed up with short annectodical evidences that are interesting in themselves. The overall discussion remains however usually quite abstract, which at times gives the impression that it lacks substance. This is to be expected from such a book, though. Prediction and precision don’t match up very well.

My main criticism of the book is that while the chapters tell a consistent story of how society evolves with periods of peacetime, revolution, conflict, and reconstruction, the chapter internals do not enjoy such a coherent treatment. The predictions that they discuss appear to exist more by accident than as the outcome of a thorough analysis. For instance, I do not recall reading anything about electronic voting. This seems to me like an unavoidable topic for such a book.

The book gives also a slight feeling of redundancy. Certain topics are discussed from a different point of view from chapter to chapter. For instance, the tension between privacy and security is discussed under the perspective of state organization, militantism, counter terrorism, etc. An improvement for a second edition would be to provide a roadmap of recurring topics and their treatment in each chapter. That would give a high-level view of the content, and would avoid this unpleasant feeling of redundancy.

While the positions in the book are relatively balanced, the overall tone is inevitably biased towards US policy, which is no suprise given Jared Cohen’s background. Also, the book emphasizes tracking and surveillance a lot and will make proponents of an anonymous internet uneasy.

Overall, I liked the book. The themes addressed are very relevant and it sharpened my understanding of the role of technology in modern society. What the future will really bring, nobody knows.

Debuggers: Theory and Practice

In “Not on the shelves“, Greg Wilson writes reviews about non-existing books, including one called “Debuggers: Theory and Practice”. It’s an entertaining and insightful read.

It made me curious about how such a book could look like and I gathered a selection of interesting articles about debugging and tried to organize them in a few sections. I wish I were more knowledable on the topic and had enough references to split section III into one section “exploring executions” and another one “strategies for debugging”.

Part I: Foundation

Chapter 1: Failures, Errors, Faults
Chapter 2: What is Debugging?
Chapter 3: Debuggers are Reflective Programs

Part II: Reproducing Bugs (Reproducing Failures)

Chapter 1: Every bug is a test not yet written
Chapter 2: Record and Replay
Chapter 3: Execution Synthesis
Chapter 4: Reproducing Crashes with Recrash

Part III: Fixing Bugs (Identifying Faults)

Chapter 1: The Art of System.out
Chapter 2: Asking Why Questions with the Whyline
Chapter 3: Scriptable Time-Travel Debugging with First-Class Trace
Chapter 4: Back-in-Time Alias Debugging
Chapter 5: Object-centric Debugger
Chapter 6: Debugging Concurrent Programs

Pharo By Example

This is an introduction book to Smalltalk and the Pharo development environment. The book is split in two parts: the first one covers the Smalltalk language, the Pharo IDE, the Morphic package for GUI application and the Seaside framework for web application. The second part is relatively thin and covers more advanced topics such as reflection.

The book is easy to read, with many examples to follow, and the reader will quickly acquire a good comprehension of Smalltalk. The object-oriented concepts specific to Smalltalk are however rigorously discussed. A good example would be the paragraph about class variables in case of a class inheritance: it’s easy to follow in the book but still an OO concept that could be otherwise misunderstood. These paragraphs are the most important one for people (like me) coming from other OO languages.

The GUI and web frameworks are briefly covered but enough to get a idea of how to they work. Both are component-based, and a concrete component is built from A to Z in both cases to get insight about the frameworks.

The second part about reflection is where the beauty of Smalltalk shines. First the concept behing meta-object and reflection are presented and then a few useful patterns which use reflection are described, for instance how to build a dynamic proxy in Smalltalk. This is clearly the most interesting part, where the dynamic nature of Smalltalk can be exploited in a constructive way.

Software Evolution

Software evolution studies software engineering under the perspective of software maintenance and change management. The term was coined in the 70 after the seminal work of Lehman and his laws of software evolution.

As such, software evolution is a topic as broad as software engineering itself – any aspect of software engineering (being a process, methodology, tool, or technique) can indeed be studied under the perspective of software evolution.

The book is a comprehensive overview of the current body of knowledge in software evolution. It contains 10 chapters addressing each one a specific field of software engineering under the perspective of software evolution. The articles present recent works and open challenges; the book can then be seen as comprehensive survey as well as a research agenda. The book bibliography is impressive and more than 500 articles are referenced throughout the 10 chapters.

Apart from this selection of articles, the book has an excellent introduction the field of software evolution, and a set of useful appendices pointing to additional resources in this field. The 10 chapters are organized into 3 parts:

Part I: Program understanding and analysis

Identifying and Removing Software Clones
Analysing Software Repositories to Understand Software Evolution
Predicting Bugs from History

Part II: Re-engineering

Object-Oriented Reengineering
Migration of Legacy Information Systems
Architectural Transformations: From Legacy to Three-Tier and Services

Part III: Novel trends in software evolution

On the Interplay Between Software Testing and Evolution and its Effect on Program Comprehension
Evolution Issues in Aspect-Oriented Programming
Software Architecture Evolution
Empirical Studies of Open Source Evolution

Chapters I enjoyed the most were “Object-oriented reengineering”, “On the interplay between…” and “Evolution Issues in AOP”.

I wish there was a chapter about evolutionary issues in model-driven engineering, which is an important area of research. I therefore would recommend “Model-Driven Software Evolution: A Research Agenda” as a complement to this book.

The book is accessible to non-expert and I learned a lot while reading it. The book is definitively worth looking at for anyone interested to understand what “software evolution” is all about.

Introduction to Reliable Distributed Programming

This book discusses distributed algorithms in the context of reliable application development. The algorithms are described intuitively and presented in pseudo-code as well. Even though this is an academic book, it is not too theoretical and is easy to follow. Theoretical complexity of the algorithms was for instance omitted on purpose.

The book presents the programming abstraction incrementally. It starts first with a recap of time abstractions and then builds a stack of algorithms in the following way: network and link abstractions, broadcast abstractions, shared memory abstractions, and consensus abstractions. The last chapter is about programming models used in real systems, for instance group communication or state machine replication.

If you are eager to learn how stuff work under the hood or want to have solid foundations to address reliable distributed programming, I recommend this book. I enjoyed reading it, but would have appreciated a bit more coverage of programming models in the last chapter.

97 Things Every Software Architect Should Know

This book is a collection of 97 articles, written by various authors, about software engineering and architecture. The articles are short (no more than 2 pages) and easy to read. Each one is focused on one principle.

The book is not a definitive receipe on how to conduct a project and be sucessful. It’s rather a set of – more or less generic – advices to think about: did I had similar experience? Should I remember this advice next time I start a project? Is this advice relevant in my position? etc.

What is nice about the book is that it covers a wide spectrum of problems faced when building a piece of software. There are not only reflexions about technology, but also communication issues, risk management, managing people motivation, taste and opinions, the necessity of having a vision and a leader, etc. What matters utlimately is the delivery of a solution that addresses the real customer problems.

My top 10 favorites are:

“Perfect” is the Enemy of “Good Enough”

Great software is not built, it is grown

If there is only one solution, get a second opinion

Make sure the simple stuff is simple

Shortcuts now are paid back with interest later

Prefer principles, axioms and analogies to opinion and taste

Simplify essential complexity; diminish accidental complexity

Your system is legacy, design for it.

Simplicity before generality, use before reuse

Everything will ultimately fail