Whether you a newbie or an experienced programmer, this information would help you, with more than 15 years of experience in the software development, I would like to share some basics which you should know to call yourself a professional software developer. If you are just a hobbyist programmer, you will still benefit by learning how to apply an effective methodology to your approach.

Let’s dive in..

Are you building the right product?

Isn’t it simple to sit down with the customer and ask what they want, what is the big deal!

Sorry but it is not really that easy, sometimes the problem is that even the customer is unsure what they want, as a software provider it is your duty to build the right product for the customer using the technique called “Requirements gathering and Analysis”

There are several ways to gather requirements:

  1. Have the customer provide you a list
  2. Surveys
  3. Interviews
  4. Focus groups
  5. Observations
  6. Use case analysis

Use case analysis is one of the most “Effective” way to determine what the customer/s really need.

A use case analysis is a process where you describe a real usage scenario, from the point of view of user, no tech jargon and absolutely no technical information.

Lets take a simple example here.

Use case name: Show ratings

Actor : Shopper

Main success scenario: When a user looks at the product, based on all the ratings (1 being worst and 5 being best) it received by other shoppers, average should be calculated and should be displayed next to the product.

There are other things to consider when you are evaluating a use case:

a) Extensions: Do you want the ratings to behave differently based on different geographic locations, i.e only last 2 years average for US customers and last 5 years average for customers from Canada.

b) Pre conditions: Should the shopper be logged on to be able to see the ratings?

c) Post Conditions: Can the shopper give a bad rating after 3 months of purchasing the product?

A really good way to put this together is by using “USER STORIES”, you can say something like:

“As a shopper, I should be able to see the rating of the product I am interested to buy”

There will several sub stories to this story based on your extensions, pre-condition and post-conditions.

Requirement analysis is basically divided into two sections:

a) Functional requirements :

Any Requirement Which Specifies What The System Should Do.

Example: Software should display rating of the product.

b) Non Functional requirements: What are the characteristics or property of the system.

Any Requirement That Specifies How The System Performs A Certain Function.

The last but not the least is “PROTOTYPING

In this phase, an actual prototype is designed based on the information gathered from quick design. It is a small working model of the required system.

After doing all this, you will really know if you are building the right product.

Great , You identified what you are building, now lets plan!

Big aspect of planning is “Modularization”

Modularization is a simple concept, just divide the big problem into smaller problems and interface them using proper channels.

When you modularize , always take the approach of “High Cohesion” and “Low Coupling”

High Cohesion means all the routines in a module, or all the code in a routine work for a central purpose.

Low coupling means the modules are not interdependent on each other. How much modifying module X affects module Y?

Following the above will help you to design a robust system with these benefits.

a) Separation of concerns

b) Increase code readability

c) Easier to debug and fix problems.

d) Easy to maintain

Good job with putting together a great design , lets code!

Finish all the above before jumping into the actual development.

We can use common design patterns to write some effective code. The fact remains, however, that Design Patterns can be incredibly useful if used in the right situations and for the right reasons. When used strategically, they can make a programmer significantly more efficient by allowing them to avoid reinventing the proverbial wheel, instead using methods refined by others already. They also provide a useful common language to conceptualize repeated problems and solutions when discussing with others or managing code in larger teams.

This link will provide you some great information about the commonly used design patterns:


Some of the good practices include:

Variables names should be meaningful and descriptive

Function names should be verbs – queryDatabase, writeToFile etc

Format your code properly and please add comments.

If you are working with a team , please use a revision control system like Github or Bitbucket. It is easy to keep track of the revisions made to the code.

Let’s talk Testing

Testing is not “JUST” for finding bugs. It is mainly to see if the expectations are met!

Manual testing is the thing of the past, you need to have “Automation testing” , which means you have a tool which can perform the testing for you based on specified criteria.

Testing involves several methods:

a) Unit testing: Done per module, helps to pinpoint errors quickly.

b) Integration testing: To test if multiple modules working together is performing the job as expected.

c) Black Box testing : Internal implementation of the module/s is ignored. Supply input and check if the output meets the expectation.

d) White/Glassbox testing: Internal implementation of the module is exercised.

e) Security testing: Test for security vulnerabilities.

There are several more testing methodologies, one of the most famous methodology is “Test Driven Development” (TDD)

  1. Write a test
  2. Watch it fail or give you unexpected result or does not work at all.
  3. Write just enough code to satisfy the expectation of the test.
  4. Repeat from Step A

   This would help us in several ways, 

  1. Keep our timelines intact by not developing anything more than what is required for that test to pass.
  2. Give the control to tester at the very beginning, so they don’t ask for MORE or LESS after the development is complete. Give them exactly what they want.
  3. QA understands at the very beginning the “KNOW HOWS” to test the feature.
  4. Since QA knows what to test beforehand, they can get busy developing the automation required to test when the developer is working on the code change.

Final Notes

After you go through all the steps, you are ready to ship the product out of the door. The customers may ask for more enhancements or new features . Well, go back to drawing board and start again from requirements gathering, every new feature to your existing product should go through the entire process again.

I hope you liked the blog, and please do share your comments below. Thanks for taking time to read my blog.

Leave a Reply

Your email address will not be published. Required fields are marked *