Wednesday, April 15, 2009

Getting everyone on the same page


If you ask your fellow team members to explain what they understand by ‘Test Driven Development’, today you are likely to find very few common thought lines.

The reason behind this is not vague understanding, it is different application knowledge.

If the only tool one knows is a hammer, everything looks like a nail.

Similarly when somebody begins doing ‘Test Driven Development’, the initial learning curve to accept the way of writing software is pretty steep. There are no standards. One tendency is to copy and not think. Because there is no reference, One can either be happy with the frog-in-a-well living or completely insecure with the efforts. Whatever the case, getting things right in the first place is hard learn in the initial stages.

With continuous efforts and trial and errors, one can eventually discover the best practices by experience or by referencing the experts in the industry.

As a software architect, when a system design is completed, there is effort needed to bring all the developers on the same page.

I am trying to think on lines of documenting my experience and information sharing to get everybody to generate the common minimum standard output expected as a developer.

That is another problem to be solved.

Software Knowledge ‘Application’


When I was quite young, I was once asked a mathematical question to be solved mentally.

What is the result of 0.17 * 0.83 * 2 + 0.17 * 0.17 + 0.83 * 0.83 ?

It took me several minutes of mental calculation when I got the most approximate value.

It was one of the earliest A-HA moment of usage of learning equations in mathematics.

I thought it was cool. Who knew an equation like (x+y)^2= x^2+y^2+2xy would be useful mapping of the problem asked.

Another A-HA moment of mathematics had come when a friend discussed about the use of Curve equations in a computer program to determine the trajectory of a object thrown in space like a Baseball pitch ( Bowling in cricket parlance). It was astonishing to discover that even though I had memory to mug up all the equations in the world, I was not really applying the solution to the real context in the world.

Do you ‘always’ apply your engineering brain to solve all the problems you encounter in your daily life? Do let me know.

As a solution architect in the software career, I have encountered numerous challenges and resolved them. Many resolutions were top of the head, some were innovative thinking in the limited knowledge and some were mediocre. There is always a room for improvement in the next iteration.

According to my limited knowledge and experience, there are 3 kinds of knowledge out there.

One is Reference

Second is Mapping

Third is Extrapolating.

Reference knowledge can always be searched.

Whatever knowledge you already have at your disposal can be used to Map to a solution for a problem at hand.

Extrapolating requires ‘Mapping’ the right context to the right problem.

The main concern I have always had about education is ‘how do we use the learned knowledge in our head to resolve problems lying in front of us’.

As I see TDD examples in the search space, I find that most of the examples are pretty lame and not really teaching the mindset of Test First Development.

Secondly over a period of TFD, there are some best practices which one learns by refactoring and improving on every iteration.

Thirdly like with every new technology or like the Six Blind Men, everybody interprets the methodologies to suit their own perceptions and have a own variant of the methodology.

Given sufficient time, I would like to change the curriculum’s to include ‘Real World Application’ and ‘Problem Mapping’ skills to be imparted with every new skill out there in the world.

That is another problem to be solved.