How to Motivate Developers - A three step framework

No . . . . not THOSE three steps!

Anyway, now that we're approaching the end of the calendar year, invariably many folks are filling out self-evaluations and managers are presiding over year-end reviews, and choosing raises and bonuses for their staff.

Managers should also be considering the year ahead and one of the most important aspects - developer productivity. A key element of productivity is motivation and this article tries to answer the question "How to motivate developers".

But first some comments on prior work . . . .

There have been quite a few blog articles written by others on this topic (see some references below). They're pretty solid but they're mostly written from the perspective of
1) Developers or
2) Managers who don't have a major technical background.

The problem with #1 is that self-reporting of what a person wants is very unreliable. Often people don't really know what they want. Or they know what they want but don't truly understand how it will make them feel or for how long (see this really great article on happiness for some more insights)

The issue with #2 is that, without knowing the perspective of the other side (developers understanding what it means to be a manager and vice-versa) the full picture is often lacking.

One thing I noticed in my research for this post is that many of the articles below try to ask "What do developer's want?". That's important but a bit misleading. For example take a more common situation - housework. I don't want to do the dishes - I'd rather be playing Call of Duty 4 - but I *have* to. For many reasons - the sanitary one is obvious - the not so obvious one . . . . my wife will kill me otherwise :-) So what's my motivation - good health and staying alive :-) What motivates me isn't what I want.

There's also another aspect to this that I feel people haven't considered. I am going to venture (without citation . . . I couldn't find one) that the majority of a person's motivation is intrinsically determined. That is - their motivation level is largely driven by who they are, their personalities and things in their lives you have no control over.

So please don't get the idea from this that I believe one can control 100% of a developer's motivation. You can influence it, but only so much. In many respects motivation should be a key aspect when interviewing new team members - because once they're hired you can only impact a relatively small aspect of their motivational make-up. Again that's based on experience - I'm not aware of any scientific studies to confirm this hypothesis.

To repeat, I feel that, to a large extent, people are already largely motivated or not. You can improve things quite a bit though. Say you could make a developer 5-10% more effective - that's like having an extra 2 weeks to a month of their development time each year.

That's a lot of extra bugs fixed or new features produced. Do that across a team of 6-8 developers and you can make a very noticeable improvement.


Anyway after thinking about it - from both a managerial and developer perspective, here's what I've come up with for my framework.

STEP 1) Compensate Well
This is one of those "necessary but not sufficient" conditions you often hear about. You can address every other motivational item but if you don't pay well and give good benefits you're shooting yourself in the foot and worst of all people are going to go elsewhere. Probably most of all you're just not going to be able to attract and retain really good (i.e. already motivated) developers.

If you think of the famous Maslow's Hierarchy of needs, this is one of those fundamental "lower" or more basic needs.



STEP 2) Remove or reduce demotivating aspects
You can pay all the money in the world to people but if you have non-existent specs, unrealistic deadlines, micro-manage etc. people aren't going to be motivated for long and they will quickly become unmotivated or leave.

As I just stated there are several things that many developers experience that drive them batty.
i) Poor requirements - there's nothing worse than building junk but consequently (for me at least) there's nothing better than great (detailed, unambiguous) requirements and the resulting happy users.

ii) Unrealistic deadlines - whether this results in 90 hour+ weeks or buggy software - this is very much a drain on developers, their ego and sense of pride. Developers want to be proud of their work and go home and see their families. Is that too much to ask?

Yes everyone has crunch times and there's invariably some extra unforeseen work but hopefully it's infrequent and as a manager hopefully you don't have to "go to the bank" too often.

iii) Too many meetings - I've found that the more formal a place is (or the less friendly it is) the more meetings you need to just get people to talk to each other. But many meetings are a bad sign - ideally developers would/should be able to talk to each other and meetings should be "organic" and not forced.

iv) Disrespectful or uncooperative colleagues. "Bad apples" can ruin a whole batch. The problem is exacerbated when management is unaware of them or worse, is aware, but refuses to do what it takes to remedy the situation.

v) Processes, Tools or Techniques that slow you down e.g. slow builds, slow unit tests, slow desktops etc. They suck productivity and reduce enthusiasm.

vi) A poor work environment e.g. a place where it's too loud, there's no privacy, you get lots of interruptions etc.. A bad environment can destroy motivation or at the very least be a distraction. And distractions are TERRIBLE for a developer's focus on the problem at hand.

Either way, my recommendation is that before focusing on MOTIVATING factors, I would focus on removal or amelioration of demotivating factors. There's also some evidence that there is some psychological difference between demotivating aspects and motivational factors.

The good thing is by focusing on these e.g. improving requirements, reducing unnecessary meetings, speeding up processes etc. you are also improving team productivity even if there's no motivational boost to be had. But that's unlikely - removing some of those impediments should buy you some good will - but frequently that fades over time. Either way, for the productivity boost alone that's makes good business sense.

STEP 3) Focus on positive motivational aspects.

Here are the things that you really are hoping will translate into more motivated (and more productive and happy) developers

i) Support Developer Learning
Developers love to learn - new languages, new tools, new frameworks. Spring, Ajax, Hibernate, Ruby - that gets their juices flowing. Now the challenge is how do you direct that to produce the product you're paid to . . . . . the key here is to align the new item with key gaps needing filling. Need an Object-Relational Mapping system - Hibernate! Need a rapid prototyping language - Ruby! etc. You also need to factor in the productivity dip as they learn.

ii) Provide Challenges & Problem Solving Opportunities
Developers in general love to solve problems - whether it's how to integrate new features into a legacy system, how best to compare two lists of strings or how to make a system more scalable developers love such problems.

In my experience however there are sub-types - different developers who prefer different kinds of challenges - ideally again you would align the challenge to the person who wants it!

iii) Provide Feedback
Developers want to learn and grow - beyond the technical learning / challenge they also need feedback in other ways to help them grow as individuals and adapt to their organization. Often I find this is where management falls down. Who could blame them / us - we often say we're open to hearing about areas needing improving but not so good in practice. I've found the Sandwich Feedback Technique works quite well though.

iv) Other Ideas
See the section below for other really good ideas from other articles

These are all the things that "developers" want, in the sense of the higher "self actualizing" levels of Maslow's hierarchy. Again, these factors should not be detached from "conditions on the ground" as it were.

For example I've known a few developer's whose idea of self-actualizing was deciding what to eat for lunch that day. They didn't want to learn ANYTHING new - no new languages, no new environments - they know what they have and don't want to change. Their motivation isn't going to take a boost from being asked to learn something - on the contrary.

STEP 4) The Secret Step - Fear as motivator
OK I said there were three steps, but here's that "magic" 4th step. The "nuclear option". Go here only when you must e.g. you or someone on your team might be fired unless some action is taken, a client could lose a lot of money etc.

As with the "doing the dishes" analogy, there comes a point when you have to do what you don't want to do. You do it because the ramifications of not doing it are worse - MUCH worse.

Often if you're seen as the "good cop", you need a "bad cop" to make this work. Sometimes you might need to be the "bad cop". Most folks know the analogy having seen it many times on the various CSI or Law & Order shows on TV.

Basically the line here is "Do this or you'll lose your bonus / won't get a raise / be fired".

As I said you can't rely on using this too often, but you need to be sure also that people know the chance is there. Developers are smart people - if you don't follow through on what you promise you lose credibility. This lesson on follow-through was something that my two year old taught me. "If you don't get down from that chair, you'll get a timeout". Guess what, unless you start handing out "timeouts" they just will continue to stand on that chair.

Again you don't want to do it too often and when you do you need to explain the reasons, it can't be seen to be arbitrary. For example - fire too many people, and people will start updating their resumes and looking elsewhere rather than live in fear. Don't fire anybody and you send the message that there are no consequences and people want to leave because they tire of supporting the slackers. It's a fine line but most of your strong developers already can identify who isn't pulling their weight and will thank you for pulling the trigger and finding someone better.

Anyway there's my thoughts on developer motivation - I look forward to your comments.


REFERENCES TO RELATED WORK

Nine things developers want more than money
1) Being Set up to Succeed
- Good requirements
- Realistic Deadlines
"Being forced to build crap is one of the worst things you can do to a craftsman"
2) Having Excellent Management
3) Learning New Things
4) Exercising Creativity and Solving the right kind of problems
5) Having a voice
"When a developer speaks, someone should listen. When several developers are saying the same thing, someone should listen and act . . .quickly"
6) Being Recognized for Hard Work
7) Building Something that Matters
8) Building Software without an Act of Congress
9) Having Few Legacy Constraints

Top 10 ways to motivate geeks
1) Geeks are curious. Let them feed their desire to learn things
2) Geeks like to be self-sustaining. Let them figure things out on their own.
3) Geeks are creative even if they don't know it. Give them a chance.
4) Geeks need tools, good ones. Give them more than they need.
5) Private, yet collaborative. Geeks need to be left alone, but not too alone.
6) Free stuff. T-shirts, food, desktop widgets, whatever.
7) Control
8) Geeks need recognition
9) Freedom
10) Compensation - Saved this for last, but geeks gotta live too

Motivating Software Developers
1) Allow me to focus
2) Allow me to feel that I am making progress
3) Allow me to make something I can take pride in
4) Allow me to do it for me, not for the money
5) Allow me to work on interesting problems
6) Allow me to be part of a team
7) Allow my ideas to be taken seriously

What motivates software developers?
1) Introduce new technologies and techniques
2) Practice pair programming to encourage communication, sharing of skills and team building
3) Encourage participation in community developer events (user groups, code camps), blogs (share links across the team), books (monthly bookshelf anyone?) and conferences.
4) Avoid generalized training - in my opinion this tends to serve the paycheck programmer more than the dedicated ones.
5) Interesting projects
6) Satisfy your customer

Motivating Software Developers

To Motivate or not to demotivate
"Only taking away the things that make people dissatisfied, will simply result in people having neutral feelings towards their jobs."

Some programming principles: People

Managing and Motivating Developers: Tips for Management Cluefulness

What makes people tick - 10 motivation factors in the workplace

"The first thing to note here is that most people are motivated by:
1. doing interesting stuff
2. feeling recognized and appreciated
3. making an impact"

What motivates programmers?

11 ways to motivate geeks

Five things your manager could be doing better

To Beta or not to Beta - That is the question

"Whether 'tis nobler in the mind to suffer the slings and arrows of outrageous bugs, Or to take arms against a sea of defects, And by opposing end them." (with props to Bill S.)

In the past few years it's become more and more acceptable to release "Beta" software to the public - almost as if it was a production release.

The reasons for that I believe are manifold but boil down to
1) Gain user feedback
2) Release early to gain "mindshare" and/or get first to market.
3) Your QA process or team isn't that great (or your unwilling to spend money on them) and you'd rather have users do your testing for you.
4) You need to gain the confidence of your customers / investors in what you're building.

The number one proponent of the Beta, I must say is Google. I've been a Google Docs user for well over a year now and I love it - but it's still in Beta. The one thing I don't love is the FREQUENT UI changes in direction though - but hey it's a Beta and it hasn't lost a Document or Spreadsheet of mine yet.

But it's clear from using what Google call a "Beta" that their goals are really predominantly #1 (user feedback) and probably to a lesser extent #2 (mindshare). It's been very well tested (internally) before it hits the public. You can read more of what Google think about Betas here.

So the quality of their Betas is quite high (see also gmail) and a Beta for them is probably a production release for 90% of everyone else.

Here's the problem though - in making Beta's "popular" I think they (and others) have lowered the bar at least insofar as management can now look at it and say "Well if Google did it - why can't we?". So there's a tendency now to ship lower quality software and at the last minute people decide to slap a "Beta" label on it if it's not up to snuff so that they can declare victory. Then they hope people will use it as if it was production quality.

Personally I think software professionals should be using a public "Beta" ONLY as a last resort. If you need to gain user feedback - try not to be cheap about it. Get a bunch of potential users in a room and have them use your product - try not to prime them - just watch them. Video them. Understand what are they trying to do - how does that align with your product? Can you make your application so easy to use it doesn't need a manual? That should be the goal (although that might be ultimately unattainable any progress in making your application easy to use is good).

If the reason is #2 (to be first to market) then I think you don't understand technology trends. Neither Google or Internet Explorer (or Firefox) were first to market - look where Yahoo! and Netscape are now.

I guess I never really "got" the whole first-mover advantage thing. Think about it:

• Apple vs. Windows (and back again)
• Ford vs. Toyota
• Betamax vs. VHS
• Atari vs. Nintendo
• WordPerfect / WordStar vs. Office
• Friendster vs. Facebook vs. MySpace
  

The anecdotal lesson I got from these cases was to NOT be first mover and learn from the other guy and where he fails.

Anyway if you're in the position of #3 (you're not investing in your QA team/process) then that's a sorry state of affairs. Although we live in a world of finite resources - finite dollars and hard-to-find tech experts so I guess it can be excusable sometimes. But if you just punted to force your users to do the bulk of your testing work then shame on you.

If you're in position #4 - releasing a Beta to the public to gain confidence well it's hard to argue too much with that given the sorry state of "production" software these days (*cough* Vista *cough*) people's expectations are sadly low so its understandable people (especially investors, customers) want some reassurance.

Don't get me wrong on this though - I'm not the type of guy to wait until the product is perfect. It's more a question of what are your motivations and are you being lazy in releasing a Beta? If you want user feedback - GET USERS and GET THEIR FEEDBACK! Don't ship junk!

After doing some Googling I came across a blog article with similar sentiments
A call for revolution against Beta Culture

"I'm mostly tired about the fact that it seems that we all have given up. Tired because . . . . in reality, it's laziness and a poor job on the manufacturer part that we have accepted without questioning. Instead of calling foul play and refusing to participate, we keep buying."

"That's the key: We have surrendered in the name of progress and marketing and product cycles and consumerism."

Right on man - it just doesn't feel right. It feels lazy and short-sighted.

Here are some other thoughts by other folks

• Don't Blow your Beta
• Does Beta really mean Beta?
• Alpha, Beta and Sometimes Gamma
• The myth of first-mover advantage
  

So here's my question to you, dear reader, what is your opinion on Betas? Useful software engineering technique or cop-out?

JarFinder.com - Where have you been all my life?

Ever have that moment where you discover a great little tool and you wonder "Where have you been all my life?"

Well I had that moment today when I finally came across http://www.jarfinder.com/

Ever have a hard time tracking down which Jar a class belongs to?

My bane is org.apache.xml.serializer.Serializer

It turns out it's in Xalan of all places (and I can never seem to remember that).

Now with http://www.jarfinder.com/ you don't have to struggle anymore to find the jar that contains that class file.

Turns out this has been out there since at least early 2006 - wow.

Book Review: The Definitive Guide to Terracotta

(Please Note: Apress, the publishers, kindy offered me a Java book to review for my blog. I accepted and out of > 100 options I chose this one due to my love of all things scalability and because Terracotta seems to address a hard problem of distributed cooperation within clusters. Anyway I guess the point is, I got this book for free, some may consider this places me in a slight position of a conflict-of-interest, some may not care. I certainly don't believe it has colored my view of this book - but you, dear reader, should be aware nonetheless. In any event I am certainly appreciative to Apress.)

Over the past few years as principal engineer / architect (and back again) I've faced a couple of hard problems which I'm sure many of you have too. Once you get to an architecture where you have more than one JVM or server, how do you quickly and easily share information across them? Yes the database is one easy solution but the performance / scalability hit in "always going to the database" becomes quickly onerous.

Then one decides to cache to reduce this load but now how to you keep caches in synch?

Then one might go down the path of deciding to use some messaging system (e.g. JMS, Tibco, WebSphereMQ etc.) to ease intercommunication but there the amount of coding, testing and debugging needed due to the complexity of this roll-your-own solution becomes quite problematic.

Another similar problem comes where you have a load balancer in front of your web / app servers for performance, DR and HA reasons and you have some stateful application (like most web sites are today). How can you share easily session information across servers to make for a seamless experience?

So for all of these problems that's where something like Terracotta comes in. It basically sits between your application and the JVM and allows you to declaratively define what information is to be shared across JVMs. It promises to do so without any code changes (nice!).

A compelling product to say the least. Anyway, in a bid to learn more about this product I decided to review this book.


TITLE: The Definitive Guide to Terracotta: Cluster the JVM for Spring, Hibernate and POJO Scalability
AUTHORS: Terracotta, Inc.
ADDALL: Link


CHAPTER 1 Theory and Foundation: Forming a Common Understanding
The first chapter starts by laying some foundation and defining terms - always a good start. "Terracotta is a transparent clustering service for Java applications" is the mantra and they go on to explain what this term means. They proceed to talk about how the underlying memory model that Terracotta gives you (across JVMs) is now transparent to the application.

They discuss at a high level how the service provides you advantages such as high availability, scalability (scale-out) and improved performance (by not requiring a DB hit to share information).

As examples, they cover the classic use-cases of Terracotta
1) Distributed Caching
2) Database Offload
3) Session Replication
4) Workload partitioning


CHAPTER 2 History of Terracotta
Chapter two discusses the forces that resulted in the creation of Terracotta - from the forces to scale out rather than scale-up (e.g., preference for loose coupling, availability of cheap commodity hardware, cheapness of linux etc.).

But with scale-out comes the problem of keeping JVMs / Servers in synch. The solutions such as
1) Scale the Database
2) In-memory replication
3) Partitioning the data

each came with their own problems.

And so Terracotta came into being. Whereas folks such as Amazon (and eBay) took the approach of "eventual correctness" (aka "eventual consistency") where each application instance could complete transactions to local disk and eventually flush to the database, Terracotta's founders chose another solution as their business folks were "not prepared to discuss the ramifications of an eventually correct architecture, where users might be told that a previously confirmed purchase order could not be completed because of miscalculations in inventory long after checkout completed".

And so they sought to effectively create a "General Purpose L2" cache. The original implementation was too intrusive where developers would often forget to serialize and replicate changes to L2-based objects to keep things in synch and this led to regressions and eventually to a significant slow down in the pace of development.

With Scalability and Availability often becoming opposing forces it was refreshing that their solution aided both. The transparency of the solution also does not necessitate the need of one programming model over another e.g. EJB vs. Spring or JPA vs. Hibernate vs. iBatis.

CHAPTER 3 Jumping Into Terracotta
Ah here we go - C O D E! They literally start off with a simple (clustered) "Hello World!" example and start to get into how to configure Terracotta. I wish they had spent some more time here, perhaps a whole chapter, helping someone set-up a REALLY good environment (say multi-machine, or at least an env for multiple programs operating simultaneously) - a lot of this is left up to the user to figure out, let alone perform. That I think dilutes the message of Terracotta and doesn't give the reader a good "WOW" factor when they see this in operation.

In any event we start to get into the "meat" here and discover how Terracotta ensures all changes to shared data have been applied before a read is performed. And just after a write, Terracotta ensures that all memory changes are made available to other Java processes that might need them.


CHAPTER 4 POJO Clustering
So having seen a quick example they correctly now need to dive in to expain how Terracotta handles Java objects and the virtual heap and secondly explain how Terracotta manages thread coordination between JVMs.

They define a "root" - a field in any class that you declare as being clustered. Terracotta traverses the graph of object references from that root to cluster those objects too. Since these objects are clustered and durable beyond the scope of a single JVM they are sometimes referred to as "superstatic" - having the same lifecycle as the virtual heap.

Typically data structures like Map, List and other Collection objects are chosen as root objects.

Terracotta is pretty smart since not EVERY object on the virtual heap needs to be instantiated in every JVM. Terracotta can load an object as needed. Just like the virtual memory subsystem of a modern OS swaps contents to and from physical memory and disk, Terracotta lets your application behave as if there was an almost unlimited physical Java heap.

Then comes information on such topics as Distributed Garbage Collection and how threads are coordinated - again the details are such that there are no real surprises or "tricks" here - the folks at Terracotta have really taken Transparency to heart. "Terracotta provides exactly the same access serialization, coordination and visibility guarantees to threads in different JVMs as the JVM itself provides to threads within the same JVM".

Then we get into more meaty topics of locks in Terracotta and how Terracotta extends the concept of locking. Again by using declarative methods they help keep much of the messy coding inherent in locking out of the developers hands and keep it where it belongs - in the Terracotta infrastructure.

From there we leap to Terracotta "transactions" wherein Terracotta batches changes made to objects into sets, helping to ensure that threads always see a consistent view of clustered objects.
From there we delve into what kinds of objects are not "Portable" (cluster-able with Terracotta) e.g. file-system related classes such as java.io.FileDescriptor (host-machine specific) and instances of java.lang.Thread (JVM-specific) are some examples.

Interestingly there is also the concept of "Physically vs. Logically managed objects" . The former are objects wherein their field data values are distributed to the Terracotta server and from there to the other cluster members. The later (Logically managed) are clustered by Terracotta by recording the method calls on those objects and their arguments and replaying them on the other members of the cluster.

Examples of logically-managed objects are Hashtable, HashMap and HashSet (spot the common theme?) - yes that's because the Hashcodes used to create the internal structure of the object are JVM-specific.

From there we get more into understanding Clustered POJOs but personally I felt much of this information was repeated either earlier or later in the book. But after that there's a more fully formed example used to elucidate much of what was discussed earlier in the chapter.

CHAPTER 5 Caching
We begin this chapter with a discussion of caching and the trade-offs and problems it incurs

• Space for time
• Freshness
• Complexity
• Durability
• Duplication of data across caches

Then a quick example shows how Terracotta can be used to quickly provide a distributed cache.
From there we delve into which of the Map structures are best for such data structures within Terracotta. Interestingly ConcurrentHashMap is generally the best choice when sharing maps but sadly LinkedHashMap is not supported by Terracotta. Harumph!

Then we get into some of the gory details of caching that we all need to know

• Eviction and Expiration policies
• Persistence
• Distributed Caching (again I felt this was repetitive)
• Use of partitioned data

Interestingly they claim that it is largely by avoiding serialization (typical of transmitting updates through a cluster using more traditional methods) they gain a very significant part of the performance improvement of their product.

From there we get a quick example with Ehcache (Easy Hibernate cache) and then onto chapter 6.

CHAPTER 6 Hibernate with Terracotta
I found this to be my favorite chapter - quite a bit more details in it than other chapters, good solid examples, and the benefits of the product become abundantly clear.

We start off with a great overview of Hibernate and how Terracotta can be used to improve it - by clustering the second-level Hibernate cache and also by using it to cluster Hibernate session objects.

From there we get a good example of how Hibernate and Terracotta together can be used to save on DB hits. Hibernate's cache runs the risk of staleness if another JVM updates data in the Db and so Terracotta helps fill this gap by preventing such staleness issues.

Then we get some great stuff lacking in other books - HARD NUMBERS!
Hibernate clustered with Terracotta gave a 4x boost over Hibernate with second-level cache alone when focused on DB updates. When focused on DB reads, we get a > 250x boost. Naturally your mileage may vary but at least we're getting some good ideas of what to expect.

We now get into the details of configuring Hibernate to be aware of Terracotta and vice-versa. All straightforward and relatively simple stuff.


CHAPTER 7 Extending HTTP Sessions with Terracotta
This was another good chapter on how to share HTTP Session information across JVMs, servers using Terracotta. A very useful feature that helps avoid most of the problems associated with persisting HTTP session information to afford your cluster the ability to scale-out, be HA etc.

Yet again we see the Transparency of Terracotta as it transparently (to your web app) hooks into the servlet container. From there we get a few nice examples to see all of this works with Tomcat. Fortunately Terracotta supports the following web / app servers

• WebLogic
• WebSphere
• Jetty
• Apache Geronimo
• JBoss

and the following frameworks

• Struts 1.1
• RIFE
• Wicket

CHAPTER 8 Clustering Spring
Here we get a pretty short chapter where basically the point is you can point Terracotta at Spring beans rather than declare each class / field yet again in your Terracotta config file.

CHAPTER 9 Integration Modules
Terracotta supports the idea of external configuration for a component you might be shipping that takes advantage of Terracotta's features. This allows you to ship a Jar and the user of that jar then does not need to include Terracotta config information for this component into their own Terracotta config.

This feature is called a "Terracotta Integration Module" or TIM. It consists of config info and perhaps code that specifies how the component should be clustered, how locking is performed etc. They then go on to describe how TIMs are created, used and configured.

CHAPTER 10 Thread Coordination
This chapter seemed like it should have been more up front, also it's quite short and I thought there would be more here. They get into some of the details of thread coordination in relation to Terracotta. I got something out of this chapter - I'm just not sure exactly what it was.

CHAPTER 11 Grid Computing Using Terracotta
Naturally Terracotta lends itself to Grid computing i.e. supporting the splitting of a workload across nodes. From there we get into the "Master/Worker" pattern and an implementation in Java and then into how to refactor the original example for improved performance / scalability by reducing contention, batching work, multiple work queues, addressing fault tolerance.

CHAPTER 12 Visualizing Applications
Finally in chapter 12 we learn about visualization techniques and tools to help you comprehend what a cluster is doing and why it is going slow or fast. They show many metrics the tools capture and what they reveal and how they can be used to tune your application.

REVIEW SUMMARY
This is a rock-solid book with a solid introduction. I wouldn't agree that it's a "Definitive Guide" - but I guess that's just an Apress standard naming convention (the same way Manning has the "In Action" series).

I'd like to have seem more help up front in getting your environment set-up for the examples, some case-studies of how Terracotta has been used, more benchmarks, perhaps even benchmark code. But given the fact that it's the ONLY book I can find on Terracotta it's fortunately pretty good and gets you "in the game".

Clearly Terracotta can't have infinite scalability - Terracotta must communicate between JVMs over the network so a guide of best practices, practical limits etc. would have been useful on things such as how to optimize network architecture, data structure design / optimization etc. would have been great.

PROS: Relatively Short and to-the-point. Examples are simple and straightforward.

CONS: Not enough examples. Not enough code. Would be nice to have them help you set up an environment. Would have been nice to see some more hard numbers of performance / scalability boost over other solutions. Quite a bit of repetition - typical of books written by teams without a clear "separation of concerns".

GRADE: B+

BUY IT? If you're using starting to use Terracotta - absolutely. If you're interested in making your application faster or scaling-out in general - probably.

A sad passing

Randy Pausch sadly lost his life to Pancreatic Cancer. He was 47.

Link

His life, his work and his brave struggle against indomitable odds (Pancreatic cancer has a 5% survival rate after 5 years) was an inspiration to many. He is survived by his wife and three young children - 6, 3 and 2.

Wherever he is, his spirit I'm sure continues that quest for knowledge and to share that knowledge with others.

To quote T. S. Eliot

"We shall not cease from exploration, and the end of all our exploring will be to arrive where we started and know the place for the first time. "