Programming Language

Nice interview of Micheal Feather on testing and multiple programming language.

http://www.infoq.com/interviews/michael-feathers-programming-languages

Fun with Java

I gave one presentation on some of cool java tools. Please find the link for slides below. I will upload the code on github soon.

http://www.slideshare.net/mmahawar/final-java-presentation

10 Tools for Distributed Developer Teams

Good List of tools, interesting read.

http://mashable.com/2010/07/14/distributed-developer-teams/?utm_source=TweetMeme&utm_medium=widget&utm_campaign=retweetbutton

TDD A Religion not Process

Now a days at work I can safely place TDD to the side, even though my boss would love me to practice it. At the moment I’m working in a large, legacy code base. This code base is about 3 years old but looks like it’s thirty :). Let me not get distracted.
Some how TDD has infused itself into my brain today. I can’t stop thinking about it. All the resources out there would make you believe that TDD is some process that all you have to do is adopt and it will lead you to the promised land. In reality, I believe it’s more like a RELIGION. You have to first find your faith and then perform the rituals before the promised land materializes.
I’ve been practicing TDD for over 2 years now and I still find it challenging. Anybody can write unit test after the fact, but only the best developers know how to make great decisions throughout a project. And it’s this ability to make quality decisions consistently that I struggle with day to day. It’s a design activity after all.

Here are couple of very high level challenges which I think I have with TDD

1. How to determine at what scope I should write a test
2. Make sure I capture behavior and not implementation details
3. Learning not to over mock
4. Force myself to write only enough code to make the test pass

There are other challenges which I have seen in projects, when a team does TDD like slowness of tests so team stops running all the tests or UI tests which tend to be fragile, because they often fall because of refactoring. So they often become fragile, failing
erratically and difficult to maintain.

Humm I am thinking of elaborating my bullets points, nahhhhhh not today probably will do that in my next blog.

Manisha

Remember to give a hint

We ran into once interesting discussion during our last code review session. As we all do it's a common trick to use relax access restrictions to test a particular property/method/function, so that you can use it in a unit test, which resides in the same package (though in different catalog).

Whether you think it's good or bad, I believe always remember to give a hint about that to the developer. A simple annotation that tells you why a particular property access restriction has been relaxed.

Consider:

public class foo {
private Long x;
String y;
}

Hummm Why is 'y' package scoped?

public class foo {
private Long x;
@VisibleForTesting String y;
}

Ah, that's why

Nice isn't it.
Manisha

Estimating for size vs Estimating for duration

“Accurate estimates is an oxymoron”

Today at our planning meeting we had an interesting discussion regarding sizing our features. We were questioning how to do right sizing and what is the basis and all good, logical and so called fun questions. Here is my take on it :).

Agile teams estimate SIZE of a feature (Story) rather than estimating the DURATION it will take to complete. Our team likes to estimate size with t-shirt sizes. Story points or T-shirt sizing are a unit of measure for expressing the overall size of a feature. When we estimate with t-shirt sizing or store points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values?

Lets take an example of restaurant before we dive too deep. Suppose a new restaurant opens nearby, and you decide to try it. For the first course, you can have either a bowl of soup. You can have the entree as either a full or half portion. You have probably been to many restaurants like this and can quite easily order about the right amount of food without asking how many ounces are in the cups of soup and exactly how big the entree portions are. At most, you may ask the server something like "How big is the salad?". The server will likely respond by holding his hands apart to illustrate the size. In cases such as these, you are ordering by relative rather than measured size. You are saying, "Give me the large portion" or "I would like the small serving". You are not ordering by exact size, such as I would like 14 ounces of sode, 6 ounces of rice and 3 ounces of veges.
It's possible to estimate an agile project's features in the same way. When I am at an unfamiliar restaurant and order a large soda, I don't really know how many ounces I will get. About all I do know is that large soda is larger than a small or medium soda and that it's smaller than an extra-large one. Similar analogy can be taken for spice levels.

Fortunately, this is all the knowledge I need :). All I need to know is whether a particular feature is larger or smaller than other feature. A feature that is assigned a 2 should be twice as much as a feature that is assigned a 1. THERE IS NO SET FORMULA FOR DEFINING THE SIZE OF A FEATURE. Rather, a sizing estimate is an amalgamation of the amount of effort involved in developing the feature, the complexity of developing it, risk inherent in it and so on.
We can get started by selecting a feature that we expect to be one of the smallest features we will or have work with and say the feature is estimated at 1 point. The best way to see how this works is to try it.

“Confidence comes not from always being right but from not fearing to be wrong.”
A key tenet of agile estimating and planning is that we estimate size but derive duration. (Estimates / Velocity = duration). Velocity is like weather. Based on past we try to predict but it may differ. (I will try to cover techniques of velocity estimation in next blog post.)

The beauty of this is that estimating in story points/ t-shirt sizing completely separates the estimation of effort from the estimation of duration. Of course, effort and schedule are related, but separating them allows each to be estimated independently. In fact, we are no longer even estimating the duration of a project; we are computing it or deriving it.

The distinction is subtle but important.

Nine steps to Better software design

Off late, I don't like to think about designing when I am coding. I know I know designing is important. I am not denying the importance but like to do it differently. I keep SOLID principle in my head when ever I code. These principles are applicable to any domain. And along with these principle I like to follow few rules defined by Jeff Bay in thoughtwork's book.

The Rules
------------
Here are the rules:

1. Use only one level of indentation per method. (My version is two level ;). It's too hard to stick with one.)
2. Don’t use the else keyword.
3. Wrap all primitives and strings.
4. Use only one dot per line.
5. Don’t abbreviate.
6. Keep all entities small.
7. Don’t use any classes with more than two instance variables.
8. Use first-class collections.
9. Don’t use any getters/setters/properties (hummmm take your own call.).

They are easy to follow and does magic with the code...