Here is the list of best practices he recommends:

1. Make fewer HTTP requests
2. Use a CDN
3. Add an Expires header
4. Gzip components
5. Put stylesheets at the top
6. Put scripts at the bottom
7. Avoid CSS expressions
8. Make JS and CSS external
9. Reduce DNS lookups
10. Minify JS
11. Avoid redirects
12. Remove duplicate scripts
13. Configure ETags
14. Make AJAX cacheable

Watch this Video of Steve’s talk at the recent Google I/O conference:

Even Faster Web Sites (Google I/O Session Videos and Slides)

http://www.scribd.com/doc/40437/Commodore-64-Users-Guide

The news today that Sun hired two key Python programmers makes me hopeful that they’re thinking what I’m thinking.

Ultimately I suggested he take a look at some of the material at xunitpatterns.com, a site developed by Gerard Meszaros while he was authoring the book xUnit Test Patterns. I was fortunate enough to be mentored by Gerard on several projects I worked on in Calgary, and have a tremendous amount of respect for him and his knowledge when it comes to testing software.

After looking at xunitpatterns.com Dustin and I realized the real question was what type of Test Double should be used. For the problem at hand, we decided to go with a Configurable Test Double. If you are stuck on a testing problem, or just want to improve your testing skills, I strongly recommend looking at Gerard’s site and picking up his book.

public void printPowers() {
    for (int r = 0; r < 100; r++) {
        int x = Math.pow(r, r);
        System.out.print(x);
        System.out.print(",");
    }
}

In Java - *with class definition and formatting left out

[r**r for r in range(100)]

In Python

Another thing I didn’t mention: The java implementation won’t work because int can’t store 99^99, but Python takes care of handling arbitrarily large numbers for you. It’s great.

Extract method is probably the refactoring I use most frequently. It is covered in detail in The Refactoring Book, so I’ll leave out many of the details here that the book covers. I strongly encourage anyone interested in refactoring to read this book and keep it close by as a reference. The intent of this post and of this series of daily refactorings is to introduce a set of commonly used refactorings and to spark discussion about concrete real-world experience with them.

I want to get people thinking about the importance of refactoring and how it impacts how we think about upfront design vs just-in-time design and the ways in which refactoring can help us avoid over engineering.

What is Extract Method?

A refactoring that moves code out of a method by creating a new method and delegating to it.

To illustrate, let’s start with some code that could benefit from applying extract method:

public BigDecimal calculateTotal(List<item> items) {
 
	// calculate sub total
	BigDecimal subTotal = new BigDecimal("0.00");
	for (Item i : items) {
		subTotal.add(i.getAmount());
	}
 
	// calculate tax
	BigDecimal taxRate = TaxRateHelper.getTaxRateForState(_user.getState());
	BigDecimal taxAmount = subTotal.multiply(taxRate);
 
	BigDecimal total = taxRate + taxAmount;
	total.setScale(2, BigDecimal.ROUND_HALF_EVEN);
 
	return total;
}

This code isn’t terrible by any stretch but it could be cleaned up by applying extract method. It’s easy to see that more than one thing is being done in this method. It is calculating a sub-total, tax amount, and total. Let’s extract these out as separate methods:

public BigDecimal calculateTotal(List<item> items) {
	BigDecimal subTotal = calculateSubTotal(items);
	BigDecimal taxAmount = calculateTaxAmount(subTotal);
	BigDecimal total = taxRate + taxAmount;
	total.setScale(2, BigDecimal.ROUND_HALF_EVEN);
	return total;
}
 
public BigDecimal calculateSubTotal(List<item> items) {
	BigDecimal subTotal = new BigDecimal("0.00");
	for (Item i : items) {
		subTotal.add(i.getAmount());
	}
	return subTotal;
}
 
public BigDecimal calculateTaxAmount(BigDecimal amount) {
	BigDecimal taxRate = TaxRateHelper.getTaxRateForState(_customer.getState());
	BigDecimal taxAmount = subTotal.multiply(taxRate);
	return taxAmount;
}

What impact did this refactoring have? What were some of the benefits?

• The original calculateTotal method is more cohesive and sticks to doing one thing.
• The comments that described what the different sections of code were doing are no longer required because the method name clearly documents what the code does.
• Each of the methods calculateTaxAmount and calculateSubTotal are no longer tightly coupled to calculateTotal and can be called independently.

Of all the benefits provided perhaps the one that I think has the most impact is that extract method increases cohesiveness and decreases coupling. The benefits of having a loosely coupled, highly cohesive system are well-worth the effort it takes to perform extract method, especially considering most modern development tools (such as ReSharper, IntelliJ, and Eclipse) support this refactoring.

Can you see any other refactorings that this code could benefit from?

Planning 

The planning sessions which include the scrum masters, product owners, and developers started after each of the product owners had their respective product backlogs prioritized.  The team spent hours together decomposing the items on the product backlog into bite-sized, testable pieces that could be estimated. It was a challenging learning experience for everyone, mostly around effectively time-boxing discussions and knowing what to discuss and what can wait, however we came out of it relatively unscathed, and definitely wiser and more cohesive for the experience.

Estimating 

After we had enough tasks broken down we gather the team of developers together to estimate each of the tasks.  The purpose of this is to know how much the development team can be expected to produce in a sprint.  The development team must be comfortable with the commitment and the product owners must be confident that the team will deliver on that commitment. We always plan more tasks than we think we can develop in one sprint so we don’t exhaust the available pool of work if the team performs better than anticipated.

The estimates are given in jellybeans rather than days or hours to avoid the myth that we can give such precise predictions about the work to be done.  This is a myth that has been hurting development teams for far too long.  Some things can be predicted very accurately such as, “How long does a direct flight from Saskatoon to San Francisco on a 737 take ( if such a flight existed)?” Others like, “How long with this football game take?”, can’t be predicted as easily.  But it can be estimated.

What the heck is a jellybean?

A jellybean is an abstract measure of the size of a development task.  To give the football analogy, we might consider that 1 quarter of a football game takes 1 jellybean.  That means a whole football game takes 4 jellybeans.  Although we don’t know exactly how long this is, it’s usefull nonetheless.  For example we may want to know how long it will take to play a football game that consists of 10 quarters.  That’s easy: 10 jellybeans.

Velocity is important when considering how much time it will take a team to produce one jellybean worth of work.

Velocity

Velocity is the measurement of how many jellybeans a team can accomplish in one sprint. It’s not something we can determine ahead of time with any confidence or accuracy, but rather something that is measured over time.  I’m sure you have experienced being on a development project where you we’re given a task AND told how long it must take. 

“Please have this TPS report generator completed by Friday.”

In football, the health of the team, injuries, penalties, weather, commercials, etc. all contribute to the velocity of the game.  It may take 1 hour to accomplish 1 jellybean (1 quarter or 15 perfect minutes) of football.  This is something we all understand and accept.

With a measured (and therefore predictable) velocity of 100 jellybeans, we would know that the team of developers has demonstrated over an extended period of time that it can accomplish 100 jellybeans worth of work in one 4 week sprint.  Changes to the team size, nature of work, distractions in the office, advances in technology, professional development, etc. will all have an effect on this velocity.

Ideal Developer Days 

There are several techniques available for estimating the size of each task, the least abstract being ideal developer days which is exactly how we did our estimation.

The team is asked to arrive at an agreement about the number of ideal developer daysa task will take by getting together in a room and playing estimation poker. Each team member comes up with an independent estimate.  We all share our estimate with the team (on a card) at the same time, then we discuss discrepancies in estimates until the majority agree. At first it was uncomfortable for me, and I sensed for some other people as well, to look around at the number of people in the “meeting” and think about how much time we were wasting.  However it became obvious that the benefits were outweighing the cost.  The team left these estimating sessions with a shared commitment to these estimates and a better shared understanding of what work needed to be done.

Relative Task Size

An alternative to the ideal developer days technique is relative task size.  This technique still uses estimation poker, but instead the team is asked to arrive at an agreement about the size of a new task relative to the size of some tasks that have already been accomplished.

Let’s return to the football analogy.  Suppose the team is asked to estimate how big a period of NHL hockey is.  Well they know that 1 quarter of football has been estimated at 1 jellybean and they have the option of estimating 1, 2, 3, 5, 8, 13 (you may have noticed that these are numbers in the Fibonacci sequence) There might be a debate about whether a quarter of hockey is 1 or 2 jellybeans, but the team eventually arrives at 1. This means that relatively speaking a quarter of football is about the same size as a period of hockey.

Summary 

Although ideal developer days are more concrete and easy to understand than relative task size there are a number of drawbacks to the approach.  I favor relative task size because improvements in the team dynamics, technologies, and practices are be reflected in velocity. With ideal developer days velocity does not reflect these improvements and we can mistakenly believe that the team is not getting better.

How does relative task size reflect technology and team improvements in velocity? Let’s look at a simple example:

Using ideal developer days we estimate the following: TASK1 - 1 jellybean, TASK2 - 4 jellybeans, TASK3 - 3 jellybeans.  The total is 8 jellybeans.  Let’s assume that we’ve measured the teams velocity over time and the team can accomplish 8 jellybeans of work in one sprint.

Now let’s step one year into the future.  We have some new technology available that makes the same type of work very easy.  Using ideal developer days as our estimation technique we estimate 3 similar tasks (these are not the same, but they are similar to TAKS1-3): TASK237 - 1, TASK238 - 1, TASK239 - 2.  If the teams velocity hasn’t changed we will obviously have to add a few more tasks to top it up to 8 jellybeans.  The problem with this is that it can appear that the team is holding at a velocity of 8 jellybeans, which does not account for the increase in performance.  Had we used relative task size to estimate these instead, we would have seen that TASK238-239 receiving similar estimates to TASK1-2 regardless of the technology improvement and the additional tasks the team is able to accomplish would cause the measured velocity to increase.

Also, anybody with an OpenID account can post comments without first creating a username and password.