The rational testing solution from IBM ad on the front page is one of the most hilarious ads I have ever seen.

All these testing tools are great and have their own place. But testing is not a solution for eliminating bugs from your code. The real problem is the way we develop software. The way we code. I would take it one step further and say, the real problem is our understanding of software.
Pulling the rational vision screen can‘t help blind project stakeholders [including the project development team].

The ad says, “You can‘t fix the bugs you can‘t see”. Sure. Having an automated testing tool does not solve the problem. It only gets you one step closer to it. I would prefer attacking the root cause rather than taking a reactive step.

All said and done, bug free software is a myth.

Time and again, events in daily life remind me of M3.

In 1975 Frederick Brooks published a book called “The Mythical Man-Month“. Most of us refer to it as M3. The essence of the book is “Too many cooks will surely spoil the broth”. Outrageously oversimplified Brooks‘ Law can be stated as ‘adding more people to a late software project makes it later‘.

I have seen people trying to break this law at different levels and fail miserably. Despite time and tide, brooks‘ law applies not only at project level, but also at organizational levels.

A lot of organizations trying to overcome financial or other crisis by growing. Even though some [very few] organizations have really solved the crisis by growing, they have surely been a failure. The reason for failure being, loss of vision and identity. Most of the old timers leave and the organization is a whole new organization, with different people and different aspirations.

Currently I‘m working on a project where the client wants us to deliver the system on a fixed date with fixed functionality. So far we have worked on this project for 3 months. Based on the amount of functionality we have delivered so far, the client has tried to extrapolate and feels that we would not be able to deliver the whole functionality on the final day. Based on these crazy calculations, what options to do we have to deliver the system on time?

Unfortunately, the obvious stupid answer to solve the problem is, add more developers and analysts. Break down the teams into smaller manageable work streams based on functionality. Add more architects, managers and more towers of hierarchy.

To step back and think, scares the shit out of me. We are already seeing some symptoms of failure. But we think we can break all records and rules. Afraid not. But we can surely do the same old stupid mistakes again.

Rick Mugridge has agreed to include the fit decorators I had written into the fit library. He plans to package them under fitlibrary.decorator.*

I have written an abstract class called FixtureDecorator. Anyone who wants to decorate any fit fixtures will have to extend the FixtureDecorator class and override the following 3 methods

protected void setupDecorator(Parse table) throws InvalidInputException;
If you need to pass any parameters to your decorator fixture, then write the logic in this method. Throws an InvalidInputException if your fixture expects some data, but in the fit test you have not set it.

protected void run(Fixture fixture, Parse table);
This is the main method which does the real decoration stuff and calls the super.run(fixture, table); when you want to execute the enclosed fixture.

protected void updateColumnsBasedOnResults(Parse table);
After execution, you might want to evaluate the results and mark the cells in your decorator as right or wrong. You can do that in this method.

Few things might change here and there, but this would be the essence of the fixture decorator.

This would be released under the GNU Public License. Oh yes! GPL.

Ideas/suggestions welcomed.

Acceptance tests are a nice way to capture requirements and test them against the system. I was wondering if we can associate some kind of performance criteria with our acceptance tests.

On my current project we are using fitnesse for writing/running our acceptance tests. We are using fitnesse to demonstrate completion of requirements to the customer. As of now we do not have specific performance parameters defined by the customer. But we want to write some tests that can keep a check on time taken for each user call.

We started using JUnitPerf for this. JUnitPerf needs end-to-end JUnit tests, which it can decorates to check the execution time. Soon we found we had a lot of code duplication in these end-to-end JUnit tests and in our fit fixtures. At this stage we started considering FIT to do this kind of execution/performance test.

So far I have written a spike implementation. In the current implementation, I have written a new fixture which is kind of a decorator around any fixture. Following is an example of how it can be used.

Going forward I‘m planning to write other decorators which can run the same fixture multiple time and so forth. Here is an example

Ideas/suggestions welcomed

This code, with a few other decorators have been released as an open source project. For more details look at the fitdecorator project.

It‘s been two months since I have landed in U.S. Recently I also moved into a rented apartment in West Chester, Philadelphia.

Before coming to U.S I was under the impression that staying alone, away from family and friends, would give me a lot more time for exploring Mother Nature and writing some open source. Well life is not that obvious.

Living in U.S has been quite an experience till now.
1. Right hand driving with the wheel on left is quite crazy. It‘s certainly more peaceful driving here. You don‘t have to look in all 360 degrees while driving.
2. Dealing with a whole different currency is also quite exhausting. There is always a thread running in the background trying to evaluate if it‘s a good deal or not. Fortunately I‘ve started evaluating things using only the U.S dollar and not bothering about the dollar to rupee conversion. Another strange thing I found was none of the products have a M.R.P [Max Retail Price] on them. Have to rely on the stores.
3. Predicting the weather is quite fun. When I landed in Chicago the sun was out till 8:00 in the evening and now in Philadelphia the sun goes to hell at 4:30 PM. The day light saving has its contribution to the whole hide and seek game. Another advice I got from a friend was to carry my rain jacket all the time because you never know when it starts raining. Two weeks back it was so cloudy and now the sun god is smiling upon us.
4. Cooking in these alien utensils with limited grocery reminds me of software projects. Always trying to solve the same old problem with different tools and technologies. Not to mention, the scarcity of resources and stupidity of some so called responsible/authorized people. Right from the pots, pans to heating appliances everything has a U.S touch to it.
5. We have to be different. Right from the electric switches to the door locks, everything works in the opposite direction [compared to what is in India]. Talking in terms of galloons and miles is also fun. Some more days before I adapt myself to this metric system.

Apart from thinking about all these things, I also end up spending most of my time cooking, cleaning/washing, shopping and driving. Experimenting with cooking is such fun, but cleaning all those vessels afterwards normalizes the fun. All this automation in house work is good but still eats up a significant amount of time. Wish we had self cleaning dust and waste.

This makes me think about the law of conservation of time. “The amount of time you have always remains constant”. Have I just found the new law which will change the world?