Builder-style setters for Java

Setters idiom in Java is an evil and I hate it. And I don't hate it because you have to invoke setXXX methods multiple times when you have to set many fields. The most annoying thing for me is that you can only set one field in a line. This is because setter method return this stupid void. Here is the example:

public class Car {
  private int maxSpeed;
  // remainder omitted

  public void setMaxSpeed(int maxSpeed) {
    this.maxSpeed = maxSpeed;
  }
  // remainder omitted
}

so my code using the Car class will look like this:

Car car = new Car();
car.setMaxSpeed(210);
car.setSpeedUnit("km/h");
car.setLength(5);
// remainder omitted

I have an idea how the life of the developers can be made easier using builder-style setters "pattern". Here is the new BETTER Car class:

public class Car {
  private int maxSpeed;
  private String speedUnit;
  // remainder omitted

  public Car setMaxSpeed(int maxSpeed) {
    this.maxSpeed = maxSpeed;
    return this;
  }

  public Car setSpeedUnit(String speedUnit) {
    this.speedUnit = speedUnit;
    return this;
  }
  // remainder omitted
}

I could instantiate and initialize my Car object in one line (maybe wrapped but still one line of code):

Car car = new Car()
               .setMaxSpeed(210)
               .setSpeedUnit("km/h")
               .setLength(5)
               ...

What do you think? Isn't it much easier? Of course if you extend Car class it becomes more tricky as you have to repeat all the setter methods like this:

public class Truck extends Car {
 private int capacity;
 private String capacityUnit;
  // remainder omitted

 @Override
 public Truck setMaxSpeed(int maxSpeed) {
  super.setMaxSpeed(maxSpeed);
  return this;
 }

 @Override
 public Truck setSpeedUnit(String speedUnit) {
  super.setSpeedUnit(speedUnit);
  return this;
 }
    // remainder omitted
}

But hey - who extends simple JavaBeans?

Maybe I can suggest this idea as a JSR-666 (there are two links :)? I'm curious what is your opinion about this idea. Please share your thoughts in the comments zone.

Agile Software Development with Scrum (PDF)

I don't know what is the value of the presentation without the presenter talking about the details but anyway I'd like to share with you my work. I presented the following slides during technical evening for my current employer's engineers in June 2008. Here it is (PDF):



Enjoy!

Video tutorial: functional testing with Selenium IDE

In this tutorial I'm presenting Selenium IDE - a tool for recording and replaying functional tests of web based applications. I'm showing how to record a simple test, test for Ajax-enabled application and how to replay such tests in Firefox web browser. I'm not showing how to start Selenium tests from Continuous Integration server in this tutorial - this is a subject for separate post.

I tried to make this tutorial short yet valuable and I hope you will see great value in Selenium IDE tool which is an open-source and free for commercial use. With Selenium tests you are able to test your web applications from the user's perspective, not from the code perspective. This greatly simplifies the acceptance testing and lets you know about all problems as soon as they arise.
Selenium tests should be considered as complimentary testing to unit tests - the best idea is to combine them both to get the best results. Unit tests should test your code and Selenium tests should test features available for your users.

I hope you will like it.

Originally published on AgileSoftwareDevelopment.com

Premature optimization is the root of all evil - not only in the Agile world

Picture courtesy of gutter@flickr

I was just reading an excellent book by Josh Bloch, namely "Effective Java, Second Edition" and I was on the optimization subject when it happened. It was funny coincidence but I think it was just a sign for me to write this post.

It doesn't relate to the Agility in any way but it relates to the quality of software so it should be definitely published here. And it all started very innocently - from publishing blog post with the solution to some annoying problem.

In this post I will tell you how easily you can fall into really dangerous and ugly development problems starting optimizing your software too early. I hope you will like the story.

Start with the simplest possible solutions...

I've been reading "must-read" book for all Java developers, namely "Effective Java (2nd Edition)" by Josh Bloch and I was just reading "Optimize judiciously" chapter. In the same time I was doing some Java EE development and I encountered a problem with Struts2 file upload capabilities. I found a solution and posted it to my private blog: http://java2jee.blogspot.com/2008/09/solution-to-struts2-upload-file-error.html. "This has nothing to do with the optimization", you may think - and I thought the same but it's wrong assumption.

After few days I received a comment to this post from anonymous user with an "optimized solution". The author of this post wanted to optimize this line of Java code:

if (string.contains(
      "the request was rejected because its size")) {

with this code:

public static Pattern REJECTED_FILE_SIZE_PATTERN 
                        = Pattern.compile(".*reject.*size.*");
...
if (REJECTED_FILE_SIZE_PATTERN.matcher(string).matches()) {

I always considered myself as a seasoned Java developer (hopefully it is still true :) but after receiving this comment I was quite worried. "Why I'm not using regular expressions to check strings? Isn't it much faster", I thought. I was even thinking: "Maybe it's time to become a manager? - my Java/technical knowledge is deteriorating..."

"But hey! I will not let it go like this" - I thought. I wrote a simple Java program to test the performance of both solutions:

import java.util.regex.Pattern;

public class Test {
  public static void main(String[] args) {
    int count = 1000000;
    Pattern p = Pattern.compile(".*reject.*size.*");
    String matching = "the request was rejected because"
                        + "its size (1234) some other text";

    long start = System.currentTimeMillis();
    for (int i = 0; i < count; i++) {
      if (matching.contains(
           "the request was rejected because its size")) {
        // do nothing
      }
    }
    System.out.printf(
      "contains() matching: %dms%n", 
      System.currentTimeMillis() - start);
    
    start = System.currentTimeMillis();
    for (int i = 0; i < count; i++) {
      if (p.matcher(matching).matches()) {
        // do nothing
      }
    }
    System.out.printf(
      "matches() matching: %dms%n", 
      System.currentTimeMillis() - start);
  }
}

On my machine the standard contains() solution is 50 to 80 times faster than the solution with regexp matcher. What a disastrous effect this could have when applied in the whole application! I can't even imagine.

When I took a look at the contains() method implementation I saw that it operates on the char array (i.e. underlying array that creates the String object). It is fast! And it is the simplest and the most obvious method to call in this situation. It even makes the code more readable and tangible than with the regexp matcher. I see only the advantages.

The conclusion is simple: DON'T OPTIMIZE YOUR CODE AND USE THE SIMPLEST POSSIBLE SOLUTIONS - THEY WORK!

... and stay with them

Joshua Bloch cites these guys:

More computing sins are committed in the name of efficiency (not necessarily achieving it) than for any other single reason - including blind stupidity. (William A. Wulf)

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. (Donald E. Knuth)

We follow two rules in the matter of optimization:
   Rule 1. Don't do it.
   Rule 2 (for experts only). Don't do it yet - that is, not until you have a perfecly clear and unoptimized solution.
(M.A. Jackson)

What else I can add? Actually, nothing. I just showed that each of the quotes above is true on the real example.

To rephrase Joshua Bloch: Never focus on optimizing your software. If you write good and logically structured code your software will be probably optimized by itself. Use well known, standard libraries and use the most basic features that meet your requirements - the optimization and quality will follow.

Do you have similar adventures with sub-optimal solutions? Maybe you disagree with me? I would gladly read your opinions.

Originally published on AgileSoftwareDevelopment.com

Seven Principles of Lean Software Development - Optimize the Whole

Picture courtesy of aussiegall@flickr

Lance Armstrong won seven consecutive Tour de France races between years 1999 and 2005. Every year there were 21 individual stages and Lance Armstrong won "only" 4 individual stages in 1999, 1 stage in 2000, 4 stages in 2001, 4 stages in 2002, 2 stages in 2003, 6 stages in 2004 and 2 stages in 2005.

As you can see Lance Armstrong was not focused on winning each stage (quite the opposite). He was focused on winning the whole Tour de France - yet he had to keep close to the head of the race. And when you take a look at time differences between him and the second cyclist in the final classification you will be amazed - they were close to couple of minutes (out of 90 hours of total time!) It means that he was focused on winning the whole race - not to be the best and outstanding cyclist (he was not - I know because I watched many of the stages these years).

Speaking with the lean language Lance Armstrong was Optimizing the Whole - and he succeeded seven times winning the most difficult and exhausting cycling race in the World.

In this post I will try to explain "Optimize the Whole" principle from "Implementing Lean Software Development - from Concept to Cash" book.

Focus on the Entire Value Stream

Software companies should focus on winning the whole race which is the Software Product. Software company does not have to be the best in everything they do, they don't have to have spectacular successes every week but they should focus on delivering great final products.

This can be achieved by optimizing the Entire Value Stream i.e. if the software teams are doing great but there is a bottleneck between them and the marketing it should be solved ASAP. So what if there is a great team of engineers who can deliver software and respond to customer's changes very quickly if this software cannot be deployed at the customer's site? They are optimized but the whole organization isn't! And this is a mistake.

Customers see the organization as a whole - they don't care if the product is great but they have problems with customer's service or other departments. For the customer every aspect of the software organization should be of the same quality. I dare claim that customers see the whole organization as they see its worst element.

This is why optimizing the Entire Value Stream is so important. It doesn't matter if the 90% of the organization is the best damn organization in the World. If the company's representatives suck our customers will have such opinion about the whole company (because they can't see our greatness).

Deliver a Complete Product

Software is not everything just like with the other products. If you go to shop and buy some stuff you not only look at what's inside but what's outside too. The whole package is important and the same rules apply to software products. Software alone is like the product without the wrapping - it may be great but it doesn't look tempting and it probably will not attract lots of customers to buy it.

Software companies should develop complete products, not just software. Our customers are not worse than we are when we go shopping - they need software, they need advice, they need post-sales service, etc.

Complete products are built by complete teams - it means that our teams should be composed of experts from all needed domains. Teams need to have great leaders as well as great engineers, sales, marketing specialists, secretaries, etc.. They together can deliver great final products to their customers and make them feel special every time.

Optimize the Whole

"Optimize the Whole" principle applied wisely will help you deliver your products and please your customers - that's for sure.

I hope pieces of advice given above will make it easy to understand how to put "Optimize the Whole" principle in practice. If you need more detailed description with more examples and more sophisticated explanation you should definitely go to "Implementing Lean Software Development - from Concept to Cash" book.

PS. Two principles described earlier can be found here: Respect People, Deliver Fast

Originally published on AgileSoftwareDevelopment.com

Predicting the team's Velocity: yesterday's weather method

Picture courtesy of aloriel@flickr

"How much software will you deliver in the next Sprints/iterations?" - do you often hear such questions? I do. And this question is really valuable especially for the project/product sponsors. But not only management likes knowing how much software they will deliver in the upcoming Sprints. Everybody (including development team members) likes to know the answer for questions like: "Where we will be in three months from now?".

If you track your team's Velocity you are able to answer such questions somewhat accurately, which is great. I personally don't know better tool for answering presented questions than tracking development team's Velocity.

Let me now explain how you can compute how much software your team will deliver in the next Sprints basing on the current team's Velocity.

Velocity
In Scrum, Velocity is how much product backlog effort a team can handle in one Sprint. Velocity is usually measured in story points or ideal days per Sprint - see Measures of size article. This way, if the team delivered software for 30 story points in the last Sprint their Velocity is 30.

What will be the weather today?
If you had to answer such question the best one would be that the weather today will be the same (or very similar) as yesterday (I assume you are not weather professional and you can only guess). The same is with Velocity and the amount of work you can predict doing in the upcoming Sprint. How much can you deliver? The same amount (or very similar) as in the previous Sprint - simple. You should take into account only the yesterday's weather i.e. only the last Sprint. Note that the yesterday's weather is one but not the only method to predict team's Velocity.

Let's consider the following example. Development team is composed of Mike, Martha, Paul, Josh and Julia. They worked on the project we are estimating following numbers of days (Sprint length is four weeks):

Team Member	Days Worked
Mike	16
Martha	10
Paul	14
Josh	16
Juila	14
Sum:	70

They delivered software worth 25 story points (sp) i.e. the team's current Velocity is 25. They claim that story for 3 sp is 80% done but this story is not DONE from the user's perspective. This story is not and cannot be taken into the final sum of delivered software - therefore we still have 25 sp instead of 28 sp.

To summarize - the team delivered software worth 25 story points in 70 work days.

How many story points we can deliver next Sprint?
If everybody in the team is available exactly the same amount of time in the project in the upcoming Sprint you can assume that the Velocity will be about 25. Depending on the team's experience in Scrum and their estimation skills it can vary i.e. if the Velocity of the beginner team will be 20 or 30 in the next Sprint it's still OK. The Velocity usually stabilizes after few Sprints (but it can still fluctuate slightly - you will probably never have the same results in two subsequent Sprints) but even if we consider experienced Scrum team we can expect that the Velocity in the next Sprint can be slightly lower or higher than 25.

If the team members will not be available in the next Sprint the same amount of time because of many reasons, or the Sprint itself will be shorter (e.g. because of some national holidays) you should verify planned Velocity.

The following example is based on techniques used in a real project that was developed be me and my teammates at Intel. Of course, names and numbers are not real.
The first thing to do is to sum team members' availability in the next Sprint. In four weeks we have 20 work days but there is one day of national holiday, therefore we have 19 work days. I also assume that team members can spend their 20% of time on developing some fresh stuff, learning, researching new technologies, etc. I will subtract 20% of time available for each time member separately. Let's take a look at the following table:

Team Member	Days Planned	Days Available (-20%)
Mike	19	15
Martha	15	12
Paul	19	15
Josh	10	8
Juila	10	8
Sum:		58

If the team delivered software worth 25 story points during 70 work days it means that they can commit to ~21 story points during 58 work days in the next Sprint (58/70 * 25 = ~21). So, predicted Velocity is about 21 story points.

Commitment
I assume that you have prioritized backlog of stories you have to deliver. I also assume that you know that you have to deliver them ordered by priority. This way you can start picking the stories until you collect about 21 story points in this example. It is really important to say about word - we are still in the estimation level, we don't know the accuracy of our estimates. That's why teams should commit to deliver about N story points.

What if the granularity does not allow you to hit exactly 21 story points? In this case you should take one smaller user story that is not at the top of your current backlog (still close to the top priorities ones) or exceed planned Velocity if and only if the team feels that can deliver selected stories. It is also pretty natural that the team can commit to 20 or 19 story points if they feel 21, 22 or 23 will be too much. Team is the most important here and they have the strongest deciding voice. At any rate the Velocity will be verified in four weeks i.e. at the end of next Sprint.

Wrap up
I hope this post helps you, I explained what Velocity is and how useful it is. I also hope you will be now able to answer the question "How much software will you deliver in the next Sprints?". Use the force which is Velocity in this particular example.

If you need more detailed information about agile estimation, planning, Velocity and all similar topics you should read Mike Cohn's book: Agile Estimating and Planning. It is brilliant and written with a very accessible language.

If you have some comments, want to ask some questions, something is not clear then comments section is all yours.

Resources
You may find following links valuable:

• velocity-measuring-and-planning


• team-velocity


• productivity


• measures-of-size

Originally published on AgileSoftwareDevelopment.com

Video tutorial: Test Driven Development in practice

In this nine minute tutorial I'm presenting TDD way of developing software i.e. start from writing the test.

Many people often say that you should start from implementing at least interface and then start testing. In this tutorial I'm showing how easy it is to start writing unit test with nothing (not even an interface) i.e. only having the requirements. After couple of minutes I've got an interface, a working implementation and a full test suite.

This is what Test Driven Development is all about - software should be developed this way IMO. Sources for this tutorial can be found here

The voice volume is quite low so I recommend using headphones and increasing sound volume a bit while watching this video



I hope you like it.

Originally published on AgileSoftwareDevelopment.com