It is highly recommended to deliver completed user stories at the end of each iteration and so, you try to estimate the “size”/”cost” of a story. Ideally, each member can estimate the cost, but to estimate correcly, are you sure that the team members have the same definition of done? Whatever the domain, “done” can lead to ambiguity…

If you played to Mortal Kombat, you know that you can choose what done means

What user stories are can help us to define what done means

According to Wikipedia, an user story is:

A user story is a software system requirement formulated as one or more sentences in the everyday or business language of the user. User stories are used with Agile software development methodologies for the specification of requirements (together with acceptance tests). Each user story is limited, so it fits on a small paper note card—usually a 3×5 inches card—to ensure that it does not grow too large. The user stories should be written by the customers for a software project and are their main instrument to influence the development of the software.

Considering this definition, a completed user story is something which has value for the customer. In a developer’s point of view, it implies that the feature is implemented and that it can be seen by the customer. It means that a first definition of done may be: it works on my machine and the customer can test the feature on it. But we know that “it works on my machine” is terrible and we want to go deeper and so, this definition becomes: it works on any machine and the customer can test the feature(acceptance test).

The iceberg is bigger than its top

The problem with this definition is that it focuses only on the visible part of the iceberg (what the customer sees):

The customer sees only the top of the software (Credits: Mindtalk)

If your team doesn’t work/rework on the “invisible” things, you will quickly have troubles and you will have to pay the technical debt soon. Wikipedia references it as:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

So, whatever the feature, when someone of your team says that it’s done, your first questions may be: “Which unit tests have you written? Have you fixed any warnings from the compiler and from the static code analyzers? Are every previous automatic tests still green?”. All these points are so often ignored that, after few weeks, the software can’t evolve:

Technical debt effect (Credits: Jim HighSmith)

So, the definition of done might be:

it works on any machine, the customer can test the feature AND no automated tests is broken, there are new automated tests and no warnings/errors from compiler/static code analyzer.

Conclusion

When you estimate the size of an user story with your team, be sure that everybody has the same definition of done : it will avoid bad surprises. Each of us has to understand that technical debt has to be managed during the whole development.

So, does your team have the same definition? What is yours?

Work as a team

First, I need to come back on what a good programmer is for me. In his book “Refactoring: Improving the Design of Existing Code“, Martin Fowler wrote this quote:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand

I agree on his definition of good programmers. This value is so often taken into account when we talk about agile methodologies: pair programming or code ownership tries to limit the “compile-only” code or the common sentence “It works on my machine”. When you read code, it is important to be able to read it quickly : if you can’t, it is probably because you are in front of a technical debt and that this source code has to be improved. When you’re not the writer of it, before modifying/debugging it, you will have to understand the intent of the developer in order to avoid any regressions. It’s one of the reasons why Design Patterns are so important: using one of them, you clearly describe to others what you are trying to do, you put a name on it and it enables you to write code for humans.

I’m convinced that people who know design patterns are better than the others when they have to work as a team.You share a same common language!

Long-term value

The biggest deal of a paid developer is to find stuffs to learn/know which improve his/her value on the market. Nowadays, object oriented is clearly the most researched skill. When an employer wants to hire a developer, he/she will test his/her technical skills and his/her human skills (keep in mind that you want to hire technical talents). Knowing Java and/or C++ doesn’t indicate that you write “good” code. I have read so much code from C++ guy which is in fact… C code. Knowing Design patterns indicates to your future employer that you know what an object is and that you prefer composition to inheritance. And my point of view is that it’s a long-term value compared to knowing a language!

Learning cost is low

I’m a little bit mixed about the debate whether we have (or not) to know Design Patterns (reason of this post). In my opinion, it is a must-have skill and the learning cost is low: I don’t understand why a good developer don’t want to learn them. The first book (Design Patterns: elements of Reusable Object-Oriented Software) is a reference one and so, a bad one to learn them. I really recommend to read Head First Design Patterns (low cost and read in one week) and then, to keep a wonderful cheatsheet on your desktop (consult the list there).

So, as a conclusion, don’t worry about not knowing them, just invest few days to learn them. In my opinion, they are like a OOP’s degree : you can be good without it but your skills are easier to show when you have it.

Bjarne Stroustrup

I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone

It’s really what happened. Smartphones are easier and easier, but they are still more complicated than phone-only device! We often forget it!

You must connect your iphone to a computer to activate it the first time. Did you say "easy"? Credits: Hirotomo

John F. Woods

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

If you’re a developer, remember this one! It’s our job to write clean code. “It works!” is not enough, we are writing code for humans.

Imagine that he will maintain your code! Credits: Dark Knight

Cory Doctorow

Engineers are all basically high-functioning autistics who have no idea how normal people do stuff.

It’s from his novel Little Brother and most of the software which are built demonstrate this fact : unusable or useless.

Credits: Wondermark.com

Fred Brooks

Adding manpower to a late software project makes it later

This quote is from his book the Mythical Man Month and he states it as the Brooks’s Law. It is the hardest thing to understand for project managers that are not used to software projects.

Credits: stellman-greene.com

P. J. Plauger

My definition of an expert in any field is a person who knows enough about what’s really going on to be scared.

I like this definition: the title “expert” is so often overused! I still don’t know when we reach the expert stage…

Credits: doglegs.net

Boring presentation - Credits: Corbis

When you’re the talker, there are many possibilities why people don’t like your presentation:

• you repeat the same thing every time
• your topic is not relevant to their interest
• people don’t understand your ideas

These three points are extremely linked together: it’s your fault! Why don’t you:

• present the topic using an original approach
• consider your public in order to help them to solve their own problems
• make your ideas easier to understand (it doesn’t mean simplistic)

Create better presentations

If you have already read my blog, you know that I’m used to read books when I go into a topic. This time, I’ve chosen a best seller(I often choose my books by reading the reviews on Amazon): Presentation zen.

Presentation Zen: Simple ideas on presentation design and delivery

It’s from Garr Reynolds who is, according to Wikipedia:

Garr Reynolds is an American writer and designer. He is particularly known for his book Presentation Zen: Simple Ideas on Presentation Design and Delivery, and for two presentations, Brain Rules for Presenters and Career Advice ‘08. Reynolds is also a professor at the Kansai Gaidai University, and the former Manager of Worldwide User Group Relations at Apple Inc.

The book is well designed and well explained. It’s a pleasure to read it! Considering the quality of the paper, it’s really cheap! There are many samples which illustrate each idea. The “tool” Powerpoint is criticized: in fact, it gives bad habits to people. When you have to prepare a presentation, the first thing to do is not to launch Powerpoint! If you do this, it will clearly break your creativity and so, your presentation will probably be boring.

So how to do? There are four main sequential steps:

• Brainstorming: Don’t use a computer! Write everything you have in mind on the topic you will talk about. It doesn’t require to be ordered ideas… Write everything!
• Grouping and identifying the core: Group similar ideas and identify the unified message, it is what you want your public remembers after the presentation
• Storyboard off the computer: To be efficient, you have to tell a story: a good way is to print out blank slides, 12 slides per sheet. Then, draw inside the slides (one message per slide).
• Storyboarding in Slide Sorter view: Make a first draft of your slides on Powerpoint. Use the Slide sorter view to see whether it is fluent.

This process will help you to create a presentation which captivates your attendees. The book describes clearly the basic knowledge that everybody has to know about design.

But, when you have the storyboard of your presentation, each slide has to be cautiously built. Don’t write too much text, only few words. Use an image that your attendees can memorize because, it will be easier for them to remember this slide if there is an image. Use the contrast when you show a chart (example below), etc… You will learn that building a presentation is an interesting work.

Example of using efficiently the constrast (credits: presentation Zen)

I can’t give too much samples if I don’t want to be accused of “plaggia”, but I really recommend everybody to read this book. You will see how bad your presentations were and, particularly, how to improve them.

Metaphor are keys in software development

If you have read Code complete from Steve McConnell, you know that metaphors are really important to understand software building. In the section 2.1, we can read:

Important developments often arise out of analogies. By comparing a topic you understand poorly to something similar you understand better, you can come up with insights that result in a better understanding of the less-familiar topic. This use of metaphor is called “modeling.”

[...]

Software development is a younger field than most other sciences. It’s not yet mature enough to have a set of standard metaphors. Consequently, it has a profusion of complementary and conflicting metaphors. Some are better than others. Some are worse. How well you understand the metaphors determines how well you understand software development.

Steve McConnell uses metaphors to describe most of the concepts of his books and yes, it gives us the feeling that he’s a specialist of software (I’m convinced he is).

A good presentation on software development

So, how to present software development? Whatever the topic is, you have to tell a story which can be understood by all your attendees. Avoid judgments when someone doesn’t understand what you mean, your explanation can be the problem. Use metaphors in order to make your software development ideas/problems understandable by everyone.

Personally, I’ve recently tested this technique and people really liked it. And you, what is your tips to prepare a good presentation on software development?

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

These values are important to remember : before trying to learn Scrum or XP, just read them sometimes.

Do you know who are the authors of this manifesto? Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C.Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas. You can get their biographies here.

The books phenomenon

When we investigate a new domain, read a book is one of the most efficient way to get an overview. I’ve searched for books from these authors on Amazon and the results impressed me.

In order to share my feelings with you, I put here books from these authors if they are related to Agile approaches :

• every book which has “Agile” or “Agility” in its title
• every book which presents an Agile methodoly (Scrum, Extreme Programming, etc)
• every book which presents refactoring, testing, code quality or other technical stuff that are used to “responding to change”
• every book which presents pragmatic thinking and which is not related to a specific language  (Java, Ruby, etc)

Feelings are strange

Does the number of books from these authors impress you? Really? Evangelism is often required in order to make ideas popular : books are part of the system. And it’s amazing: each book has pretty good reviews on Amazon (min 4/5). They are good references on this domain and these guys have made a tremendous job for software engineering : I encourage every developer to subscribe to their feeds (most of them have a blog, search engines are your friends).

But it’s interesting to see an opposite view. In his post, “Good Agile, bad agile“, Steve Yegge (a “googler”) criticizes methodologies:

• anything that calls itself a “Methodology” is stupid, on general principle.
• anything that requires “evangelists” and offers seminars, exists soley for the purpose of making money.
• anything that never mentions any competition or alternatives is dubiously self-serving.
• anything that does diagrams with hand-wavy math is stupid, on general principle.

And by “stupid”, I mean it’s “incredibly brilliant marketing targeted at stupid people.”

Maybe, this view is not really objective and the biggest problem of Steve’s post is that Steve considers that the Google model can be replicated in any company, and for cultural history of others companies, it’s often wrong. And I disagree that, when you listen to others ideas, you’re stupid. But I agree with Steve on one point that we can observe when evangelism is too strong:

anything that never mentions any competition

Agile approaches don’t work with any type of projects

But currently, I worry about the “agility” word because it seems that it becomes a buzzword and most of us forget sometimes that Agile approaches are not silver-bullets:

• it’s hard to become agile
• agile is not always the most appropriate approach

The first point is always the one which is addressed when we say that it’s not a silver-bullet, but the second one is often forgotten. In his best-seller “Code complete“, Steve McConnell wrote:

In software, consultants sometimes tell you to buy into certain software-development methods to the exclusion of other methods. That’s unfortunate because if you buy into any single methodology 100 percent, you’ll see the whole world in terms of that methodology. In some instances, you’ll miss opportunities to use other methods better suited to your current problem.

Most of (all?) authors of the Agile manifesto agrees with the Steve’s view about methods. So, focus on this point !

When is agile relevant?

Danc gives a spectrum of Process Complexity in his post “Managing game design risk: Part I”

• Simple Processes: When both requirements and execution are quite certain, then the projects can be managed with relatively simple processes. Often a simple checklist does the trick. The repetative steps that a single worker performs on an assembly line is a good example of a simple task.
• Complicated: When the requirements and execution get out of hand slightly, you end up with a project that can still be completed with your typical check list. However, you need to increase the number of rule and steps necessary to accomplish the task. Bridge building is a good example of a complicated task.
• Complex: Many projects fall into the dangerous middle ground where requirements and execution is somewhat defined, but rife with multiple layers of uncertainty. In these situations, high feedback, agile processes let team steer their way towards ago despite high risk and uncertainty. Software development is a good example of a complex task.
• Chaotic Processes: When both requirements and execution uncertainty is very high, projects tend to devolve into unmanageable chaos. Success arises as often from luck as it does from any real process.

Agile is adapted to complex projects. For others kinds of projects, there’s probably a better way to manage them. If your project is complicated, you may have a look at Lean approaches or other methodologies. When you have a simple project, I think that the Waterfall way is a good one: you will always be more efficient if you can specify clearly the requirements at the beginning.

Conclusion

Don’t become an evangelist yourself : look at your project and decide which methodologies is the most adapted. Sometimes, Agile is not the right one but if you see that your requirements are far from agreement or certainty, Agile approaches are probably a good choice.

Do you think that you become an evangelist sometimes?

Study

In 90s, two professors of Harvard, Steven C.Wheelwright and Kim B.Clark have studied human productivity when we are working on many concurrent tasks (you can find this result in their book Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency and Quality). This chart gives the percent of time working on tasks relative to the number of concurrent tasks to do:

Multitasking & productivity

So, what do we see here? The highest productivity is reached when we have only two concurrent tasks. With more than two, we waste too much time on switching. With only one, when we’re blocked, we waste time. With two, you can work on a task and when you’re blocked, you switch to the other one. This result is easy to understand but it is too often forgotten by managers who wants to drive sometimes too many projects at the same time (and so, they give too much concurrent tasks to his/her team members -> but remember, they’re just human too…).

How to improve my productivity?

Okay, our management team can sometimes decrease our productivity when they give us too many tasks (maybe, it may be a good idea to show him/her this study). But, what about ourselves?

Today, if you have Internet at work, you probably add to yourself many tasks: read the last RSS feeds, see what is going on on Tweeter, look at your social networks, access to your personal emails… And now, you know that it decreases your productivity in a way you don’t want. So, try to keep you some time-breaks to manage your “personal concurrent tasks” but don’t work at the same time : just close them when you are working (yes, close the gmail tab .

Credits: dilbert.com

LeechBlock can help

If you’re a user of Firefox, I recommend you to install the LeechBlock extension:

LeechBlock is a simple productivity tool designed to block those time-wasting sites that can suck the life out of your working day. (You know: the ones that rhyme with ‘Blue Cube’, ‘Pie Face’, ‘Space Hook’, ‘Hash Pot’, ‘Sticky Media’, and the like.) All you need to do is specify which sites to block and when to block them.

You can specify up to six sets of sites to block, with different times and days for each set. You can block sites within fixed time periods (e.g., between 9am and 5pm), after a time limit (e.g., 10 minutes in every hour), or with a combination of time periods and time limit (e.g., 10 minutes in every hour between 9am and 5pm). You can also set a password for access to the extension options, just to slow you down in moments of weakness!

With this tool, the temptation is lower and you can configure it as you want.

Have you already try this kind of tools? Does it prevent you from being disturbed?

Facebook Friends - Credits Mc Morbid

At the beginning, I wasn’t convinced by the success of this kind of websites. Why do people want to share their personal life with 200 of their “friends”. Why would I want to say to everybody that I’m happy… that I love this group… and why would I want to share my private photos with these “friends”? Moreover, how can I accept to give all those informations to a website/company which consider that the data is its property… Maybe, I’m too paranoid on this topic!

But in fact, what are friends? What is behind this popular word? If you haven’t read this great book, I recommend this cheap best seller to you:

Each chapter is summarized in one sentence (it’s not enough to just read these sentences but, it’s nice to read them again after reading the book). I read it in French but the sentences are available on its wikipedia page. Some of them are really useful in order to consider the success of social network:

• Become genuinely interested in other people
• Be a good listener. Encourage others to talk about themselves
• Make the other person feel important and do it sincerely

Why these ones? Because when I ask to other people why they are using thiskind of networks, they answer me: I want to stay in touch with my “friends”. But, I’m convinced that they are using it in order to tell to every body what they are doing themselves. They want to say: I’ve done this, do you know? And I never see one of my “friend” who is saying “What you’ve done, I don’t care”! We just make a small interest, if it is nice, we say it… But if it is not, we don’t say anything.

I’m not a social network fan… But I try to understand why they have such a success… And one of my answer is: Others are genuinely interested in other people. They are good listeners and they encourage others to talk about themselves. They make me feel that I’m important…

And you, do you like social network? Do you use them?

In 6 years, the Eclipse project counts now 33 sub-projects and 24 millions Lines Of Code (LOC). The number of projects demonstrates that its incubator is really useful but, I don’t like to see the number of lines of code. In his article “Cannot Measure Productivity“, Martin Fowler wrote:

Any good developer knows that they can code the same stuff with huge variations in lines of code, furthermore code that’s well designed and factored will be shorter because it eliminates the duplication. Copy and paste programming leads to high LOC counts and poor design because it breeds duplication. You can prove this to yourself if you go at a program with a refactoring tool that supports Inline Method. Just using that on common routines should allow you to easy double the LOC count.

You would think that lines of code are dead, but it seems that every month I see productivity studies based on lines of code – even in such respected journals as IEEE Software that should know better.

Now this doesn’t mean that LOC is a completely useless measure, it’s pretty good at suggesting the size of a system. I can be pretty confident that a 100 KLOC system is bigger than a 10KLOC system. But if I’ve written the 100KLOC system in a year, and Joe writes the same system in 10KLOC during the same time, that doesn’t make me more productive. Indeed I would conclude that our productivities are about the same but my system is much more poorly designed.

What I mean is that, for a project of the size of Eclipse, the rise of this metric doesn’t provide any information. A project with 17 MLOC is as big as a project with 24 MLOC: they are both huge projects. What would be interesting to know is whether dead code is removed between releases or whether redundant code is refactored. Ohloh can give you an idea. For sample, if we’re looking at the MySQL project, we can get this chart:

Mysql - Ohloh - LOC

The fact that the number of LOC decreases sometimes can give us an hint on the project. We can hope that it is related to refactor/clean up sessions.

In summary, the number of lines of code provides only an idea of what the size of a project is. When the project is becoming bigger and bigger and that the size never decreases, refactoring stuffs are probably never done and the cost to enter in the code increases significantly.

Measuring progress by lines of code is like measuring aircraft building progress by weight, Bill Gates

NB: I only use the Eclipse chart to discuss about this metric, I like Eclipse and I don’t deduce that Eclipse developers don’t make any refactoring: this chart is not enough.

In object-oriented programming, an inner class (aka nested class) is a class declared entirely within the body of another class or interface. It is distinguished from a subclass.

In Java, we can illustrate this concept with this sample:

public final class Clazz {
  private final class InnerClazz implements Runnable {
    public InnerClazz() {
    }
 
    @Override
    public void run() {
      System.out.println("Hello world");
    }
  }
 
  public Clazz() {
  }
 
  public Runnable getRunnable(){
    return new InnerClazz();
  }
}

It’s a simple sample that does nothing useful but the declaration of inner classes is shown. I remark that the difference between nested classes and inner classes is not always understood by every developer.

Inner class

The previous code declares a nested class “InnerClazz”. A new instance of it is created each time the getRunnable method is called. If you analyze this code with FindBugs, you will have this warning:

SIC: Should be a static inner class (SIC_INNER_SHOULD_BE_STATIC)
This class is an inner class, but does not use its embedded reference to the object which created it.  This reference makes the instances of the class larger, and may keep the reference to the creator object alive longer than necessary.  If possible, the class should be made static.

The message is explicit: an inner class keeps a reference on its parent class and so, as long as the InnerClazz is referenced, the parent class can’t be garbage collected (there’s a strong reference between the inner class and its parent -> you may read on memory management). This kind of nested class is useful when you want to use the reference:

public final class Clazz {
  private final class InnerClazz implements Runnable {
    public InnerClazz() {
    }
 
    @Override
    public void run() {
      // print the value of a member of its "parent" class
      // it's possible because the inner class has an implicit reference
      // on the Clazz instance
      System.out.println(_currentNumber);
    }
  }
 
  private int _currentNumber = 0;
 
  public Clazz() {
  }
 
  public Runnable getRunnable() {
    _currentNumber++;
    return new InnerClazz();
  }
}

Nested but not inner class

If you don’t need to keep a strong reference between the instance of Clazz and InnerClazz, just declare InnerClazz as a static member class (now called NestedNotInnerClazz).

public final class Clazz {
  // static keyword is added
  static private final class NestedNotInnerClazz implements Runnable {
    public NestedNotInnerClazz() {
    }
 
    @Override
    public void run() {
      System.out.println("Hello world");
    }
  }
 
  public Clazz() {
  }
 
  public Runnable getRunnable(){
    return new NestedNotInnerClazz();
  }
}

Yes, it’s easy…

In computer science, garbage collection (GC) is a form of automatic memory management. The garbage collector, or just collector, attempts to reclaim garbage, or memory used by objects that are no longer in use by the application. Garbage collection was invented by John McCarthy around 1959 to solve the problems of manual memory management in Lisp.

In this post, we have a look at:

• when is the garbage collection triggered?
• how to know when objects are no longer in use?

This post is related to the Java platform but it’s probably the same principles on .net one.

Triggers of garbage collection

As you know, you can invoke garbage collection explicitly in your code:

System.gc();

The javadoc of this static method is:

Runs the garbage collector.

Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.

But it’s not recommended to use this explicit call. Findbugs considers that it’s a bug:

Dm: Explicit garbage collection; extremely dubious except in benchmarking code (DM_GC)
Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.

In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.

So, we have to rely on the mechanism provided by the platform. The Java HotSpot Virtual Machine uses a generational collection which means that the memory is divided in generations. Each generation holds objects of a different ages. The reason why this approach is used is that it exploits the weak generational hypothesis:

• Most objects die young (not referenced for a long time)
• Few references from older to younger objects exist

In HotSpot, the generations are:

• Young generation (green)
• Old generation (blue)

Memory - Credits: www.wilsonmar.com

The memory management whitepaper describes the life of an object through generations as:

Memory in the Java HotSpot virtual machine is organized into three generations: a young generation, an old generation, and a permanent generation. Most objects are initially allocated in the young generation. The old generation contains objects that have survived some number of young generation collections, as well as some large objects that may be allocated directly in the old generation. The permanent generation holds objects that the JVM finds convenient to have the garbage collector manage, such as objects describing classes and methods, as well as the classes and methods themselves.

The young generation consists of an area called Eden plus two smaller survivor spaces [...]. Most objects are initially allocated in Eden. (As mentioned, a few large objects may be allocated directly in the old generation.) The survivor spaces hold objects that have survived at least one young generation collection and have thus been given additional chances to die before being considered “old enough” to be promoted to the old generation. At any given time, one of the survivor spaces (labeled From in the figure) holds such objects, while the other is empty and remains unused until the next collection.

So, a minor garbage collection is triggered when the the eden is full and can promote survivor objects to the old generation. The major garbage collection is triggered when the tenured space is full. Note that a call to System.gc() launches a major GC.

What we need to remember is that minor GC and major GC consume CPU (there are more than one strategy for garbage collection but it is the subject of another post). Major GC is longer than minor GC. If you don’t choose the right values (options Xms, Xmx, etc) your application can launch too many garbage collections and so, its global performance will drop significatively.

Live objects

How does the garbage collector determine that an object is no more referenced? One of the most used algorithm is the mark-and-sweep one and it uses the following principle to determine whether an object live or not:

The objects that a program can access directly are those objects which are referenced by local variables on the processor stack as well as by any static variables that refer to objects. In the context of garbage collection, these variables are called the roots . An object is indirectly accessible if it is referenced by a field in some other (directly or indirectly) accessible object. An accessible object is said to be live. Conversely, an object which is not live is garbage.

Java memory leaks are often caused by adding object reference in a collection and never removing it. If your application has a cache system, it’s better to use weak references rather than a strong reference. The article of Wikipedia on weak references defines them as:

In computer programming, a weak reference is a reference that does not protect the referent object from collection by a garbage collector. An object referenced only by weak references is considered unreachable (or “weakly reachable”) and so may be collected at any time. Weak references are used to avoid keeping in memory referenced but unneeded objects.

Conclusion

In this post, garbage collectors are not deeply explained: the algorithms are not described precisely and it is just an abstact view that every developer has to know. To summarize:

• when the size of the memory is not adapted to your application, it implies too many garbage collections and it consumes CPU time
• most of the memory leaks are caused by strong references that are never released: when it is relevable, use weak/soft references instead.