Monday 8 April 2013

The art of debugging

In software, everyone faces issues almost daily.  We need to be highly equipped to solve those issues.  Not all problems are straightforward to find out and require a lot of debugging to be done.  Hence debugging skills is of prime importance.  I would like to reiterate that everything in software development is an art.  Similarly debugging is also an art.  In this post I will focus on how to debug a software problem.

  • Understand the architecture
    • The more the number of components in a system, the more complex it gets to solve an issue.  It is critical to understand the architecture of the software / the module in order to debug a problem.  Suppose your system has a client web browser and at the server side a web server and a database server.  What if this setup is required to be able to work through a VPN connection? And you get an error in your web server mentioning that you "Could not connect to the database server", where do you think the problem might be.  The problem might be anywhere.  Hence it is very important to understand the architecture if you want to solve the problem quickly.
  • Analyze the entire picture
    • Once you get the entire picture, analyze the entire picture and try to see where the symptoms are lying.  I refer symptoms here because whatever you see is only a symptom, we need to trace to the problem in order to solve it.
  • From the symptom, try to trace the problem
    • Many problems tend to have more than one symptom, look out for those and try to get those hints.  In our example, "Could not connect to the database" is a symptom.  The problem might be due to various reasons.

Saturday 9 March 2013

MongoDB Schema Design - How to think Non-Relational


A nice video about MongoDB schema design.  To all who are new to MongoDB, MongoDB is a leading NoSQL document oriented database.  A table in RDBMS can be contrasted to a Collection in MongoDB, and a row in RDBMS table corresponds to a JSON document in MongoDB.

Key Points:

  • MongoDB introduction
  • Comarison of concepts of MongoDB Vs Traditional RDBMS
  • Schema Evolution
  • How to Model 1-Many and Many-Many relationships in Mongo
  • Queries and Indexes



Monday 4 March 2013

Introduction to NoSQL - Martin Fowler


Excellent video about Introduction to NoSQL by Martin Fowler.

Main Theme:
  • History of NoSQL
  • Families of NoSQL
    • Key Value Database
    • Document Oriented Database
    • Graph Database
  • NoSQL and Consistency
  • NoSQL Usage





Enjoy this video !! Very informative !!

Saturday 2 March 2013

11 areas an Agile Project Manager needs to focus on

In my previous posts I focused on the Attitudes of a Great Software Developer and the Attitudes of a Great Software Tester.  

An Agile project's success also depends a lot on the Agile Project Manager.  The decisions he takes and the emphasis he provides on certain areas will pave the way for a successful Agile Project.  In this post, I provide some key points that an Agile Project Manager should focus on, for the betterment of an Agile Project

  • Employee hiring
    • First and foremost, an Agile Project Manager needs to hire the right people for the project.  Apart from the technical skills and non-technical skills required of Agile teams, it is imperative that the chosen candidates adopt to the Agile practices and are themselves Agile.
  • Technical and Non-technical grooming
    • Once into the project, the candidates needs to be groomed to meet the project needs and also grow further.
  • Employee motivation
    • I always believed that Employee motivation is one of the Critical Success Factor of an Agile Project, for that matter any project.  Motivated employees can do wonders if provided with the right environment.  Motivated employees go that extra mile to achieve the common goals.  Hence an Agile Project Manager needs to put high emphasis on this point.
  • Engineering Practices
    • There are a lot of engineering practices that make an Agile project successful.  An Agile Project Manager should focus on putting the right Engineering Practices to place. He/She should not forget that there is an overhead in following certain practices, but once fully functional, they start to provide high returns on the investment.  For ex. following Automated Unit tests and TDD can be very difficult to start with, but over time, developers get into that practice and the results start to follow.  

Wednesday 27 February 2013

MVP - Minimum Viable Product strategy

Not all good ideas turn out into great products.  There are quite a few products that fail in the market due to a variety of reasons.  But does it stop us from investing in the Products? How do we find out if a Product is going to be a hit in the market?  And more importantly how do we find that out by investing the minimum amount possible.  Enter MVP - The Minimum Viable Product.

The concept of MVP is getting acceptance throughout in the area of Product Development.  It is a concept largely used by start ups.  And it will immensely help new product design and development in larger organizations.

What is an MVP?

Our objective with a Minimum Viable Product is to provide a mechanism for maximum learning about the target audience or the target market with the minimum effort.  Does it mean that we only ship 3 out of the 10 features that is required to hit the market at the earliest.  No.  The concept is beyond just the product features.  A Minimum Viable Product takes into account the Product idea, how it generates interest among the users, what features that the customers or the market really wants, demand for the product, etc.  It is a strategy that is used for learning about the customers early into the product life cycle, so that they can make the changes for the good.

Strategies for MVP

Sunday 24 February 2013

Software Design in the 21st Century - Martin Fowler

Great talk from Martin Fowler, focussing on 3 topics

1.  Schemaless design
2.  NoSQL and consistency
3.  Software Design



A must watch !!!

Saturday 23 February 2013

11 Reasons why products fail in the market

Not all the product ideas get transformed into actual products.  Only a few pass that stage and get to the market as a Product.  And there are even fewer products that are actually successful.  So what are the reasons why products fail in the market.  In this post I am outlining a few reasons in my practical experience which can lead to the failure of a product.


  • Not having a directed product vision
    • A product needs to have a vision, a roadmap at least at a high level.  Product roadmaps might change depending on the feedback from the customers / prospective customers / market research, but you need to have a product vision as you go along.

  • Not enough investments for the products
    • It is highly important that all the investments need to be made for the product development, testing, marketing, sales and brand promotion.  Without investments, the product will eventually die a slow death.

  • Too late into the market
    • A product needs to be in the market at the right time.  If the product is late into the market, there will be many competitors for the same market, and hence competition will be tough.  It is highly desirable for any product to have that First Mover advantage.

  • Too early in the market
    • In my previous point, I mentioned that a product needs to be in the market at the right time.  Even though being early in the market is a highly desirable option, however being too early in the market when there is no maturity in the market will obviously lower the chance of product success.