#Finale software stable release code#

In Shopping cart services I have distributed into multiple layers like persistent, connectors, rule-engine, discount-engine, payment and services. I have first divided the complete system in two modules of front end having UI and shopping cart services. In addition to this there were certain business logic like we need to apply some business logic for discounting, part payment. I have a similar instance in another project, I was given to develop a shopping cart, it was new for me and the products were of different types which needs to be sold and were provided by different suppliers. To make it more clear I use to divide a big project into multiple layers/components, it helps in giving micro level clarity for execution to the developers and QA. Once the database is designed the major part of the solution is very much visible and clear.I am a firm believer that a good normalized entity relation database would be a back bone of any product.

#Finale software stable release code#

This ultimately resulted in less complexity to find the vendor code from normalized city code and vice-versa. After reviewing it my manager has suggested me to have one normalized city, vendor and vendor normalized city mapping table and put vendor city code in the mapping table itself. I have designed database to join normalized city table, vendor, vendor city and vendor city normalized city mapping. Each vendor were having their own city code. I was designing an aggregation service which were supposed to aggregate multiple vendor's service which were providing multiple services for multiple cities. In general, I always go for normalization, but in one project I learned how de-normalizing the big tables especially where the parent table don't have more than two or three columns benefits. In designing database, I always try to simulate the real world entities and their relation into database. Design Architecture : After finalization of approach, focus on designing database, components and layers.I have developed the reporting framework around 6 years back and that framework is still there. I told him that this framework will take around 1 week to build afterward adding reports would be a couple of days work only and it would also impact in fast QA cycle. After 4 days I had a design in my hand, which I shown to my manager. I have spent around 3-4 days just in thinking and designing the framework. My manager told me to deliver the project as soon as possible, I asked him that I want to make a framework for report which will help in maintenance and in making new report then he replied that your code is not going to be alive for more than 2 years, and it will be changed in refactoring. I can recall an instance of a project, in which I need to create multiple reports for MIS. Afterward comparing them on multiple parameters like maintenance latency etc and come to choose one best approach.

Think Think Think : After getting the understanding of scope and objective of problem, one should spend more and more time in thinking the approaches.

It is very likely that the impact of a problem could be more than what we estimate, and in such cases later we meet the new scope of impact wider the scope of changes will be required. Before this meeting I always prepare myself with the objective questions for stakeholders. It require couple(or more) round of meetings with all stakeholders.

Understand The Problem First : Once we get introduced with a problem my first step is to define the scope and impact of problem.

In my career, I have noticed some very small pointers which helped in the timely delivery of product and stability of the product, which I want to share as below:

Since last 12 years, I am in the software development industry and have been part of several product development.