My Learnings...

The deadlines must not be streched.

UNIT TESTING IS VERY IMPORTANT..

When some resource tells, i've completed the module, they must show unit testing as well as functional...

Provide complete information for the resources. Regarding their logic..

Make Sure they are not hard coding any things in the Application..

Before starting coding, do a brain storm session and ensure what reusable code and design can be help us out...

DATE FORMATS ARE Always a headache.

Use Convert.Datetime instead of Date.parse...

ASP TEXTBOXES made as Readonly fields wont return any value to the server, So use always HTML input boxes for readonly (Calendar)

Ensure that WBS is updated if necessary before start of coding.

ALWAYS HAVE A PROPER TIME ESTIMATE..

FROM THE NEXT PROJECT, JUST RECORD THE TIME REQUIRED TO COMPLETE A USP/ FORM OR WHATEVER, SO THAT WE CAN USE THAT INFORMATION FOR FURTHER TIME ESTIMTATION.

ASK FOR THE TEAM'S LEAVE PLAN...

ALWAYS BE PREPARED FOR ANY KINDA RISKS..

production issues.. needs to be addresses...

first ensure the design is proper in the stage of designing only.. Once done, we must not tinker with it always...



---------------------------------------------
My Observations and learning’s while working on MER

Requirement Gathering

I. Don’t Assume Any thing, get information properly

II. If we are gathering requirements for a particular page, then make sure all fields are covered, don’t miss even a single field.

III. MOMz are a must. Also specify as much details as possible in the documents so that in future it wont affect the functionality

IV. In SDD, Database level details must be specified very clearly.

V. If there are some conditional constraints that are very decisive, then it must be clearly specified.

VI. If there is any interaction with a third party system or a different system, then make sure, an exactly similar environment is available at the development end. Or else, while integrating both, problems are meant to rise and time also won’t be on our side.

VII. Once the SRS and SDD are done, just go through the same and do as it says. Don’t assume or remember things and do. SRS / SDD must be the source for coding. Just Open it and type the code.

VIII. It’s a very bad practice to start development without the SRS and SDD being signed off or else except more headaches in the later phases of the project where in the user may demand for requirements which you have not even heard of.

IX. If something can be done technically in more than one way, Keep all the options in front of them and let them come back with the option feasible for them.

a. For Example, Consider Client Side Validations, This can be done in the following ways

i. Javascript (Which we follow religiously)
ii. VB Script
iii. Field Validators.

So, instead of suffering last minute changes, we can avoid this at the requirement gathering stage itself.

Database Design

I. Do not have unnecessary table and Stored Procedures, which will just confuse us needlessly.

II. Make sure for a particular field A, the data type and the size is correctly defined.

III. Follow one Case, Either all BIG CAPS or all small caps. NeVeR BOTH

a. The above statement refers to the naming conventions of tables / views / stored procedures as well as Script statements

IV. If there is interaction with another database, just make sure views are created to access the same instead of directly querying onto it.

V. Creating VIEWS is very much important and it will reduce a lot of statement in the Where clause.

VI. If we are inserting / updating to more than one table in a Stored Procedure, Sql Transaction statements are a MUST.

VII. Also, most importantly try to follow the EXACT Coding Standards specified in the SDD.


Coding

I. Also, most importantly try to follow the EXACT Coding Standards specified in the SDD.

II. If there is some functionality which is common across the entire layer / Application, then use a common class file; write that piece of code here.

a. If there are changes, then it can be easily dealt with.

b. For example, if there is an ACTIVITYLOG functionality to be implemented, then

III. Add one line of comment for every method and if there is some complex code written, a comment is always necessary there. All comments must be short and live up to the complexity of the code.

IV. Make sure the pages cannot be directly accessed. Use Session Variables to ensure Direct Access to the application will not happen.

V. All datasets / Sessions or other disposable resources must be disposed where ever applicable.

VI. Try to user Data Reader where ever applicable, since the performance of the application will take a huge hike.

Testing

I. Try to see the application as a USER instead of a developer. There can be a chance wherein we can think of some changes that can help the user, do his work more effectively

II. Give the code to someone very new to the application and so

Implementation

VII. G

UAT


I. G

II. Give more importance to Design as well, CSS and alignment details.

III. Try

IV.

---------------------------------------------