Our Philosophy on Software Development

The truth of the matter is that software development is more of an art than it is a science. The developers are creating something from their own perspective. The same problem can be solved in many different ways. That is where the creativity comes into play. We follow an agile scrum process in creating a product that allows us to be flexible and fast to market.

The ideal situation is to write code that is self-documenting. Then in this case, the changes are only made in one place. Even with the simple case of writing comments with in your code could become troublesome. Sometimes the code is updated but the comments are not. This leads to more maintenance headaches. Our automated processes minimizes these type of issues.

Our approach takes a layered view of the development cycle and each layer is interchangeable. This gives us the added flexibility of changing the requirements during the development, should the need arise. We are able to adopt to the needs of our customers very quickly. We always have shippable software at the end of the sprint. But foremost, we avoid making any changes to the sprint backlog while in the current sprint.

It all begins with our requirements gathering process. During this phase, the goal of the project is well defined. We might use stories that are already in the product backlog or we might have to add new stories into the product backlog. At the beginning of each sprint we pick which product backlog items will be addressed in the sprint. We then move on to the design phase. The first sprint design is the most important one as it lays the foundation for the upcoming sprints.

Even before we write one line of code, we want to have the whole design on paper. We breakdown the software from top to bottom. The whole development team understands the goal. This makes everyone more alert to what is going on. In so many cases we have seen, the individual developer might not know how their small part fits into the big picture. We feel that when everyone knows the big picture they can make suggestions which greatly improve the overall product. This comes into play even more during the testing, documentation, and implementation phases. All the people involved in the project come to know the product intimately.

We believe one of the biggest part of the sprint is the dev-integration testing, which should happen about 50% into the sprint. This involves the dev team assigned to a user story to have a dedicated QA engineer examine the released code in a QA environment. Issues will not be entered into the QA system but rather addressed on an informal basis. Showstopper type issues are found in this phase. Then the code can be released to the full QA team after this step. Once the sprint is completed, the QA team gives the demo. All interested stakeholders attend the demo and make their comments. These comments and feedback are taken in and addressed in future sprints. After the final sprint the product is ready for release.
Share by: