Category Archives: Books

Book review: Breaking the Spell

Why do all societies we know of practice some form of religion? Either religion must be “true”, or there must be some sort of natural explanation for this universal phenomenon.

Breaking the Spell
Breaking the Spell

Breaking the Spell” by Daniel Dennett presents avenues of research into these explanation. He does not profess to have the answers to this question, or even the right question. He merely sets out to prove that the questions are important ones and ones that we can hope to gain insight into.

Dennett is a philosopher, and he has explained the role of philosophers with an analogy: A philosopher watching a magician sawing a lady in two offers an explanation: “You see, the magician is not really sawing the lady in two. He merely makes it appear as if he is sawing her in two.” When asked, “so how does he do that”, the philosopher answers “I’m sorry, that’s somebody else’s department.”

This story undersells Dennett and his books, of course. I have been a fan of Dan Dennett for over ten years. His accessible books “Darwin’s Dangerous Idea” and “Consciousness Explained” have radically shaped my understanding of evolution and the brain. “Breaking the Spell” does the same with religion.

So, if religion has a natural explanation, what could this explanation be? Obviously, something in our evolutionary history has made us religious. Does this mean that religion is good for us, or rather, that it helped our ancestors survive? Not necessarily. Dennett shows how certain traits that could’ve been good for us, like susceptibility to the placebo effect and a disposition to interpret events to be caused by an actor, could’ve made the human mind susceptible to other ideas, or memes as well. As long as these ideas don’t cause the “host” fatal damage and they can spread to other “hosts”, such ideas would become widespread, even if they were (moderately) harmful to those who bear them.

This hypothesis is also explored by Dennett in one of his several talks for the TED-conference:

The question for the final part of the book, then, is what effect religion has on it’s adherents and society at large. When does it help us and when does it harm us? Dennett suggests experiments that could further explore this subject, but doesn’t offer definite evidence for any hypothesis.

The weakness of the book is that it spends quite a bit of time excusing itself to hypothetical fundamentalist readers. Even if you believe your religion is true, Dennett points out, you must wonder where all the other religions came from. Even if you believe your religion is true, you must wonder what effect other religions have on society.

I wish the book had spent more time exploring the issue at hand (why religion might exist, what effect it has) and less time excusing the validity of the question. But it’s an enjoyable read and gave plenty of food for thought.

Dennett remains my favorite philosopher author.

Be sure to check out Dennett’s great presentations on the web:

Posted in Books, English, Non-technical | 6 Comments

Book review: Predictably Irrational

Summer is starting
Summer is starting

“Predictably Irrational” is a perfect book for lazy summer days on the beach or, in this case, while enjoying a beer from top of Oslo’s tallest office building.

Dan Ariely is on a bit of a crusade against traditional economics, with it’s idea of rational behavior from everyone in the marketplace. Instead of this (strawman) economics, he uses experiments to explore what he calls “behavioral economics”. The book is focuses particularly on how our behavior often is not at all rational.

The book is enjoyable, and Dan Ariely’s style is easy to digest. However, the free online videos of him talking are even more enjoyable.

Some of my favorite sections:

The Context of Our Character

The experiments that first made me aware of Dan Ariely is those that explore what makes people cheat more and what makes people cheat less. This is the subject of a great TED-talk, titled “Why we think it’s OK to cheat and steal (sometimes)”:

The Cost of Zero Cost

The Cost of Zero Cost talks about how “zero” is a very special price. The experiment: If you let people choose between a good chocolate at 14 cents and a cheap chocolate for free, traditional economics predicts that preferences will be the same in a choice between a 15 cent good chocolate or a 1 cent cheap chocolate. Ariely demonstrates how this is not the case.

The effect of zero cost has been discussed lately by the likes of Seth Godin and Malcolm Gladwell. This particular discussion springs out of Chris Anderson’s recent book Free.

The price of zero has been one of YouTube’s great strengths. However, as Malcolm Gladwell points out, it is also carries a slight downside: YouTube doesn’t make any money.

The Verdict

The book was a pleasant little read, but ultimately, disappointing. Let me explain:

Before I bought the book, I watched all the videos I found about the subject on YouTube. After having seen these, the only area which the book gave me any further insight was that of zero price.

Ironically, the book suffers from Malcolm Gladwell’s skepticism about “Free”: Giving away information for free will give you a lot of attention, but might undercut the reason for people to give you money.

If you want a pleasant read on the beach, “Predictably Irrational” might be for you. If you just want to learn about “behavioral economics”, watch Dan Ariely’s videos instead:

Posted in Books, English, Non-technical | 1 Comment

Book review: A question of torture

After receiving request to revive my book reviews, I’ve decided to blog about books I read again.

If a known terrorist in police custody knew the whereabouts of a ticking bomb about to explode in a large city, would the use of torture be acceptable? Would it be helpful? I stumbled across Alfred McCoy through The program impressed me so much that I decided to pick up his book A Question of Torture.

A Question of Torture

In the book, McCoy examines the history of coercive techniques from the fifties until the present. He makes the case that the so-called “few bad apples” in Abu Ghraib in fact were using techniques directly from the CIA’s playbook on torture. These techniques focus on sensory deprivation (such as hooding and prolonged isolation), self-inflicted pain (such as prolonged standing and other “stress positions”), humiliation (such as forced nudity), and sensory disorientation (such as loud music and sleep deprivation) and they do constitute torture.

Some of the questions raised and answered in this frightening book:

  • How does torture and coercive methods compare to noncoercive methods when it comes to getting useful information? This is in a sense the difference between the effectivenesss of CIA and FBI in “the war on terror”.
  • What long term effects does torture have on its victims?
  • What is the effect on those who commit torture?
  • What is the strategic effect of employing torture as a weapon in a war, such as the use of torture and summary executions by the CIA in Vietnam and France in Algers? McCoy unstated claim is that in a sense, the CIA’s Phoenix-program cost the US the Vietnam war.
  • Can the use of torture ever be effectively limited to avoid torturing innocent civilians?

The book offers a resounding indictment of torture on practical, but more importantly, on moral grounds.

The academic style of the book makes it a bit hard to read. At times, it feels like a collage of quotations. On the other hand, this means that it contains well-documented, important and disturbing claims. In the end, this made it into a very quick read.

Posted in Books, English, Non-technical | 1 Comment

Book Review: The Cuckoo’s Egg

I read an extremely intesting book last week. Cliff Stoll’s “The Cuckoo’s Egg” is a true story about how the author was tracking a hacker in the mid-eighties. It reads like a spy novel, but is appearently all true. I picked the book up at 11 at night, and was unable to put it down until I had completed the whole thing!

The book gives a pretty good understanding of computer crime, crimefighting, and the basic methods of the typical script kiddie. The exploits that the bad guy uses are all real vulnerabilities, but happily, they are all (mostly) corrected today.

Despite its technical detail and accuracy, the book should be accessible to the general public. I highly recommend it!

Posted in Books | 4 Comments

Book Review: User Stories Applied

I bought User Stories Applied to get help with practical problems with writing good user stories and requirements in general, but it ended up changing the way I think about requirements and tracking them.

The book first fullfills one very important mission. It answers “what is a good user story” with a mnemonic rule: Independent, Negotiable, Valuable, Estimatable, Small, and Testable (INVEST). Cohn refers to William Wake as the source of this mnemonic, but expands further upon how to achieve it. For me, the most useful parts of the book was the explainations of some of the more difficult points of extreme programming’s Planning Game, such as how to split up large stories, how to estimate the effort, where to get the stories from (Cohn’s suggests using the technique User Role Modeling), and how to deal with a lack of a “real customer.” Towards the end, Cohn compares User Stories to Use Cases. For me, the discussion revealed some of the weak points of Use Cases. Based on User Stories Applied, I feel confident that the Planning Game from extreme programming addresses requirement management sufficiently for very many projects.

Reading the book made me realise the different faces of requirements and where user stories fit in. There are requirement types for which user stories may not be appropriate, but they will probably still help. More on this in later.

If you are managing requirements, especially in an agile context, this book is a must-read.

Posted in Books | Comments Off on Book Review: User Stories Applied

Book review: Domain-Driven Design


The first thing that strikes me about Eric Evans “Domain-Driven Design: Tackling Complexity in the Heart of Software” is how it seems to bring together the ideas that have resounded the best with me during the last few years. The central thesis of the book is that that enterprise software should to be built around the model that (non-software) experts in the field has of the problem domain. The shared understanding between the software developers and the domain experts and users facilitates communication. And also: In many domains, there are advanced models that have stood the test of time (for example double-entry bookkeeping). Reinventing such models is not the best thing software developers could spend their time doing.

The model driven design effort is based around the shared discovery of a ubiquitous language that is shared by the development team and the customers.

The part of the book that was most useful to me was Part III: Refactoring Toward Deeper Insight. Unique in the books I have read about modeling, Evans claims that a model that does not evolve is dead (or at least fossilized), and is a sign of failure for the project to be useful. This is in congruence with Robert Glass’s observation in “Facts and Fallacies of Software Engineering”: The most valuable programs are changed, as the users discover new needs. Evans describes how to keep a design supple by strategies that build on and extend the recommendations of Extreme Programming.

I only have two practical problems with the Domain-Driven Design approach.

  • The software development projects I have been involved with lately has used technology that constains the design. The technologies are also so technically challenging that the development team don’t have the time to focus on the domain model.

  • No software project is an island. Practicing domain driven design is hard in the face of legacy systems that the team must maintain or integrate with.

Evans addresses both of these topics, but I feel only the last is answered to my satisfaction.

The question of domain-driven design with the current technological trends is an interesting one. I feel a lot of vendors (but not all) are trying to sell technology that constrains the design further. The worst example IMHO is Enterprise JavaBeans. This is an example of a framework that is invasive, inflexible, and constraining. However, from the open-source scene, the current trend seems to be more in congruence with domain-driven design. IoC/Dependency Injection, AOP, and Naked-Objects are my favorite examples of paradigms where the goal of the frameworks is to get the technology out of the hair of the development team. “Domain-Driven Development” spells out the argument for such tools, even though Evans does not address this aspect directly.

I think this is the only failing of “Domain-Driven Development” as a book. Evans explains in detail a host of useful techniques for working in a domain-driven world. I feel the ideas are important enough to warrant more of a manifesto-like book. The book is great for implementing Domain-Driven Design once you have sold management and the team on the idea. There is a need for something something shorter and more persuasive as an introduction to the subject. Subjects like technology interaction with the domain-driven design should be explored further.

All in all, this book is not for everyone. I feel domain-driven development as a focus for developing software in the future is an essensial paradigm. However, Evans goes into too much details on the techniques, and the book ends up being a heavy read for anyone who just want to get an idea of what domain-driven development is about.

Posted in Books, Software Development | Comments Off on Book review: Domain-Driven Design

Book Review: The Art of Unix Programming

I was recommended “The Art of UNIX Programming” by Eric Raymond (esr) from Joel Spolsky’s “Joel-On-Software” blog. The recommendation in it self warrants some comments, as Joel Spolsky normally is very much a Windows-kind of guy. Despite the title, the book definately has much to offer people who never touch UNIX as well.

esr focuses on the cultural aspects as much as the technical aspects. For organisations that are migrating into Unix infrastructure the ramifications of the Unix culture can be hard to grasp. In my experience, no other technical platform has as strong of a culture. esr does an excellent job of explaining the Unix mindset and how it influences the software on the platform. The heavy use of case studies from big open-source Unix projects helped me understand the factors very well. I was amused by the examples esr choose in the case-study of the cookie-jar format. I generally disagree with the political views of esr, but he is considerate enough to only preach Unix-philosophy in this book. (esr’s political writings define as extreme left-wing what in Norway would be considered the most right-wing parties. Oh well)

What I loved most about this book was probably its treatment of open-source. The subject of open-source is of course not specific to the Unix world. esr covers as diverse subjects as the economic justifications, the schism between the Free Software Foundation and the Open Source Initiative, practical management of open-source projects, and legal implications of open-source licenses. If you are considering using open-source in your organisation (and you really should be, if you are not already), you need to read the Licensing Issues of chapter 16. It is available online. Go ahead, read it now!

This section is directed to commercial developers considering incorporating software that falls under one of these standard licenses into closed-source products.

Having gone through all this legal verbiage, the expected thing for us to do at this point is to utter a somber disclaimer to the effect that we are not lawyers, and that if you have any doubts about the legality of something you want to do with open-source software, you should immediately consult a lawyer.

With all due respect to the legal profession, this would be fearful nonsense. The language of these licenses is as clear as legalese gets — they were written to be clear — and should not be at all hard to understand if you read it carefully. The lawyers and courts are actually more confused than you are. The law of software rights is murky, and case law on open-source licenses is (as of mid-2003) nonexistent; no one has ever been sued under them.


Three things I took with me from this book:

  • A lot of program design heuristics and ideas

  • Better understanding of the open-source model

  • An appreciation for the legacy and future of Unix

Posted in Books, Software Development | Comments Off on Book Review: The Art of Unix Programming

Book Review: Agile Software Development

If a beginning programmer was to read just one book, this would definately rank high on a list of candidates. (But then again, why should a beginning programmer only read one book)

“Agile Software Development: Practices, Principles, and Patterns” is in many ways Robert C. Martin’s magnum opus. After having read much of his papers on Dependency Inversion Principe, the Open-Closed Principle and other object-oriented methods, as well as Extreme Programming, Agile Software Development puts it all together. More than any other book I have read, possibly including Beck’s excellent “Test-Driven Development”, Agile Software Development makes a very strong case for writing the test before the code. Most of the examples in the book, even when Martin does not talk about testing, start out by writing a test to explain a concept. The book goes a long way to normalize the sensibilities of Extreme Programming.

As the full title implies, Agile Software Development spans a wide range of subjects. The book starts off explaining Agile software development and Extreme Programming in some depth before covering principles of program design. While using a lot of examples and good case studies to clearify his points, Martin then goes on to explain, each in it’s own natural time, 14 of the most crucial design patterns from Gang of Four, as well as a few from other sources. Agile Software Development does not study each pattern in as much depth as the gang of four, but the author provides a good trade-off between giving the motivation for each pattern, explaining the mechanics of the pattern and putting it into context.

All in all, the book tours a great number of subjects that are critical to the design and implementation of software projects. I would be much relieved about the competency of any colleague if I knew this book was on the list of books he or she had read. More than explaining the basics, Martin argues for why and when they are important and just as importantly: when they should be ignored.

But the Satire of Two Companies in the appendix is just lame. ;-)

Posted in Books, Software Development | Comments Off on Book Review: Agile Software Development

Book review: Lean Software Development

Update: Cleaned up mess made by “WYSIWYG” tool)

Rating: Must-buy

The agile movement has started to gain speed and become more mainstream, and the Poppendiecks’s “Lean Software Development” added an important part of the puzzle for me.

Like so many manifestos before it, Lean Software Development compares software development to other industries (lean thinking takes its roots in the Toyota manifacturing system). However, the authors reach a very different set of conclusions. The crux is to not compare the practices that were useful in other industries, but the principles underlying these practices. The ideas developed in the book are very much like the agile manifesto.

Lean Thinking uses the following principles (each described in a separate chapter in the book):

  1. Eliminate waste
  2. Amplify learning
  3. Decide as late as possible
  4. Deliver as fast as possible
  5. Empower the team
  6. Build integrity in
  7. See the whole

As you might notice, the list is not specific to software development. Each chapter is rich in great examples, both from the software industry and other industries of how to do and not do lean thinking. One of the greatest parts of the book is the table comparing the wastes in manifacturing to the wastes in software development:

Manufacturing Software My Notes
Overproduction Extra Features CHAOS report: 40% of s/w features are never used
Inventory Work in progress The background for iterative development
Extra processing Unused artifacts Artifacts should have an “eager customer”
Motion Finding information XP: “Customer on-site”
Defects Defects
Waiting Waiting Includes customer waiting for the product
Transportation Handoffs XP: “One team”

As the table shows, “Lean Software Development” very much supports the position of Agile software methods, but adds a new facet to the discussion: Why does agile work, and where can we see similar ideas bringing success in the non-software world. In conclusion: Why agile makes business sense.

If you are addressing software from a business point of view, or if you are trying to convince people why Agile development is a good idea from a business point of view, you need this book.

Posted in Books, Software Development | Comments Off on Book review: Lean Software Development

Book review: Beyond Software Architecture

Beyond Software Architecture (Luke Hohmann) is an invaluable read for any aspiring project manager or program manager. There is so much more to getting successful programs out the door than just the classical analysis, design, development, test.

The most important feature of this book is how it helps frame software development in a larger picture. The point of software development is to create value for someone. It is important not to lose sight of that fact. There is more to value than just features, and Hohmann gives a good overview. My only problem with the book is that I found it to be a little encyclopedic at times. This does not detract from the value, but it makes it a little harder to read.

My favorite part of the book is the introduction of the concepts of marchitecture and tarchitecture, and Hohmann’s descriptions of the very important marchitectural considerations that must be present for a development effort to be successful.

I am sure there is much more to this subject than is covered by the book. I am also sure there is much more to know about each subject. For someone like me, who likes to get a full understanding of the activity that is software development, it provides a good introduction to an important part.

I recommend this book if you are currently or in the future planning on being project manager, program manager or (t)architect on a software project. It is a fairly quick read, and covers a lot of ground.

Posted in Books, Software Development | Leave a comment