Type Inference - NUnit 2.5

//[TestFixture(12.0,42,TypeArgs=new Type[] {typeof(double),typeof(int)})]
[TestFixture("Hello", " World!",TypeArgs=new Type[] {typeof(string),typeof(string)})]
public class TestClass<targ,targ1>
{
private TArg val;
private TArg1 val1;
public TestClass(TArg val, TArg1 val1)
{
this.val = val;
this.val1 = val1;
}
//[TestCase(5.0, 7)]
[TestCase("Hello", " World!")]
public void TestTypesOfArgument(TArg t1, TArg1 t2)
{
Assert.That(val, Is.TypeOf<targ><targ>());
Assert.That(val1, Is.TypeOf<targ><targ>());
}}

Uncomment the commented lines and comment the other attribute to explore and know more!

Happy Testing of Types! :)

Product Development and Agile

Let us consider a product that has been released in the market and has won accolades for its UI. The next version, minor or major, of the product would obviously benefit from the appreciation but what if the product owners decide to tweak the UI more and settle for the menu’s look, feel and location.

Let us say that the below image represents the current menu look – the traditional drop-down menu. Imagine the plight of a designer who cannot see the changed look of his text.


And the below image is the proposed, new look for the same feature. This not only complies with the Mac and Windows Vista themes, it is also space saving that icons pop-up and reveal functionality as and when necessary and the menu itself can appear at the corners of the screen just like a rotating dial!

Great feature! So, what is the best way of developing this new feature?

There are many ways of developing software but the Agile way fits in on all counts due to its very nature of composition. Below are the reasons that the Agile way is a tailor-fit development method for products.

New Product/Feature plan and scope of Agile in it

Agile was formulated to suit scenarios where frequent or dynamic changes in requirements are present. And for a product’s lifecycle, these are the greatest impediments to the products’ success. Constant vigil on competition, growing technology and market demands make Agile the best suited way of software development for products.

There are lots of similarities in the nature and make-up of Agile teams and Product teams.

Both consist of talented, passionate and committed members. Both the teams are self-driven, self-motivated and innovative. Both teams are constantly looking for ways to improve the existing software towards “better software”.

The below table shows a comparison in the make-up of both the teams:

The best way, recommended, for UI implementations is to make sure that the designers and developers do a “Stand-up” meeting every day. This removes all ambiguities in what the designers envision and what the developers develop. The presence of QE (Quality Engineering) or QA, as is more popular called,  is also a great help as the scenarios become known to them and testing can happen in parallel.

Have a collaborative workspace.

Product development insists on innovation and creativity.

A collaborative workspace, where a team working on the same component/story when placed inside the same workspace will find better shared understanding and clarity than seated away in different cubicles or rooms.

Avoid cubicles, separate rooms and insist on a dining room kind of a layout with people sitting face to face on either side of the table.

Use LCD monitors that are compact and slim in shape; make sure the lighting is pleasant and well-ventilated.

The whole room is meant to be a complete workspace for the whole team and so have sufficient mediums of communications like a Video Conferencing facility, white boards, flip charts etc.

The stand-ups, video conferencing, telecoms and discussions are artifacts of an Agile method that increase the agility in the team and therefore, if you conduct all such meetings in separate places it would only lead to more loss of time, which will decrease the agility in the team.

The Agile "dryndrome"

When I used Procomm to develop (!) my first software in 1989 for Deccan Herald, a newspaper company based in Bangalore, it didn't seem to be a great activity. Of course, family members went ga-ga over my newly acquired skills and the amount of money that the effort brought in! In fact, I remember my father was almost glad that he had got back more than half the money he had spent in educating me and lavishly gifted me a good percentage of it!!

The approach was simple and I remember using a character from the character set to create a splash screen that evoked an envious "Hey, is this a Unix program?". In those days, anybody who programmed for Unix was considered to be a great techie!! The only time that I had a tryst with Unix was to use a dumb terminal to play PacMan!

I went into a non-IT profession, part-time, for about 3 years and returned to the IT industry in 1992 or thereabouts with my own company called "Semantix Computers". Looking back, even starting my own company did not mean a lot, as very few Airline companies, big institutions and travel agencies ( to impress their Airline friends) actually went for customized software development!

The first thing that comes to my mind when I cast my mind back to those days is the simplicity with which I used to work with the customers. The requirements were clear because the customer did not know what she wanted !! So, I had to patiently and correctly understand the requirements to the extent whether the customer wanted the print to be on a dot matrix printer or on a Laser Jet (the new swanky toy then!) printer!

If the software crashed, no worries! The customer could be told, "Please restart your machine!" and if the customer said, "I had forgotten to save my data. Does this mean that I cannot recover them now?" Not irate, not cursing! Just a simple query that would be met with, "Please remember to save frequently from now on" and you could actually chide the customer !!

Today, the same scenario possibly may exist in a rural village deep in Nagaland or in a pygmy country!

Requirements gathering, which has often been touted as possibly the most difficult of all phases of the SDLC, is missing just that one thing - the naive, trusting customer!! The customer, today, is far more educated than his predecessors as are the users and consequently, the definition of Quality, too, has changed. The growing competition in the market makes that revered Unix programmer almost a liability and a techie, who stresses on extensive documentation, a sure shot recipe for project failure. And, project failures across many studies have all identified, "Requirement changes" as the top reason for IT project failures with organizational and IT letdown as a close second.

This dread of requirements changing has possibly been the furore behind the Agile Development approach and the subsequent "dryndrome" that has emerged out of this race to become Agile!

A "dryndrome", it is, because of the dread that has driven its adoption.

Looking back to the early days of software development in India, I attribute the success of Agile methods to the increasing lack of clarity in the approach to software development. It is as simple as this; if you have not understood the requirements, it is natural to get this phase clear before going ahead with design or implementation!

There is no substitute for natural stupidity as there is no substitute for common sense. And since these are the essential elements in any sanity check list in a SDLC, that people are still failing despite have adopted Agile methods is a clear indicator that a method becomes madness if not understood correctly and not applied in the right context.

The number of interpretation that Agile methods have been subjected to is mind boggling! What has emerged for me to understand from my various interactions with the wannabe Agilistas or the wannabe Agile organizations is just this - if you do not have a first hand experience of the evolution of the IT industry in India then you will find it very difficult to truly understand what, why and how Agile is and, why it should be adopted and not implemented!!!

The "dryndrome" is likely to continue and the race for adopting Agile is likely to result in a few more newer Agile methods to satisfy the partially baked palates of the enthusiastic wannabes!