Concurrency: Past and Present
Brian Goetz discusses the difficulties of creating multithreaded programs correctly, incorrect synchronization, race conditions, deadlock, STM, concurrency, alternatives to threads, Erlang, Scala.
Tracking change and innovation in the enterprise software development community

Posted by Amr Elssamadisy on Nov 06, 2007 12:07 PM
Kent Beck's new book, Implementation Patterns, is a book about writing code in Java. The patterns in this book are based on Kent's reading of existing code as well as his own programming habits. These patterns are about developers communicating through code which is reminiscent of his earlier work on Smalltalk Patterns. They are lower level than design patterns and about the same granularity as Larman's GRASP patterns. The patterns in this book are meant to be a coherent view of how to write code people can understand that serves human as well as economic needs.
Spring App Platform, Java Concurrency/Multicore, Eclipse Mylyn and more @ QCon SF Nov 19-21
Six Free Project Management Certification Training Courses
Gamma's Jazz platform's first implementation: Rational Team Concert (Trial Download)
JProbe Freeware – Eclipse Plugin for efficient memory analysis and diagnosis
Guide to Calculating ROI with Terracotta Open Source JVM Clustering
Of course, the notion of what is good code - let alone great code - is one that not all developers will agree upon. Kent presents his Theory of Programming as foundation for discriminating code quality. In Chapter 3, after a couple of introductory chapters, one on the goal of the book and the other on patterns, Kent describes two cross-cutting concerns in programming: values and principles.
The values are the universal overarching themes of programming. When I am working well, I hold dear the importance of communicating with other people, removing excess complexity from my code, and keeping my options open. These values - communication, simplicity, and flexibility - color every decision I make while programming.
The principles described here aren't as far-reaching or pervasive as the values, but each one is expressed by many of the patterns. The principles bridge between the values, which are universal but often difficult to apply directly, and the patterns, which are clear to apply but specific. ... Faced with ambiguity, understanding the principles allows me to "make something up" that is consistent with the rest of my practice and likely to turn out well.
Kent then discusses the values and principles in detail. The patterns in the book all refer back to the values and principles - they help the developer understand how each pattern helps achieve the larger objectives.
The values are:
The principles are:
This chapter is followed by a chapter on the motivation - mainly economic motivation - that drives software development. Simply put, we put most of our time in maintenance of software. The cost of change, in turn, is the sum of understanding the code, changing the code, testing the code, and finally deploying the code.
The patterns are written in essay format and cover everything from when you should create a data field in a class, to equality methods, to subclassing. The patterns are grouped into chapters by:
Some examples of the patterns covered are as follows: (Kent presents them much more elegantly than the summaries here.)
Kent provides us with his experience in an elegant and concise format (the entire book, with appendices, is 156 pages). He does not give rules, but gives values, principles, and rules of thumb:
There is no universal rule. Programmers need to think, communicate, and learn. That's part of being professional.
This is a book that is useful for both junior as well as senior developers - each will come away with something different. Those new to software development will see development through the eyes of one of the most talented developers today. Others with more experience will be able to reflect on why they do things the way they do - practices take on a different meaning by focusing on why they are done. Finally, tying the values and principles (but especially the values) to software development makes everything different - in a very good way.
The values and principles discussion sound like the one from XP2. How does it differ from it and does it? What about the accountability Kent emphasises on so much and what about testing. Kent being one of the two JUnit guys and now an Agitar fellow the Implementation patterns should deal with testability as well? I also hope to reflect the stuff I'm doing. And become better at teaching these values, principles and patterns to my fellow developers. I'd really liked to have the Implementation Patterns as a Pattern Language as described by Kevlin, Frank and Doug in POSA5. There you have everything: vision, values, context, practices and pattern influencing context and each other in their application. I already wrote Kent on this. Unfortunately he thinks that covering XP and Implementation Patterns inside a pattern language distracts the reader to much from its core essence. Imho it would gain a lot from reevaluation as a pattern language. Another question ist the applicability of patterns. To decide when and how to apply a pattern and when to choos not to apply it. This ist the most difficult part for most developers. So I'm looking forward for my preorder to get here. Did you review the manuscript or the printed book? Michael
The values and principles discussion sound like the one from XP2. How does it differ from it and does it?
It is the same approach - values and principles - as in XP Explained, v2. The values are a subset of the XP values, which I assume is because programming is only a subset of the XP practices. As for principles, they diverge even more.
As for pattern languages... This book reads very well. Kent's style is - IMHO - much clearer. Part of it is personal preference, the other part is the book itself is simple.
Finally, I reviewed an early edition from the publisher and just got my official print yesterday.
Brian Goetz discusses the difficulties of creating multithreaded programs correctly, incorrect synchronization, race conditions, deadlock, STM, concurrency, alternatives to threads, Erlang, Scala.
Often the hardest part of changing technologies is language syntax differences. This new article provides Java developers with a transition guide to Actionscript which forms the foundation of Flex.
Neal Ford talks about having multiple languages running on one of the two major platforms: Java and .NET. He also presents the advantages offered by Ruby compared to static languages like Java or C#.
David Anderson talks about the history of Agile, the current status of it and his vision for the future. The role of Agile consists in finding ways to implement its principles.
Nick Sieger talks about the future of JRuby, Java Integration, and his work on JEE deployment tools for Ruby on Rails like Warbler.
Rustan Leino and Mike Barnett of Microsoft Research discuss the technology in Spec# and its futures.
Henrik Kniberg talks about 10 possible reasons to fail while doing Scrum and XP. Maybe the team does not have a definition of what Done means to them, or they don't know what their velocity is.
This article outlines 9 principles Marc Lammers discovered while building the world’s best field hockey team, mapping them to software development practices.
2 comments
Reply