unit Testing / Code Reviews

Every individual developer who writes code has an obligation to ensure that the code satisfies the needs, that it was intended to serve. Other then the stated need, an implicit assumption is that it is robust enough. The Developer needs to review or test his piece, to ensure that.

 

So what should the developer check for?

 

Input validation

Any piece of code usually has some kind of an input, either through a UI, or as parameters for the function/ method or Data that is read from a file, db or some temp memory location.

is the value within the expected min/max limits, is it null, is it one of the expected values(in case of enum), is it numeric / alphanumeric / allowed special characters, is it the incoming data too big that it does not fit into the expected data type size limitations. Is it in valid format? (For example dates, regular expressions) 

 

Valid Comparisons

Any comparison between two variables, x==y needs to checked if x & y are of compatible data types,

mode of comparison is also an important consideration, equals, less then, greater then, like, which is the appropriate one to use, based on the requirement or circumstances. has less then been used when less then or equal to is more appropriate, or is equals used, when like is more appropriate, ensuring that the condition being checked will return both true / false and is the correct set of statements under true / false or is it reversed. These are the kind of questions to ask oneself

 

Loops & Conditions                                         

All kinds of loops and associated conditions such as select / case, while, for loop, will need to be looked at to check if, either the first element or last element may be left out, or the possibility of overshooting the no. of elements, problems due to the index (starting from 0 or 1), conditional checking such as < or <= which is the correct one? Proper use of break or continue to ensure that exit from loop happens, a default else or a default case, in case of a switch or a select case statements. another item not necessarily of the same category is recursive functions related problems, which need to be looked for.

 

Assignment - type mismatches

When the language being used allows implicit conversion among data types, there is a possibility of wrong assignments, a variable declared as a string might be assigned a number, date etc. but when reading from that variable and converting back, you will tend to get errors related to data type mismatch. when creating a variable of date/ time and assigning value from another input variable, then format, related issues may crop up especially when supporting I18N, 04/11/2008 may be interpreted as 11th April or 4th Nov, need to be watchful of such possibilities.

 

File and DB Access points

Another important area is proper closure of connections and freeing up of resources, in case a file is opened and read, has it been closed and the memory assigned been properly disposed. this applies on similar lines to Database connections also. Are the db objects such as record sets closed, if not, this may result in unwanted row level or table level locks. Resulting in a wait for ever, until the process is killed.

the same applies to files too.

 

Standards & Consistency

From a readability perspective the code can be checked for naming conventions, proper indenting, correct and relevant comments etc. well structured, preferably with an header indicating the purpose, and where this piece fits in the big picture.

 

 

Exception handling

In all of the above scenario's of failure conditions, having a mechanism to capture those exception cases, and logging that information for debugging purposes, and throwing a meaningful application defined error / exception message back, is important, during a review process we could check if all of the important areas where possibilities of exceptions are high, have the relevant mechanisms to catch them.. btw, this can be handled as a separate topic in some future discussions (possibly... not probably J )

 

 

I guess taking care of these, should make the code good enough, and ready for integration with other parts of the system.

Types of Integration (problems)

Integration can mean a lot of different things. But for our know-how we will stick to the scenarios below (for now).

 

Projects can be of many flavors; I have come across a few like the ones described below, let us dwell on the details of the advantages and Risks involved in each of these scenarios separately.

 

Project Management Related

 

Multi – location Development

 

The Multiple modules that form part of the Product may be developed by team members who are working from different geographical locations.

The main challenges faced are related to Time differences and Cultural differences. Good Clarity on expectations of Quality of the deliverables from each of the teams, having realistic timelines considering the local culture and calendar are key to satisfaction here

 

Procurement of Components

 

The Project may involve using a third party component as part of your product or service, You will usually base this decision on the fact that it is cheaper to buy then build it yourself, or you do not have either the competency or the time required to build.

The main challenges here are related to licensing the product, rights to re-distribute, future support availability, maximizing the utilization, in lieu of the price paid. Etc. There are cases where the vendor is asked to make a few changes or customize the components to your needs.  The Key here is to ensure that the vendor will continue to exist in the future, will be capable of providing timely support, and the procured components meet your quality expectations.

 

Joint Development

 

Two or more organizations may want to leverage each others strengths to capitalize on a market opportunity that requires them to work together to create a solution. This is the most tedious for the PM to manage, This includes the challenges in the above two scenarios, and also the added responsibility of qualifying each of the Individuals deliverables and the solution as a whole. Other bottlenecks may include revenue sharing, and agreements on providing technical support to customers. If not handled proactively, problems arising at installed locations can be tossed around as not my problem, or it’s on his side of the fence.

 

 

Technical Issues      

 

Data Mapping

 

When sharing information between two products, The data representation and Semantics of one product will not be the same as the other product. Identifying these dis-similarities and resolving them in mutually acceptable terms is always going to be a pain. A lot of Integration related problems arise from this mis-match if not captured during Requirements and Design stages.

 

Module or Component Interfaces

 

When the parts of a solution are developed separately, either in-house or procured, as and when these parts need to gel or work with each other. Interface mis-match issues crop-up resulting in a lot of re-work and schedule slippage to get the pieces to work in unison. Clarity in communicating the problems to the concerned teams, and getting it resolved will take multiple interactions. Geographically dispersed teams and working with teams outside the organization can further strain to the developers

 

 

This is not an exhaustive list of categories; just a few that I have come across in the last couple of years.  I will explain further details of problems and solutions related to working with external organizations and joint development in a separate article.

 

 

                                                                                     

 

                                                                                    

 

                                                             

Integration - Convergence

While the simplest of integrations may involve a straight forward Data transfer between two backend Data stores,
Next on the line can be a need to update multiple data stores, and then of course, do it real time.
Subsequent scenarios may involve transformation of data to cater to the semantics and the idiosyncrasies of the destination systems.  
You will come across entities or their attributes that does not have an equivalent entity on the destination. You will also come across Need to have some mandatory entities created in the destination store, when the source has nothing equivalent to send across.
Further there can be workflows triggered based on incoming data, and of course the workflow themselves may enable data changes across multiple systems

 

So what, why should I be concerned?

Well unfortunately or fortunately, I have had the opportunity to work on programs which involved Integration between such disparate systems.
We have had successes and failures along the way, with a horde of factors contributing to those results.
It makes sense to reflect on what I learnt and summarize for future.

I will probably take a couple of weeks… to gather my thoughts.

nuggets from Paulo Coelho

When we sense that the time has come for a change, we begin -- unconsciously -- to run the tape again, to view every defeat we have experienced until then.        "And, of course, as we grow older, our number of difficult moments grows larger.  But, at the same time, experience provides us with better means of overcoming those defeats, and of finding the path that allows us to go forward.  We have to play that second tape on our mental VCR, too. "If we only watch the tape of our defeats, we become paralyzed.  If we only watch the tape of our successes, we wind up thinking we are wiser than we really are. "We need both of those tapes."

5 essential tasks of a PM

1. Satisfy the Customer

2. Meet the Requirements

3. Deliver on Time

4. Deliver within budget

5. Keep the team Happy