AHCI in Windows

A recent discovery I made because of my mobo's odd controller:
While its true that AHCI works out of the box with Vista/Windows 7 (that is, there is no need for third party drivers) -- If you did not have it enabled when you first install Windows, it will be disabled to save some boot time. Makes sense. What's odd is what you have to do to enable it. You have to change HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\msahci\Start from 0x3 to 0x0. Otherwise, you get a blue screen when you try to boot. The fancy startup repair that comes with Vista/Windows 7 will be launched the next boot (if you let it), but won't be able to figure this out for you.

So yea, I tried moving the cables around on the inside (thinking it might be a bad sata port), and changed to AHCI, and my cd drive was still the one that disappeared, not the drive in that port.  I thought it might be some incompatibility with the firmware, but the updater fails to run. :'( I suppose it's also possible it's a bad cable.

Java vs Groovy: Polymorphism

While doing some studying for SCJP, I was tinkering with some stuff in the Groovy console as a way of testing some stuff in Java and I found they actually behave differently.

class Person {
  protected String name
  protected int age
  
  public Person() {
    name = "secret"
    age = -1
  }
}

class John extends Person {
  int favoriteNumber
  
  public John() {
    name = "nobody special"
    age = 0
    favoriteNumber = 7
  }
  
  public String doNothing() {
    return "junk"
  }
}

Person p = new John()
println p.doNothing()

If you do this in Java (splitting the classes out to their own files of course), it won't compile. Java looks at the reference type for available methods, so you will get a NoSuchMethodException. In Groovy, however, it looks at the type of the object, not the type of the reference so the method is found at runtime. And this is probably what you would want, so I can refer to John or Mary as a generic Person, but they still do the things they do in a John or Mary way.

Java vs Groovy: Overriding static methods

The Java equivalent of below will not compile, but in Groovy it works fine. Groovy supports overriding static methods, whereas Java does not.

class Person {
  protected String name
  protected int age
  
  public Person() {
    name = "secret"
    age = -1
  }
  
  public static String doNothing() {
    return "junk"
  }
}

class John extends Person {
  int favoriteNumber
  
  public John() {
    name = "nobody special"
    age = 0
    favoriteNumber = 7
  }
  
  public String doNothing() {
    return "more junk"
  }
}

Person p = new John()
println p.doNothing()

I don't think this would be a problem. You might want each inherited class to have its own (maybe static) version of a method, but for every instance of the class to only have one in memory. If you don't want the children overriding the method, you should just make them final.

Skip The Tests

Skipping tests is generally a bad idea. But, if you are changing things just to tinker and see results, without particularly caring about the tests, it is easily skipped from the command line:

mvn install -DskipTests

This is something I'm sure you've seen. What I didn't know is that you can also skip the compiling of the tests:

mvn install -Dmaven.test.skip=true

Code in Blogger

So, I've been looking for a way to make my code examples in blog posts more readable. I had tried to use the hosted version of SyntaxHighlighter, but couldn't seem to get it working right (I'm sure it was something simple) and it needed several lines added to the Blogger html template. Instead, I've opted to use google-code-prettify. Though it doesn't support as many languages (in particular no groovy), all I needed was 2 lines pasted into the template, and making it load the class when the body element is. Couldn't be simpler. I followed the instructions (slightly tweaked) from here. Thanks Luka.

These are the lines you need (anywhere in head tag):

<link href="http://google-code-prettify.googlecode.com/svn/trunk/src/prettify.css" type="text/css" rel="stylesheet" />
<script type="text/javascript" src="http://google-code-prettify.googlecode.com/svn/trunk/src/prettify.js" />

Then modify body tag to load the script:

...
<body onload='prettyPrint()'>
...

Use:

<pre class="prettyprint" style="overflow:auto;">
  <!-- Your code goes here -->
</pre>

You don't need to specify the language since the script will guess, but you can if you like:

<pre class="prettyprint lang-html">
  <!-- HTML code here -->
</pre>

The lang-* class specifies the language file extensions. File extensions supported by default include "bsh", "c", "cc", "cpp", "cs", "csh", "cyc", "cv", "htm", "html", "java", "js", "m", "mxml", "perl", "pl", "pm", "py", "rb", "sh", "xhtml", "xml", "xsl".

I've gone back and added the syntax highlighting to all my code examples in previous posts.

Boolean.flip()

Recently I needed a Boolean in a groovy project I was working on to alternate back and forth (for row highlighting with Apache POI). I thought it would be slick to metaclass a flip() method (something I've always thought should be there) into Boolean. It turns out, this is not possible. I browsed the Java source and learned that all primitive wrapper classes are immutable. I'm not completely sure why they did this. My guess is to protect programmers from hurting themselves by mutating objects in a collection and possibly creating unexpected behavior or a race condition.  I could have created my own boolean wrapper class, of course, or use Apache Commons MutabeBoolean. In the end, I decided not to be fancy and just reference a new object like

Boolean foo = false
foo = !foo

But boy, it would have been pretty & nice to have

Boolean foo = true
foo.flip()

Yay! Someone else agrees with me!

A couple days ago, I blogged about some of my frustrations with task estimation. This morning, I saw an article posted on AgileZone that seemed to echo my words (though in a more concise and articulated fashion than I managed to).

Things About This Universe That Amuse Me

We live in a weird universe.

1. There are more species of beetles than any other order the animal kingdom, comprising 25% of all known life-forms.
   
2. Humans are the only species that drinks milk from a species other than their own.
3. There are significantly less than a googol of atoms in the known universe.
4. Onomatopoeias
5. Time is relative.
6. More people have died than are currently alive (6% of all people who had ever existed were alive in 2002).
7. The chimpanzee genome is 95% identical to the human genome. And up to 95% of our genome may be junk left behind by retroviruses and evolutionary artifacts.
8. Humans are the only species known to use the smile to express something other than fear and aggression.
9. ∞ - ∞ != 0.
10. Human childbirth. How does this not kill us? The infant's skull actually changes shape as it passes through the birth canal.
11. Human flora. The womb is sterile, but after the family has finished kissing and caressing, 500 to 1000 kinds of bacteria live in the gut, and just as many on the skin. Cool.

Project Estimation

I've been thinking about project estimation the last several days. What initially got me thinking about it was the links off of this article. I find the notion of using story points instead of hours for sprint estimates appealing. I like the idea of having a set number of story points per sprint, it keeps everyone apprised of the complexity of the issues at hand. It also encourages the use of stories instead of use cases for requirements, which has some advantages. I buy the idea that estimating story points is easier than estimating time. Scrum-Breakfast likens it to a train

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?  The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle [...], the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just as the distance to the train station does not depend on how I get there.

However, I think this ignores a fundamental aspect of human nature (at least of modern day humans): our need for instant gratification. We don't really care how far away something is (except for concerns about fuel). When we ask someone how far away they live from some particular point, they usually give an answer in hours and minutes, not miles. They view it as a question of how long they have to wait before they get what they want. Similarly, product people and especially the customer don't particularly care how complex a problem is to solve. They just want it solved, and want to know how long they have to wait before they get what they want.

It seems to me that eventually someone will have to make the translation to hours (even if only done implicitly). Users care about release dates -- "when are the features I want going to be available?". Even if you schedule sprints with story points, someone is going to have to figure out how long those will take to complete in order to set a reasonable release date. When you make this conversion, you will have to account for variances in velocity (the speed at which people work). Even if you do decide to use story points, this correlation will be necessary at first to establish how many story points are possible in a sprint.

Still, there are some advantages to this approach that come to mind. When you estimate story points, you don't have to estimate both complexity and your ability to solve the complexity. You only have to worry about the complexity. The hours for big things are often pulled out of the air and aren't very accurate until they are broken down into tasks. Story points provide a good way of looking at the big picture without fleshing out all the details. One additional cool thing about story points is that they have built in variances, as Scrum Breakfast points out

The thing to realize about about estimates is that they are very imprecise. +/- 50%. One technique for dealing with a cost ceiling is to define an estimate such that the actual effort needed will be <= the estimate in 90% of the cases, regardless of whether they are measured in days, hours or point. So Story Points are usually estimated on the Cohn Scale (named for Mike Cohn, who popularized the concept): 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. Why is there no 4? Well a 3 is a 3 +/- 50%, so a three actually extends from 2 to 5, a 5 from 3 to 8, etc. The difference between 3 and 4 is nowhere near as significant and between 1 and 2, so we don't give estimates that give us a false sense of precision. Summed together, many imprecise estimates give a total that is a remarkably accurate estimate of the work to be performed (the errors tend to cancel each other out, rather than accumulate).

Mule also had an interesting approach to creating a product backlog, where they used a sort of bucket sorting rather than choosing actual numbers for story points. This is what Chris Sterling calls affinity estimating.

Mike Cohn says that sprint backlogs and product backlogs should have different units to prevent confusion, since if you use hours for both it doesn't show that hours on a sprint backlog have been thought about a lot more than hours on the product backlog. Speaking of Mike Cohn, he has an interesting notion for the role of story points. He suggests they are a good long-term indicator, but the short term should focus on the product backlog and prioritize stories, then break them into tasks and estimate those using hours. Some have suggested using task points in a similar way as story points, but for individual tasks. This might provide some room for variance if you really suck at estimating. Additionally, you will only have to update the estimates when complexity changes not when velocity changes. This also might be a more lean approach since it doesn't waste time on an artifact that is not needed. However there are some downsides to this approach. One is that there is no easy way to track the progress of the task (e.g. in Jira), unless a conversion to hours is first made. It also presents a challenge to HR, which may wish to account for hours for financial reporting purposes.

I think it makes a bit of sense to use hours to estimate at the task level, since you should be able to give more detail at that point (as opposed to the bigger items, like stories where any hours ascribed would basically be pulled out of thin air). This is what I'm interested in. How can I make my task estimates more accurate to make sure I can deliver what I think I can deliver? To me, it seems the issue with both of these methods of task estimation is that they do not address the real problem with why tasks get off schedule in the first place. Actually, there are two, but both deal with an unknown. The first is if there are other tasks competing for the same resource (e.g. your time) that weren't initially accounted for: either they came up after the estimation or were a result of oversight. The second is because you have misjudged the complexity of a task. You look at a problem, it seems pretty simple, you ascribe a few hours/points/whatever to it, but once you start digging into the problem you realize its going to take longer than you thought. Then you are left with the question of whether or not to re-estimate. I think while the original estimate should be retained for posterity's sake, its useful for the product people to have a new estimate for planning purposes...perhaps pushing back to another sprint.

The only certainty is the certainty of uncertainty, but that's probably why you're doing agile in the first place. This is especially true when new technology is involved. While there are some who advocate task points for breaking down tasks (pieces of a story), most advocate to use hours at this level. And this is what I do not understand. Why are we going to all the bother to make all these estimates about minutia? Get a commitment from developers, keep a backlog, and get to work! I can't believe some agile teams are willing to spend several hours (some say 8 hours) on sprint planning. That doesn't sound agile to me at all. A practice that seems to work pretty well for some of my colleagues here at OCLC is to use units that are a bit fuzzier than an hour. They tend to estimate in 1/2 days, which is a bit less precise, but allows for greater accuracy because it is easier to ballpark. But unless you are continuously updating estimates (as the Scrum Primer suggests) so that volunteers can move around on tasks (perhaps in a paired situation), I don't see much point in having exact hours.

Honestly, I'd rather do away with task estimates altogether. Maybe its because I don't like submitting something that I know I can't do a good job on (at least not yet). But it also seems to me that you are spending time creating an artifact that doesn't necessarily help you finish the sprint. There are some out there who have suggested this. Including Jeff Sutherland here. Jurgen De Smet has an interesting blog post on it here. I feel that as long as I'm reasonably certain I can get tasks X, Y, Z done in sprint N, I don't' really need to make up numbers for how long they'll take. Maybe I'd feel differently if I were on multiple teams and close to being overworked. But I feel developing this sense is developing a skill that isn't really useful for anything. I can't even get good at estimating to apply it to other areas to improve productivity, this 'gut' sense is a rather domain specific intuition. What's the point? Am I completely missing something?

P.S. This didn't really fit with anything else, but I wanted to pass it along. It is about building a common definition of done:
http://chrissterling.gettingagile.com/2007/10/05/building-a-definition-of-done/