Just now I finished upgrading website to 3.0. I do not find any problems. Planning to redo the website look and feel some time.

I am using Parallels for some time now for running windows under an iMac. Mostly I use it full screen mode. Whenever we leave fullscreen and get back to OSX, Parallels resizes the desktop. The resulting screen adjustment is really ugly.

Enter Think. Think is a small and beautiful application that stretches a blank (or a selected color) screen below your active application. In effect, the current application is highlighted. It comes along with a semi-transparent control panel. Now, the control panel is available when Parallels is running in the full screen mode. Switching to a Mac application? Use the control panel and select the running application.

If only Think supports using a wallpaper now.

I lurk around the ExtremeProgramming group with an occasional posting or two. Recently there was this thread where there is some discussion about the length of a story. Most people seems to lean towards shorter stories of 1-3 days duration.

The initial wisdom from the XPers seems to point towards longer stories. Both the wiki as well as XPE refers to stories of 1-5 weeks in duration. Even the initial discussions on the XP group favor longer stories. But over a time there was a general move towards shorter one week iterations (XPE2 calls them Weekly Cycle) and a move towards shorter stories.

Contrary to the current trend, longer stories provide better value to an XP project. As a work unit they are easier to handle, buck the half-cone syndrome of cone of uncertainty and make better use of law of averages. Longer stories also have tendency to excite the customer.

Longer stories = Less upfront work to the customer

This must be obvious. The shorter a story the more work is for the customer. They need to write down more story cards, they need to think of finer details about the application and also handle more cards per release and iteration for prioritization.

Longer stories = Less upfront analysis

One of the XP books (I don’t remember which one – though I think it is XP installed) asks the team to practice tearing the cards. That is one of the best advice I have seen. It is really tough to backtrack on something that you have spoken let alone written. But, this is what the teams are asking the customer to do by requesting for shorter stories. Like the design evolves, the application also should evolve. A longer story when discussed during an iteration provides the customers a chance to see the application developed till now and analyze the requirements in the light of what is existing.

Half Cone syndrome of Cone of Uncertainty

A recent post in Steve McConnel's blog is very illuminating. It seems to be the cone of uncertainty for estimates tends towards underestimation in agile projects. I did not read the original article, so I might be totally wrong in the conclusions.

Whatever it may be, my personal experience is that shorter work units are easier to estimate, the estimates are more accurate – but I tend to underestimate the work. You can also do an experiment. Take few story cards and estimate them. Then split the cards into smaller tasks and re-estimate them. In most cases you will find that when split to tasks the combined estimate will be lesser than the story card estimate.

So, by using shorter stories we tend to more create more accurate estimates and at the same time we increase the probability of underestimation. Using longer stories mitigates this risk by letting law of averages work for the team.

Longer stories = More perceived value to the customer

Frankly speaking, I want my customer to be excited when a story is completed. A 1-3 day story can’t excite a customer as much as a 1-3 week story. Where as shorter stories act as a progress report, longer stories provide the extra zing that comes when a customer can accomplish something with the software.

Excuses for using short stories

I enumerate some of the (valid and not so valid) reasons for using short stories.

Easy to estimate

If the team uses yesterday’s weather, estimating a long story is as easy(or tough) as estimating a short story.

Concrete estimates

Estimates are never concrete. The only way we can create concrete estimates to create them post hoc – that is create the estimates after the work is done .

That said, having larger stories does not mean that the estimates are not concrete. Spikes, yesterday’s weather and the power of our minds to use analogies and metaphors allows us to create estimates that are as accurate taken together as when we use shorter stories.

Shorter iterations

This will be a fodder for another post . That said, if the team size is big enough longer stories are still possible with short one-week iterations.

Small teams size

This is one valid reason to avoid stories and go ahead with tasks. My experience is only with teams of medium size and XP4One. I suspect larger stories (for that matter stories them selves) can be avoided for teams that are very small (say 1-4 in size). Any larger XP team can benefit from longer stories.

If you want to discuss this post, I suggest to use ExtremeProgramming group. The blog comments are moderated (though I use akismet I find inappropriate comments once in a while) – and they may appear after some time.

The whole of XP design strategy depends on ‘Do the simplest thing that could possibly work’. It has become a command for XP teams. The c2.com wiki page on DTSTTCPW starts with an excerpt from an interview with WC. The worst part of this excerpt is that it ignores the context in which the question is asked.

According the interview:

And sometimes the programming was almost effortless, as if Smalltalk had been made to write that program. It was amazing. But other times we’d be programming away, and we’d say, “Now, wait a second, what are we working on here?” We’d just get stuck. And if we were stuck more than a minute, I’d stop and say, “Kent, what’s the simplest thing that could possibly work?”

Did you find how it is different from the XP gospel? Here the part is highlighted:

if we were stuck more than a minute

So what WC was saying is that do not stop working because you did not find the best design. Go ahead with whatever simple solution you can find at this time. The act of writing code and concretizing the thoughts will stop us from blocking the progress.

It is worth while to hear these things straight from the horse's mouth.

Few months back I bought a MacMini just to play around with. Initial periods are somewhat irritating – remembering to press command instead of control etc. But I stuck with it. Recently, I realized that I am spending more time on the Mac than either Linux or Windows. Eclipse for Mac is decent (though it crashes once in a while) and I am using it for Marathon development. In the end, I decided to go for a iMac. My iMac just got delivered and it is great. With parallels I am able to run both Linux/Windows on this and the VM is pretty fast.

Why Mac?

1. It is smooth and works out of box. And of-course it looks great.
2. With parallels, I am able to test out Marathon on Linux/Windows and Mac from the same box. No other box can give me the ability to test it under Mac.
3. Quicksilver – I took sometime getting used to it, but it is a great time saver. Since eclipse also uses Ctrl-space as a short cut, I use Ctrl-Option-Space to bring up QS.
4. Under the hood, OSX is BSD. So most of the Unix goodies are available.

For those of my friends who say (with some justification) Macs are costly, I say just try it. Eye candy makes a lot of difference (though I find myself playing around once in a while instead of working .

While working on porting Marathon to Java 5, I found a funny problem. We use a TestDialog(derived from JDialog) for running most of the component related test cases. When run under Java 5, the dispose() of TestDialog is being called multiple times. Since TestDialog.dispose() calls super.dispose() this goes into a loop. The number of times TestDialog.dispose() is called is random. I dug into the sources and found that since some developers might not call super.dispose() in classes derived from Window, the VM calls dispose() for them.. So a little bit of sloppy programming would have helped.

For some time I am planning to update this website. I am using WordPress as the backend and wanted to use it also as a CMS for this site. WP supports a concept of pages and page heirarchy, but I could not find any WP themes that makes use of this as I want it.

I started with an excellent opensource web template by Andreas. (BTW, head for his site if you want to see some excellent CSS/XHTML compliant templates). I hacked a bit in wordpress to get what I want. Then I went ahead and created a template for this site (what you see currently for this page).

Both the templates are available for download @ WordPress themes page.

Looks like 9500 and 9300i have a lot in common. With a little bit of cp and vi, I could make my 9500 sync with Mac. If you have OSX 10.4.7 and iSync 2.3 – go ahead grab the file and untar it in iSync.app directory.

iSync plugin for Nokia 9500

Drop me a line if this is useful to you.

Actually I prefer referring it as Test First Design with an emphasis on Design. Whatever, while scanning through my book marks, I found this nugget of wisdom.

E.W.Dijkstra Archive: Dijkstra: The Humble Programmer.

The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness. But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer’s burden. On the contrary: the programmer should let correctness proof and program grow hand in hand.

Is this the earliest referrence?

On his blog Ravi Mohan had a entry. He said:

Programmatic thinking somehow seems to investigate the “structure” (and the structural integrity) of a solution to a problem while mathematical thinking focusses on the abstract essence of a problem and the “degree of rightness” of a solution.

I beg to differ. In my opinion, knowledge of mathematics will be helpful in finding some good solutions for some interesting problems. In majority of programs this is not a requirement.

The whole confusion (if any) arises because most early programmers were mathematicians. The basis of programming languages is steeped in mathematics till now. Most early languages were designed by mathematicians – I am even doubtful whether we have programmer or computer scientist in vocabulary at that time.

A look at list of alchemists at wikipedia shows some well known names – Plato, Newton. There were no separate branches for physics, chemistry, astronomy at that time. As the body of knowledge increased the different discipline of science started appearing in our vocabulary. This happened in computers also. Not very long ago, we have hardware and software combined together into the same discipline. Courses like Master of Computer Applications (with focus on only software) started appearing only two decades back.

Similarly the body of knowledge is increasing for programming. If it is not already happened – sooner or later it is bound to seperate from the mathematics. It will stand on its own as a separate disciplline. There are advantages of separating programming from the underlying mathematics. A typical programmer needs to have different skill sets that are often different from that of mathematicians. This does not mean that all maths will disappear from programming. Programmers still need to learn state machines (especially since regular expressions became a standard in all languages), a little of linear algebra, relational algebra and lambda calculus. It is unfortunate that quite a few programming courses either donot have these courses or skim over these topics. We need a dose of all these topics as related to programming not as a standalone maths theory.

That said, in my opinion Maths will always be corner stone for computer science (as opposed to programming). Programming language theory (as opposed to programming) still needs heavy dose of Mathematics.