OJT vs. Traditional Training

1.1 OJT

Definition for this purpose:

Make a just-out-of-college or almost-so new employee to work on a problem in an ongoing project and let him come through it.

Action:

The employee should be handed a problem that has enough complexity. The employee has to setup his or her environment based on the choices made for the project. The employee could solve the problem in parallel with the team. This will prevent him from being a bottleneck, but at the same time allows enough room and an actual problem to think.

Additionally he can also be made to troubleshoot some issues. These issues could be current issues or issues that have been solved but have educational value.

The employee can be presented with a list of training courses, which he can attend to accomplish the task and should be encouraged to ask for one if he is stuck.

Result:

Employee learns to solve some of the problems that may crop up, which will help in production projects. The training becomes a pull model rather than a push model. This results in better take away from training. Since the training correlates with the knowledge required to solve the problem at hand, the information gets registered better.

But, it may also turn out that the employees don’t ask for training as most of the problem might have been solved by one-off discussions.

1.2 Traditional Training

The usual training models involve pushing the information to the employee. The information contains mainly of overview of technologies, which could be easily obtained from the Net and information on standards and conventions. Most of these are not registered in the minds of the employees, as they could not match this with a real need.

1.3 Hybrid Model

A better approach will be a hybrid of the above two. Let the employee go through OJT for a month or so until enough curiosity is awakened and then put him through the training. The training should involve general, but critical information on fundamentals (e.g. fundamentals of webapps – Web server, app server, ports, request, response etc. along with show and tell with a request analyzer), specific technologies (with emphasis on practical application), unit testing. Ideally, an employee could be trained in multiple technologies and then he may align into one or many of them.

1.4 Things that have not worked

Some approaches have not worked very well in an OJT:

• Working on an internal project

Typically, this internal project will consist only of trainees/new employees. The whole team has an air that it is an unimportant one. Most of the times the project is not utilized.

• Involving in a live project, but without any real problem to solve i.e. left to handle routine activities
• Giving a problem from a real project but not attaching any importance to the results or worse not expecting any result at all

Better approach will be:

• If it is a critical internal project, create a real team for it with proper team lead and some senior developers. If not, scrap the project. If it is not important enough it is not worth developing.
• Utilizing an employee effectively only when forced does not add any value to the team. Prepare the employee for tomorrow’s requirement. Automate routine activities and share/cycle non-automated ones amongst the team.
• Push for the results. Use parts of the results where it could be. Expect something that could be used. Give the employee a sandbox branch in the source control for the project and let him commit his changes there.

Using JTestcase for unit testing - Part I

Test Driven Development (TDD) has become a very critical element in today's development with systems being more complex and time-lines and budget as tight as if not more tighter than ever. This has caused more and more unit testing frameworks and support libraries to be released. JTestcase is one such library that helps in separating test data from test cases.

While almost everyone appreciates the benefit of unit testing, when it comes to actually developing the test cases, there are various deterring factors that quickly make us lose interest in writing unit tests. One those factors is the test data. While test data for simple computations may be very easy to build, things become tough when we are dealing with domain objects that are huge and consist of complex fields within them. The mere size of them and the code that gets interspersed into the unit test code to create them adds a lot of clutter to the unit test code, making the code tedious to follow and maintain.

JTestcase helps us to separate the data from the unit test code into XML. It helps create simple domain objects easily and uses a part of JICE framework for building complex object trees. JTestcase has facilities to represent assertions in addition to test input and output data. JTestcase XML structure is as follows:

Class to be tested 1
......Method to be tested 1
...........Test case 1:
......................Param 1
......................Param 2
......................Assertion 1
......................Assertion 2
............Test Case 2
.
.
......Method to be tested 2
.
.
.

While JTestcase has support for this structure, I have found that another way of organizing test data using JTestcase seemed to work well and seemed to be in line with the expectations of various teams that I have worked with. In the subsequent parts I intend to blog the conventions that we followed when depicting data using JTestcase (along with examples),which worked very well for us.

In the meanwhile, following are the links to this framework and JICE:

JTestCase
JICE Engine

First inspiration to blog comes from unexpected direction

I never thought I would find anything interesting to blog. But, today something inspired me to start blogging. But, the thing that inspired me was nothing amazing. It was a simple train travel. I have always liked travel and especially train travel. During my college days I used to travel back to my home town with friends and every time I used to look forward for the vacation and excited by the travel itself in addition to the excitement of meeting your dear ones again.

But, this travel that inspired me to blog is unique. I usually don't open my computer while I travel. I like to look out the window and enjoy the passing scenary. But today I thought of using my laptop aboard the train from Edinburgh to Peterborough. The first thing that struck me was, sitting by the window, it was like a corner office - with one difference though - The view out your window keeps changing. Especially in this route with scenic farmlands of Edinburgh and other places en route, small streams, river et-al in the time of the year of receding winter, welcoming spring.

This train is an east coast train and it has a decent free WiFi connection. I am writing this blog aboard that. Interesting. Thanks to technology and thanks to nature - the mix of which caused this inspiration.