Software Development Philosophy
By: Kiran Biliyawala
Tags: Software Development, Sdlc

Photo by Fotis Fotopoulos on Unsplash

For mid to slightly high scaled organisations

Our development philosophy revolves around mainly two aspects:

Agility Quality

Below document is a derivative of this assumption. The document does not intent to cover all possible use-cases, and can never do so either. Please use common sense, core philosophy and take decide appropriately.

The details provided in the document below are based on my best judgement. They can changed / modified basis circumstances.

Introduction

What we strive for?

As a software engineer (I see smiles :D), I am a sucker for that utopian world; where there are no communication gaps, all requirements are known in advance, you are never disturbed when you are zoned-in for coding, your estimates are to the mark, your code is a piece of art that connoisseurs study for hours together.

But how the ground reality looks like…

Chaos of all sorts happen. No matter how tight you try to keep the leash, things go out of control. So just like change, chaos is a fact and constant. The more the number of brains involved, the bigger the chaos.

Processes do try to bring in some predictability, but then where do you draw the line. We have got to let the brain do its thing, who all agree?

This document is just an attempt to bring in the necessary stability and yet ensuring that each individual is able to bring that very unique flavour to this mix of entire development life cycle.

What is Agility?

No product is created overnight. It takes multiple cycles and frequent experiments to create a useful product.

Agility is about a team’s ability to roll out small capabilities at a fast pace, gather feedback and do course correction. This is a kind of slippery slope. At no time it should mean that we are making substandard releases in the name of agility. Remember, we are releasing code that will be run on production and impact life in the real world.

What I have observed so far to be working nicely in the real world is something like the graph shown below.

The graph represents the release of new capabilities in a product.

We usually start by getting out foot through the door. This is required to be fast in order to get some validation for the product/business idea. However, once we have a good idea, we start investing our time into more non-functional aspects of the problem; building a robust monitoring capabilities and investing in building a safety net. All this will ensure higher agility for future cycles.

What is Quality Software?

There are numerous attributes that can be encompassed to formulate a comprehensive quality definition, therefore to look what causes the lack of quality might lead to better understanding as; “The lack of the quality is the losses a product imparts to the society from the time the product is shipped”.

For continuous improvement of a product; timely, continuous evaluation and monitoring is required. These observability aspects are the core responsibilities of software quality during software development. QA also monitors and evaluates the quality of Processes, Standards and Procedure.

Besides targeting quality of product/service, some standard models also focus on quality of software development process at organisation level. And eventually, the responsibilities of QA are being increased to ship high quality product and see delighted customer. QA activities are important and it’s a back bone for an organisation. In agile development, testing is not restricted at tester level, developers are also supposed to test their programmes and fix the bug whenever they find it. Bugs are fixed at the same stage they are found and no matter who finds them and who fixes them IMO. Close customer collaboration is merged to get effective and rapid feedback of developed system before starting a new iteration, to increase product quality.

Once build is delivered to QA team for certification, QA team should start functional testing, must do the verification of all requirements. Even a small issue should not be ignored in this phase. As Continuous Integration comes into picture, a good number of unit test case coverage is already met the build criteria before build delivered to QA. Functional verification stage make sure, given requirements are present and build is ready for next stage of testing. Multiple iteration of testing for same piece of code is commonly known as Regression testing where once existing bugs are fixed, need to verify product still maintains given requirements, this will be done by continuous improvement in Automation Suite; Yes Automation is the ONLY way for fast, agile and continuous releases.

Next stage is where two or more different features talks to each and protocol is tested with real data. Behaviour of system to be verified as a functional way, stability of all components, data correctness, reliability of services/components, non-functional(majorly performance, security) testing etc. Once all planned testing is completed and reported bugs are fixed, release is ready for Sign-Off. If some known issues are present and all stakeholders are aware of those known issues, add these in release note and ship the product.

High Level Development Process

We’d have a continuous development cycles with checkpointing every week. We can choose to have a daily standup to assess everyone’s progress. In the weekly/fortnightly meeting (retrospective term in agile world) we would quickly summarise what all is achieved and plan for what is going to happen next week(Grooming/Planning). We will also go through various other issues that are hampering smooth development and create action items to be taken up in this meeting

SDLC Process