Understanding DevOps: A Beginner's Guide to Continuous Integration and Continuous Delivery (CI/CD)

 Introduction to DevOps and CI/CD

In the evolving world of software development, speed, quality, and collaboration are no longer optional— they are essential. This is where DevOps enters the picture. DevOps is a combination of "development" and "operations," designed to unify software development (Dev) and IT operations (Ops). It aims to shorten the development life cycle and deliver high-quality software continuously.

One of the core practices in DevOps is CI/CD, which stands for Continuous Integration and Continuous Delivery (or Deployment). These practices are foundational to the DevOps philosophy.

---

What is Continuous Integration (CI)?

Continuous Integration is the practice of frequently integrating code changes into a shared repository. Each integration is verified by an automated build and automated tests, allowing teams to detect problems early.

Key Benefits of CI:

• Detect bugs and integration issues early

• Maintain a constantly working build

• Encourage small, incremental updates

• Facilitate better team collaboration

Real-World Example: Imagine a team of five developers. Without CI, they might work on separate features for weeks and face serious integration issues at the end. With CI, their changes are merged daily, and any conflicts are resolved early.

---

What is Continuous Delivery (CD)?

Continuous Delivery is the next step after CI. It ensures that code changes are automatically prepared for a release to production. Although it stops short of actual deployment, it guarantees that the software is always in a deployable state.

Key Benefits of CD:

• Faster, more reliable releases

• Improved product quality

• Reduced deployment risks

• Ability to release on demand

Real-World Example: A retail company might use CD to roll out new features to their e-commerce website. If an issue is detected, they can roll back the changes quickly, minimizing customer impact.

---

Continuous Deployment vs Continuous Delivery

Although both share the same initials, there's a subtle difference:

• Continuous Delivery prepares the code for release but requires manual approval to deploy.

• Continuous Deployment goes one step further by automatically pushing every code change that passes all tests into production.

When to Use Which:

• Use Continuous Delivery when manual approval is necessary for regulatory or business reasons.

• Use Continuous Deployment when you want a fully automated pipeline for faster feedback and delivery.

---

Why CI/CD is Important in DevOps

CI/CD brings automation and monitoring into every stage of application development, from integration and testing to delivery and deployment. This reduces manual work, minimizes human errors, and provides rapid feedback.

DevOps Goals Achieved Through CI/CD:

• Automation: Less manual work and consistent environments

• Speed: Rapid iteration and shorter release cycles

• Quality: Continuous testing ensures robust code

• Collaboration: Developers and operations work as a single team

---

Key Tools in CI/CD Pipelines

There are a variety of tools available to implement CI/CD:

For Continuous Integration:

• Jenkins

• Travis CI

• CircleCI

• GitLab CI

• GitHub Actions

For Continuous Delivery/Deployment:

• Spinnaker

• AWS CodePipeline

• Azure DevOps

• Bamboo

Testing Tools:

• Selenium

• JUnit

• NUnit

• TestNG

Containerization and Orchestration:

• Docker

• Kubernetes

Example Pipeline Flow:

1. Developer pushes code to Git

2. CI server (e.g., Jenkins) triggers build and runs unit tests

3. Artifacts are generated and stored

4. CD pipeline tests the build (UI, integration tests)

5. Upon approval or success, code is deployed to staging/production

---

Who Can Use CI/CD?

CI/CD isn't limited to big tech companies. Teams of all sizes and industries can benefit.

Startups use CI/CD to move fast and iterate rapidly. Enterprises use CI/CD to maintain reliability and scale while managing hundreds of applications. Freelancers and Solo Developers can use lightweight tools like GitHub Actions to streamline their workflow.

---

Challenges in Adopting CI/CD

Despite the benefits, teams may face hurdles:

• Cultural Resistance: Some teams resist automation or process change.

• Initial Setup Time: Building a CI/CD pipeline takes planning and effort.

• Tool Complexity: Choosing and configuring the right tools can be overwhelming.

• Security Concerns: Improper setup may expose sensitive systems.

Tips to Overcome These Challenges:

• Start small and scale gradually

• Use open-source or managed tools to lower the learning curve

• Train your team and promote DevOps culture

• Implement security best practices (DevSecOps)

---

Best Practices for Implementing CI/CD

1. Use Feature Branching: Isolate work to avoid conflicts.

2. Automate Everything: From builds and tests to deployment.

3. Fail Fast: Detect errors early with automated tests.

4. Monitor and Log Everything: Use tools like ELK Stack, Prometheus, and Grafana.

5. Use Infrastructure as Code: Tools like Terraform and Ansible help replicate environments.

---

Benefits of CI/CD for Business

CI/CD is not just for developers; it brings measurable benefits to businesses:

• Faster Time-to-Market: Releases can happen weekly, daily, or even hourly.

• Higher Customer Satisfaction: Bugs are caught early, and features arrive faster.

• Cost Savings: Reduced rework and better productivity.

• Competitive Advantage: Teams can innovate quickly and adapt to market changes.

---

Further Reading and Resources

Recommended Amazon Books:

• "The Phoenix Project" by Gene Kim (Purchase the book #ad)

• "Accelerate: The Science of Lean Software and DevOps" by Nicole Forsgren (Purchase Book #ad)

• "Continuous Delivery" by Jez Humble: (Purchase Book #ad)

Helpful YouTube Videos:

DevOps CI/CD Explained in 100 Seconds

CI CD Pipeline Using Jenkins | Continuous Integration and Deployment

DevOps Tutorial for Beginners | Learn DevOps in 7 Hours - Full Course

Conclusion

CI/CD is not just a set of tools or a buzzword. It is a philosophy and set of best practices that dramatically improve the way software is built and delivered. With the right mindset, team structure, and tools, implementing CI/CD can lead to faster releases, better software, and happier users.

Whether you're new to DevOps or looking to refine your process, CI/CD is the backbone that supports rapid, high-quality software development.

The Real Advantages of DevOps: Why It Matters in Modern Software Development

 DevOps is a combination of Development and Operations, focused on unifying software development (Dev) and IT operations (Ops). Its goal is to shorten the development lifecycle and deliver high-quality software continuously.

At its core, DevOps encourages:

• Continuous Integration (CI)

• Continuous Delivery/Deployment (CD)

• Automation of testing and deployment

• Collaboration across traditionally siloed teams

• Monitoring and feedback loops

Now let’s dig into why this approach works so well.

---

Key Advantages of DevOps

1. Faster Time to Market

DevOps enables frequent and reliable software releases. With Continuous Integration and Continuous Delivery, new features and bug fixes reach end users faster. Teams can respond quickly to market demands and user feedback.

Example: An e-commerce company can roll out discounts or inventory updates almost immediately, responding to real-time market trends.

2. Improved Collaboration and Communication

DevOps breaks down silos between developers, QA teams, and IT operations. Everyone shares responsibility for software performance, security, and user satisfaction.

Example: In traditional models, developers might finish coding and hand over to QA. With DevOps, QA and Ops are part of the workflow from day one.

3. Enhanced Quality and Reliability

With automated testing and continuous monitoring, DevOps helps catch bugs early in the development process. This reduces the number of defects in production.

Example: Netflix uses DevOps tools and automated testing to ensure seamless streaming experiences worldwide.

4. Better Resource Management

By using Infrastructure as Code (IaC) and containerization, DevOps teams optimize how they manage resources. This results in more efficient deployments and lower costs.

Example: Kubernetes and Docker help scale applications only when needed, saving compute power.

5. Faster Problem Resolution

DevOps practices include real-time monitoring, logging, and alerting systems. This leads to quicker identification and resolution of issues.

Example: A financial services company uses automated alerts for any latency or failed transactions, ensuring immediate response and customer trust.

6. Increased Deployment Success Rate

Small, incremental updates reduce the risk of massive failures. With rollback options and version control, issues can be quickly addressed.

Example: Amazon deploys code every 11.6 seconds, using DevOps practices to ensure each deployment is safe.

7. Security from the Start (DevSecOps)

Security is integrated from the beginning. Automated vulnerability scans, code reviews, and compliance checks make security proactive rather than reactive.

Example: Healthcare applications embed compliance checks within the DevOps pipeline to ensure HIPAA standards are met.

8. Cultural Benefits

DevOps fosters a culture of shared responsibility, continuous learning, and process improvement. This results in more engaged, empowered, and happier teams.

Example: Teams that adopt DevOps often report higher morale and better team alignment.

---

Who Should Use DevOps?

DevOps isn’t just for tech giants. Any organization that delivers software—whether it's a banking app, an e-learning platform, or a customer portal—can benefit from DevOps. It is especially useful for:

• Agile teams

• Startups needing fast iterations

• Enterprises managing large-scale systems

• SaaS product developers

---

DevOps Disadvantages (To Be Aware Of)

While DevOps brings numerous advantages, it comes with a few challenges:

• Cultural resistance: Teams may resist change.

• Learning curve: New tools and processes take time to master.

• Tool sprawl: Too many tools can cause complexity if not managed.

• Security blind spots: Poorly implemented automation may bypass crucial security checks.

These issues are usually temporary and manageable with proper training and leadership support.

---

DevOps Tools to Know

Some popular tools used in DevOps pipelines:

• CI/CD: Jenkins, GitHub Actions, GitLab CI

• Monitoring: Prometheus, Grafana, ELK Stack

• IaC: Terraform, Ansible, AWS CloudFormation

• Containerization: Docker, Kubernetes

• Source Control: Git, Bitbucket

---

DevOps Success Stories

• Spotify: Uses DevOps to deploy code frequently while scaling services for millions of users.

• Etsy: Improved their deployment speed and quality dramatically with DevOps practices.

• NASA: Adopted DevOps to reduce build times and increase system reliability in mission-critical software.

---

Final Thoughts: Why DevOps Is Worth It

DevOps is not just a process change—it's a culture shift. Teams adopting DevOps experience faster releases, fewer bugs, higher productivity, and better alignment across departments.

In a world where speed, reliability, and user satisfaction define software success, DevOps offers a clear path forward.

---

Further Reading and References:

• DevOps on AWS

• Google Cloud DevOps Research

• DevOps Handbook by Gene Kim (Purchase on Amazon #ad)

YouTube Resources:

• DevOps In 5 Minutes | What Is DevOps?

• DevOps Tutorial For Beginners | Intellipaat

---

Need help adopting DevOps or building a DevOps team? Reach out to certified consultants, or explore free DevOps bootcamps offered by platforms like Coursera, edX, and Udemy.

DevOps is not a one-size-fits-all solution, but when applied correctly, it becomes a game-changer for software development and delivery.

What is agile modeling (AM)? An explanation. Part 2

Read the first part of this post (Agile Modeling: An explanation - Part 1)

The modeling should be carried forward in small increments. As such it is easy to find bugs if the increment fails or some fault occur. As an agile developer, it is your duty to continuously strive to improve the code. This is just another way of showing that your code works in real, and is not just mere theory. The stakeholders know what they want better than the developers. Thus, by actively participating in the development process and providing constant feedback they can help in building a better software overall.
The principle of assuming simplicity means keeping focus on the required aspects instead of drawing out a highly detailed sketch. It also means using simple notations for depicting various model components, using simple tools, taking information from a single source, rejecting temporary models and updating models only when required. Facilitation of the communication can be improved by making a public display of the models, be it on wall or website, application of standards of agile modeling, collective ownership of artifacts and modeling in a team. Gentle application of the patterns enhances the results drastically.
The formalized contract models are required when you require integrating your system with other legacy systems such as web application or database. These models lay out a contract between you and the owners of these legacy systems. The principles, values and practices of AM have been developed by many experienced developers. With AMDD or agile model driven development we do sufficient high level modeling in the initial stages of the project for making out the scope of the project. In the later stages the modeling is carried out in iterations as a part of the development plan. You might then take model storming road for compiling your code straightaway. Agile practices can be applied to most of the projects. It is not necessary that you should be working on an agile project to benefit from these practices. Also it is not necessary to put all principles, practices and values to use to harness agile advantage. Instead it is better to tailor these practices according to the specifications of your project.
Another way of harnessing agile benefits is to follow AMDD. MDD (model driven development) in its agile form is called agile model driven development. In AMDD before writing the source code we create extensive agile models. These models are strong enough for carrying forward all the development efforts. AMDD is a strategy that seeks to multiply the scale of agile modeling. The main stages in this process are:
> Envisioning: Consists of initial architecture envisioning and initial requirements envisioning. These activities are carried out during the inception period.
> Iteration modeling
> Model storming
> Reviews
> Implementation

It is during the envisioning phase that we define the project’s scope and architecture. It is done using high level requirements and architecture modeling. The purpose of this phase is explore the requirements of the systems as far as possible and built a strategy for the project. Writing detailed specifications is a great risk to take. For short term projects you may like to pare only few hours on this matter. Agile modelers are advised to spend only required time on this phase to avoid the problem of over – modeling. For exploiting the important requirements you might require a usage model. It helps you explore how the product will be used by the users. For identifying fundamental business entity types an initial domain model is used. The issues with the user interface and its usability can be explored using an initial UI model.

What is agile modeling (AM)? An explanation. Part 1

Agile modeling is one of the most trusted development methodologies when it comes to producing an effective documentation and software system. If described at a high level, it comprises of all the best practices, best principles and values required for modeling a high quality software product (this description may seem a bit hyperbolic, but it tends to be true for the most part). These practices are lightweight in implementation, with a lot of flexibility. Although, Agile Modeling is a set of principles and therefore on its own, it is of no use. It has to be mixed with other fuller technologies such as rational unified process, extreme programming, and adaptive software development, scrum and so on. This process enables us to develop software that satisfies all of our requirements. Agile modeling is governed by the following values. Some of these values are extended from extreme programming:

- Communication: All the stakeholders should maintain an effective communication between them.

- Simplicity: Developers should strive to develop the simplest solution possible meeting all the requirements.

- Humility: As a programmer, you should have a sense of humility that you may not know everything and you should allow others to add value to your ideas.

- Feedback: There should be a mechanism for obtaining feedback early in every stage of development.

- Courage: You should have courage to make decisions and stay firm.

The principles on which the Agile Modeling is based are defined by the agile manifesto. Two of these principles are to assume simplicity and embrace changes. Assuming simplicity makes it easy to design software. You are able to cut out unnecessary secondary requirements and focus on the primary needs, thereby reducing the complexity. When you embrace the fact that there will be changes in the requirements, it adds flexibility to your project. As a result, you can develop more flexible projects that can adapt to the changes in requirements, and other changes, over time. 

The software evolves in increments. You should know that it is this incremental behavior that maintains agility of the system. The requirements are ever changing and so there should be rapid feedback mechanism in place through which early feedback can be obtained. With this early feedback it becomes easy for you to ensure that your system is fulfilling all the needs. The modeling should be done with a purpose i.e., if you don’t understand the purpose of your project, its audience or its environment you should avoid working on it unless you are pretty confident. 

It is always wise to have a contingency plan. Therefore, it’s good to have multiple models on standby. There can be a situation in which your primary model might fail, the standby models will provide a back up. One thing worth noting is that agile models are not just mere documentation; they are light weight realizations of your system’s purpose. Once the purpose is fulfilled, the models are discarded. 

One belief of agile developers is that representation is less important than the content. It is the content that matters. Also there are a number of ways in which the same content can be represented. Focus should be maintained on quality work because sloppy work is not valued anywhere. Also adapting to the principles of agile modeling for meeting the environment needs is important. Modeling in an agile manner requires practice. Agile modeling can be applied through various practices. You have to pick the most appropriate one for your project. However there are few fundamental practices that are always important for success of an agile model:

> Parallel creation of several models.

> Application of the right software artifacts depending up on the situation.

> Moving forward through continuous iteration.

One word of caution though! These models are just an abstract representation of the actual systems and therefore cannot be accurate.

Test Driven Development - The Process

Continuing from the previous post on the basics of TDD (link), this post continues with the topic of Test Driven Development.

What is the process of Test Driven development?
For the test driven development to be implemented on some software artifact, its units should be kept small. By units here we mean a group or class of functions related to each other. Sometimes these units might also be referred to as the modules. These are a couple of the benefits of using small units:
> The debugging effort is reduced – Upon detection of test failures; it becomes easy to track down the faults when you have smaller units.
> Tests are often self – documenting: Readability and understandability is increased by virtue of small tests.

TDD can be converted into ATDD (acceptance test driven development) by mixing TDD with more advanced practices. The criteria that the customer specifies are converted into acceptance tests which are then used for driving the UTDD (unit TDD) process in traditional manner. With this process it is ensured that there is an automated mechanism which can be used by the customers for deciding whether their requirements have been met or not. The ATDD provides the development team with a fixed target i.e., the acceptance tests which keeps them steadily focused on the requirements of the customers. Now let us examine the TDD cycle. It's test driven development cycle consists of the following phases:

1. Adding a test: The beginning of a new feature is marked by writing a test which must fail because of being written before the implementation of the feature. If this test succeeds then either the test is defective or the feature has already been added to the software. Before writing a test, the requirements and specifications must be fully understood by the developer by means of user stories and use case stories. This step puts the focus of the developer on the requirements before he/ she begins writing the code that makes a subtle yet importance difference.
2. Running the tests and checking if they fail: This step does the step of validating the correct working of the test harness. The test itself is also tested in this process ruling out the possibility that the new test will pass always. This results in increase in confidence in software.
3. Allowing the test to pass by writing some code: the code written at this step is not perfect as proved by later tests but it is eventually improved. The code is written only to pass the test.
4. Running the tests: If all the tests pass, the programmer can be sure of the code that the requirements are being met.
5. Refactoring the code: Now the code has to be refactored as required. This also involves placing the code in its logical place and removing any redundant code. It has to be made sure that the function and variable names represent properly their current values. Any misinterpreted constructs should be clarified. After this the code should be re – run to be sure that the refactored code has not changed the other functionalities.
6. Repeat: Another test is taken to test the next functionality. The steps should be kept small. If the new code does not satisfy this test or if it fails, the changes made should be undone instead of excessive debugging. Maintaining revertible checkpoints becomes easy if continuous integration is used. If external libraries are being used, then it is necessary that the size of the increments should be as small as the library itself unless the library is not sufficient or it has bugs. Between each test run, there can be maximum 10 edits. This cycle goes on until all the functionalities have been tested.

What is Test Driven development?

The test driven development (or TDD in short) is a type of software development process that emphasizes on the use of repetitive development cycles. These development cycles are quite short when compared to the cycles followed in other development processes. Initially an automated test case i.e., an initially failing one is written by the developer defining a new function or improvement that is required. Next a code is produced (as small and as efficient as possible) for passing the test. Lastly, this code refactored so as to make it standard compliant. This technique was discovered by Kent Beck in the year of 2003. He stated that this software development technique is an inspiration for confidence and produces simple designs.
There is a similarity between extreme programming’s concepts of test – first programming and this test – driven development process. However, lately TDD has developed a general interest for its own. The concept behind the test driven development is also applied to the debugging and improvement of the legacy code that has been produced using some older methods. There are a number of aspects in which test – driven development can be used. For instance, TDD principles such as YAGNI (you aren’t gonna need it) and KISS (keep it simple stupid) are used in general context too. Since the focus is on producing only the required amount of code necessary to pass the test, the code that is developed is much clear and clean than what is developed by other methods. Another famous principle of TDD is “fake it till you make it”. For achieving some concepts including advanced design (for example, design pattern), the tests that would produce this design have to be written. The code may be simpler than the actual target code but would still pass all the tests.  At first, you might seem to disagree with it but, on the positive side it allows the developer to focus on the important things.

The first thing that should be done is to write the tests even before the functionality that has to be tested. This approach has a number of benefits:
- It helps in ensuring that the application is test ready making it easy on the developers on how to test it from outset. It eliminates the scene of worrying later.
- It makes sure that for every feature there is a test.
- This approach facilitates an early understanding of the product requirements. Thus, ensuring the test code’s effectiveness. Also the product quality can be focused up on continually.

On the other hand, the feature – first code pattern in development organizations may push the developer to the next feature which results in negligence in full testing. Also the compilation for the first test might not even take place because the classes and functions it requires might not exist then. But, even then the first tests are treated as executable specifications.
The test cases are first failed for ensuring that the test is working and is able to catch the fault or error. Once this is established, we can proceed with the implementation of the underlying functionality. This strategy is called the “test driven development mantra”. Also known as the red/green refactor where red stands for failing and green stands for passing. In TDD we repeat the process of adding the failing test cases and then passing them and again refactoring. When at each stage the programmer receives the expected results, his mental code model keeps getting stronger and reinforced. Further this boosts his productivity and instills in him a sense of self - confidence. This is the development style that TDD follows.

Lining up the support structure at the start of a cycle with firm commitments ..

During the course of a software project, you need the support of a number of people. For those who are not so well versed with the various challenges involved in project management, handling the support and resources from outside the core team are one of the biggest challenges during the early stages of the project, during the middle of the project, and during the later stages of the project; which only means that handling the various supporting teams is one of the biggest tasks during a project cycle.
So consider the starting time of a project. The features that are required for the project to succeed have been generated (including the trade off about the ones that are critical for the project vs. the ones that can be cut when there are schedule risks), and there is a need to ensure that there is a formal kick-off for the project. What do you do in a formal kick-off ? Well, one of the key items is to ensure that the team knows what the project is about, what are the key features that will be there in the project, and other such details. Typically the product manager will give a presentation to the team about the aim of the product, the market, the revenue earned by previous versions of the product and the target for the current version, and a high level description of the features that are sought to be included in the project. For many of these features, the further detail that the product manager can give is about how these features were derives, whether these be from competitor analysis or specific requests by customers, or generated based on ideas by the team.
However, as part of the initial kick-off, there are many other discussions that need to take place. For making the software development project successful, there is a lot of support that is needed from other teams. There are teams that prepare the build and the installer, there are teams that work on the documentation and help files, there are teams that deliver components that are required for specific functionality in the product, there are teams that work to translate the product in other languages. Most modern organizations have these kind of dependencies; it is no longer possible to have a situation where a single team does everything that is required for the team (for example, if you have a product that uses video formats, you would rather be using a common component that uses different video codecs to work with these formats rather than write code for working directly with these video formats (it may not even be possible to write code for all these video formats due to technical and commercial limitations)).
It is easier to ensure that you have the support of your core team and more difficult to ensure that all these supporting teams are providing the required support. For this purpose, before the kick-off, you would need to work with all these teams, providing them details about your requirements and the schedule in order to get a commitment from them (in some cases, where there is a clash due to priorities for support, you may need to escalate before you can get the desired commitment). In all cases, unless you can get the required level of support from these teams in terms of commitment, your project is already at a certain amount of risk that you will need to manage in one way or the other.

Taking care of country specific concerns (example the GB18030 standard)

In today's world, it is difficult to have software that is released in only one language. For example, you may have a great product, and are releasing it in English, and it is earning some great amounts for your organization. However, by just restricting your software to a single language, you are losing out large potential regions where you could be earning much more money for lower incremental costs. So, when you are releasing your product only in English, you are missing out on sales in France, Germany, Italy and other European countries that work primarily in languages other than English; you are missing out on sales in Japan which is a large market; you are missing out the entire Latin and South American region; and you are missing out on smaller markets that are there in East Europe and the Middle East. In addition, there are possible deals with some OEM's that would require support in multiple languages. If you want to load your software as part of the software that laptop makers distribute, many of these want a software that is available in multiple languages to ease their software packaging process.
So you decide that it will make sense for you to release your product in other languages, and start planning for the same. Now, if your application has been coded properly, then it is simple to extract the UI elements of your software and send it off for translation into different languages. It can get more complicated when you have asset elements such as graphics and others that require translation (since there may be UI elements that have English text within the graphics - in which case these graphics will need to be re-done by taking the appropriate language text for each graphic and then re-doing the graphic), or if you are using SWF  (Flash) files that need to be re-made for each language if there are language elements and the file needs to be done again for other languages.
However, all of these are process driven. There are subjective elements that need to be handled during the process, and for which the team needs to consult with experts on the processes needed for that language. For example, you may want to release the software to target the ever-growing Chinese market, and start the process of working on the translation and testing of the software in the Chinese Simplified language, and then find that when you are close to release, nobody told you of a specific testing process known as the GB18030, which is a mandate to ensure that the software is properly translated for the language. We had to submit the software to an actual testing and get the software certified that it passes GB18030. Similarly, when you look to release the software in Spain vs. Latin America, you will need to realize that there are some differences between Spanish and the language used in Latin America. The same goes for French and the language used in the French speaking parts of Canada (and in Canada, there are other mandates that you have to follow to respect the rules that software have to follow in terms of multi-language release).
There are other issues that you need to know, such as the difference between date notation (mm/dd/yyyy or dd/mm/yyyy) and the separators used in number (where the number 100000 is written as 100,000 in the US vs. 100.000 in many parts of Europe). Similarly, when you are releasing your software in Islamic countries, there may be cultural issues in term of depicting faces or the female form, and you need to ensure that all of these are already factored in.
In earlier releases of our software, in some cases, we did not know of some specific points and had to make quick changes when either the country specific person doing testing told us of the same, or we the pre-release tester who was more proficient in a certain language pointed out some things that we had missed, and all of these later changes takes more effort. Better to be as prepared as you can be right at the beginning.

Getting technical teams to talk to each other for technical discussion of features

We work in a world where a software development team cannot exist entirely on its own. It is true that the software team develops a large chunk of the features of the application, with coding and testing of most of the features of the application. However, software teams do end up using code written by other persons or teams, in the nature of components and functions written by other teams. One of the most common cases is when there are large software organizations, where there are central teams that create common components. Such components could be used for specialized purposes such as reading and writing to the disk and to optical disk drives, reading and writing varied video and imaging formats / codecs, components that are meant to create a specialized user interface, and so on. If you are working for a large organization, there is a good chance that you will be using such examples of components in your product, and also using other bits of code that is written by other people or teams.
As a consequence of this dependency on other teams, there is a need to have a regular synch-up with these teams to ensure that there is a ongoing discussion with these teams - these regular discussion could be related to the requirements, the schedule, the process of coordination, and and so on. However, some of the discussion that gets missed unless the teams have already had an agreement over the requirements and the schedule is that of the technical teams and the architecture. A lot of time there is the assumption that unless there is an agreement between the teams, there is no need for a regular technical discussion.
However, this can be a fallacy. When the discussion is between teams within an organization, there are far greater chances that there will be an eventual agreement between them. And in many other cases, this would not be the first time that the component will be integrated into the product, the discussion would be related to a newer version of the component that will be integrated into a newer version of the product. In such a case, it makes sense to have an ongoing technical discussion between the product team and the component team. It is also very likely that the technical discussion will be as important as the requirements discussion, since most of the issues in such an integration are of a technical nature. Further, having an ongoing discussion also means that then needs of your team remain high in the attention span of the product team, and that also makes it easier to get what you need from the requirements team.

New requirement after start of cycle - ensuring that there is a proper process followed ...

From the outset, let me make clear that I am not talking about a development process which is Agile or Scrum based (in the Scrum based methodology, features are taken up on the basis of a Sprint cycle, which means that features are taken up from cycle to cycle). Let us take the typical case on which a number of teams work, the Waterfall based development methodology. In this methodology, teams follow a sequential process whereby they start out with a requirements process, which is followed by a design process, which in turn is followed by a coding process mixed with a testing process. The process ensures that a phase is only started once the previous phase has been completed. So, if you consider this entire methodology, the requirements phase needs to come to an end before the design phase starts.
The direct implication of this is that once the requirements phase is completed, it is not expected that there will be a change in requirements. This is now considered to be a weakness in those situations where the requirements are in flux, but if you consider the industry where a software organization does projects for clients, the completion of the requirements phase is a critical stage. The clients typically use the entire requirements phase as a milestone which certifies that their business workflows have been captured accurately and increases the confidence level in the clients that the software mapping their business requirements will be designed accurately.
Now, look at software projects, and consider the case where after the completion of the requirements phase, there is a modification in some requirements or a new requirement that has been added. This new requirement could come in because some change in business workflows has happened, or a customer has added some new feature that is critical for success, or any other valid reason. Once such a change needs to happen, there needs to be a process to be followed to ensure that the team does not increase the level of risk beyond what has already been incurring. Typically, with a change in requirements, there is a risk of the schedule slipping, or the quality level suffering. It is better to take a hard look at the impact of such a change rather than do such a change under pressure, and then find that the software team comes under pressure later.
So what needs to be done ? Well, the group should do an impact analysis of the change before going ahead with the change. This is a process by itself that the team needs to do:
- Have a team of requirements folks to do a review of the change and estimate the change to the requirements already in place
- Work out the design changes or new design needed for this change / addition and the effort estimate
- Do the same estimation for the development or testing phase
Once you have these estimation in total, you know the approximate change to the schedule because of this change. Based on this estimation, the team needs to figure out whether there needs to be a reduction in the feature set to accommodate this change, or whether the number of resources deployed in the team need to be increased for taking this change. However, keep in mind that there will be a point in the schedule where such a change cannot be take just by increasing the number of resources; there will be an impact on the schedule.

Software development - Keeping track of stuff such as images across versions - Part 2

This is a series of posts on the handling of items other than code during the development of different versions of a software application. In the first post of this series (Keeping tack of images and other content during software development - Part 1), I took the case of the icons, images and other graphics that are used in a software product and which may be used as the same across different versions or updated when a new version of the product is used. For example, the application icon would be updated everytime a new version is released, so that it can also be differentiated from previous versions and also seek to graphically display the theme of that specific release. I will be adding more details in this post, focusing on the graphics and images.
The theme of this series is about how we do a lot of effort to ensure tracking of different versions of the code of a product (given that the code is seen as the most important valuable of the release in terms of being its Intellectual Property - and the IP of products such as Photoshop, MS Office, and others is very valued by the organizations that build these products) in a code repository, and with the use of processes such as labeling and branching, easily able to track which version of code was contained in which release.
However, my experience in multiple versions of a major software application led me to believe that this same sort of focus is not put on the non-code items that also form part of the application. I have already talked about the graphics and images that are used in an application and how my experience led to believe that organizations can very disregard the need for having a good process regarding these items. Let me continue on the same example that I was using earlier.
We had a team that would provide us the graphics and we would go through several rounds of discussions, sharing these graphics with the core team and the team that would create the installers that were an integral part of the application. However, the process was so haphazard in terms of their sending us the original set and later versions by email (as .zip attachments), and the process of reviewing them (even though we tried various options such as using Excel, Wiki, or even filing for changes as defects) did not provide a high level of confidence that the process would be error-free. And so it turned out, in the sense that invariably we would find out that some graphic was missing, and so on and so forth. Further, there was an additional element of complexity in this discussions, since the size required of the graphics was different.
The application dialogs, the installer dialogs and other such dialogs had different requirements in terms of size of such graphics, and so there was a need to ensure that we were communicating these different size requirements, and then receive the different sizes. Since they were producing such graphics in a large size, it eventually turned out better for them to send us multiple sizes of each graphic and we could pick and choose the one we liked. We did try using a more process oriented tool for this purpose, but getting a creative team to follow tight processes and the like were very problematic and caused additional stress for the program manager of the team once the process was put in place and the creative team did not follow the defined processes. As a further example, once they provided us these sizes, there was no effective place other than a folder on a server to save these, and if you needed a different size in the next version of the product, it could be real hard to work these.

More in the next version of this post (Keeping track of stuff such as graphics and others across software versions - Part 3 - TBD).

Software development - Keeping track of stuff such as images across versions - Part 1

When you are working on a software, it is not just code that you need to be worried about. A typical large software will contain a large amount of stuff besides the code that your software engineers write. When you look at the menus of the software, there might be cute icons to depict certain functions, or even if you look at the typical Undo option that sits in the Edit menu of a large number of options, there would be a button that you could hit for doing the Undo. If you look at Microsoft office recent versions, there would be a ribbon kind of menu at the top that will have a lot of options, and all of these are complemented by the visual appearance of icons. Typically, software makers try to ensure that their software has easy to remember buttons / icons that users remember and which makes the software apparently more usable by consumers.
However, for code, you would use some sort of code repository; but the same is not truly the same for non-code items such as buttons and other graphic options. Well, actually you can store such icons / visual items in the source safe but you will not be able to do operations such as comparisons between different versions of these items, and in fact, only when you actually export the history of such graphics from the source safe, will you be able to visualize what a previous version of the graphic items looks like.
One of the big challenges that software makers have when using such graphics in their application is about maintaining them. Consider the fact about the application icon (this is typically the graphic that is seen on the desktop, or in numerous other places where the name of the software is referenced). But, as you move from one version to another, you will need to have an application icon that is different from the icon used with the previous version. This helps you to mark that specific version of the software with a specific icon. So what do you do with the icon that you were using for the previous version ? You still need to save it somewhere since it was used in the previous version, and from time to time, people want to reference these icons and other imagery used within the product (once, we had a case where we were in version 7 of the product, and the management team wanted us to present the main graphics (including the application icon) that were being used in the previous 5 versions of the software; the idea was that there was a review team that was looking at a co-relation between the icon and the main focus of that previous release and whether these graphics were effective. It was hard to find the correct imagery, and the specialized team that had been preparing the graphics for us had suffered a lot of attrition over the years; they were unable to provide us the data that we needed. Finally, we had to do a lot of installation of previous versions, compare these with the versions stored in the source safe and then finally come up with the list.).
The idea of the previous story was about how it is much more difficult to maintain items that are different from code; since with code, the source safe will do a quick text comparison and make out the changes in code over a period of time. And mature large applications can have huge number of graphics embedded all over the software, and it is hard to find somebody in the team who will have the knowledge of which graphic was added at what period of time, and more important, the reason for why a specific graphic was added. And there are more complications that come into the picture. Consider that you are using a graphic in your software that was contributed by a team member and it was included in the software, and this happened over 4 years back. The graphic is still being used, and suddenly there is a legal challenge hit for the company over the rights of the graphic. At this time, you better have a good system of maintaining records to ensure that you can solve such a problem.

The next post will be a continuation of this series (Keeping track of stuff such as graphics in the software - Part 2).

How to determine the Operating System support for your product - Part 8

In this series of posts, I have been talking about the Operating System support provided in your applications. In the previous post (Operating System support for your software application - Part 7), I talked about support for 32 bit vs. 64 bit and also talked about how support provided by components can be a huge factor in the operating systems that you support. I took the example of a video application which depends on a large number of external components for codecs, encoders and decoders, for writing to DVD and Blu-Ray and for other parts of the application. If some of these components drop support for an operating system and that component is a critical part of the application, then it is time to take the decision to drop an Operating System. I know of a number of software applications that finally dropped support for Windows XP because 1) Microsoft is on its way to dropping support for Windows XP, with this support ending in 2014. 2) A number of external components dropped support for Windows XP and these were critical enough that the management team of the application finally bit the bullet and dropped support for Windows XP as well.
What happens when you cannot afford to drop support for an application such as where components have dropped support, but the customer profile is such that there is still revenue to be had from customers on this operating system ? Well, that is not a very nice place to be, but you still need to take a stand. If the revenue is important, then you will need to support that specific operating system. So what do you do ? There are a number of steps that you can take to ensure that your product remains on that operating system.
1. Well, you will need to make another effort to ensure that the external component retains support for that specific operating system. If the company or group providing the external component is not willing to provide full support, ask whether they are willing to maintain it to the level that was previously supported. If this is another group in the company, then the revenue potential provides some leverage to ensure that escalation can happen and support is maintained, even if it is at a lower level (only critical bug fixes are provided rather than all bug fixes).
2. The most risky approach. You take a chance and go with a component that is not supported by the provider on that specific operating system. The problem in this case would be that if there is some critical problem that has emerged, things can go out of control very easily, and lead to a situation where there are no good options.
3. Look for alternatives. There are very few functionality items that would not have multiple providers, even if the alternative is a less than perfect functionality. If using another component provides a solution, then you should evaluate the other component and use it if it meets your purpose (even if less than perfect).
4. Prepare for a reduced functionality. I have seen many products using such an approach. When there are no alternatives, and it is decided that support for the specific operating system needs to be continued, then it may be something as easy as dropping the component which has dropped support for the operating system, and having the product without the functionality provided by that component. This needs to communicated to customers as well so that they know that there will be reduced functionality on that specific operating system.

How to determine the Operating System support for your product - Part 7

In the previous post in this series (Operating System support for your software application - Part 6), I focused on the different roles and responsibility of stakeholders in the team, primarily the Product Management, the QE, and the developers. The Product Manager has to take the decision taking into account the various pros and cons of such a move, and also while evaluating revenue impact; the QE and development team would do their contribution to this discussion keeping in mind the impact on their effort, and any technical factors that could also influence the decision. In this post, I will talk more about the dependency and also briefly touch on the 32 bit or 64 bit discussion.
For some years now, there has been an ongoing discussion about the need to move applications onto a 64 bit architecture and stop support for 64 bit architecture. Most people will not understand this discussion, and the reason why it is a top item of discussion for many teams. In near layman's terms, when you state that your application is now 64 bit, it would mean that it can take inherent advantage of the benefits posed by the new wave of 64 bit operating systems, being able to allocate more memory, and numerous other technical advantages. Also, most Operating Systems that are now available are 64 bit. So why not go ahead and convert your application to 64 bit ? Well, converting your codebase to offer native 64 bit support is a project by itself, requiring a large amount of development and testing time. For teams that have limited resources, making such choices is not easy (and most teams cannot claim to have unlimited resources). In addition, you also need to realize that you would no longer be properly supporting consumers who still have 32 bit operating systems (and where the hardware has been supporting 64 bit for a long time now), so this is a decision that needs to be taken.
The other aspect of this post is in terms of the various components that your application would use. In today's world of software development, it is hard to think of a large software that the development team has totally written. Consider that your product is a large video manipulation application. Even though a lot of the workflows will be written by your team, the functionality of a number of sub-areas are better handled by using external components (which could be built by other teams within the company, or by other companies which specialize in such areas). For example, if you are looking at an application that allows users to organize, edit and manipulate videos, you would need support for the different video formats, you would need access to different encoders and decoders, you would need components for creating DVD's or Blue Ray discs as part of the end process. In all such cases, it is far more efficient and effective to use specialized software rather than trying to replicate all of them.
And this is where you dependency starts to dictate matters for you in terms of the operating system support. The external components that you use are created by companies that in turn have to take the same decision for operating system support as you do, and they would also have a large number of customers, based on whom they need to take decisions. It is entirely possible that you would end up in a scenario where some key component that you are using is dropping support for an operating system, and given its criticality in your own application, you are forced to also stop support for the same operating system.

How to determine the Operating System support for your product - Part 6

This blog has seen a series of posts on deciding the Operating System supported by your application. The previous post (Operating Systems supported by your application - Part 5) talked about the kind of constrains that there are for an operating system that is not supported - whether these prevent the user from installing the application on that operating system, or just give a warning and let the user install on the specific operating system. This post will talk in more detail about the process for the various stakeholders in the team that come to a decision about the operating systems to support.
The most important stakeholder is the Product Manager. It is the product manager who is responsible for the final state of the product, the system requirements for the product (which includes the operating systems to be supported in the application). The Product Manager is also the one who is responsible for the revenue requirements for the product, and supporting or dropping an operating system can make a difference to the revenue generated by a product by a few percentage (and these few percentage can make a huge difference in terms of whether targets are met or missed). Hence, it is for the Product Manager to take a final call on whether the product should drop a specific Operating System or not. However, it is perfectly fine for team members to be able to provide a lot of updates and constraints to the product manager.
Another important stakeholder is the QE team (the testers). During the testing phase, the team needs to draw up a plan of which are all the operating systems that need to be supported, need to decide the amount of effort to be spent in each operating system, and then actually put in the effort. Suppose a team supports Windows XP, Windows Vista, Windows 7 and Windows 8. In such a case, the team would use data about the approximate number of users on each operating system in order to prioritize the testing effort on each operating system (no testing team has enough resourcing to do all the tests and spend the effort that they would like to do). But you would still expect that if there are 4 operating systems, then the team would spend around atleast 15% on each operating system testing. In some cases, the testing for an operating system might take more time because there are more defects to be found on such an operating system (for example, we found a lot more problems on Vista, many of them related to the security issues because of the user security accesses control introduced in Vista).
So, the testing team would want that if there is a possibility of reducing an operating system because of a lesser number of users on such a system, then they would hold a number of discussions with the Product Manager on this topic, to ensure that their voice is heard and if they have any data, that is also passed onto the Product Manager (such data could be the increasing number of bugs that they are finding on older operating systems).
The development team are also important stakeholders. They are responsible for ensuring that the code is there for functionality to work the same on all the supported operating systems, something that can be problematic sometimes because the operating systems behave differently. In addition, there may be components in use that are not supported as well on older operating systems.
All these are stakeholders and opinions that need to be factored in before taking a decision on whether to drop a specific operating system. The decision needs to be taken after factoring in a lot of points.

In the next post, I will add more points on this particular topic (Operating Systems support for your application - Part 7)

How to determine the Operating System support for your product - Part 5

This particular series of posts talks about how to determine the support for previous Operating Systems provided in your application (Operating System Support in your application - Part 4). In the previous post, I talked about one major factor - when the maker of the Operating System (whether that be Microsoft or Apple) decides to drop support for the Operating System and will not provide any more bug fixes or other support. This gives a problem where even if you decide to support such an application, you will not get any bug fixes from the makers of the Operating System, which can be a huge potential problem given the interactions of the application with the Operating System.

In this post, I will talk about the process of cutting off support for an Operating System. There are 2 different methods which I have seen about how to cut off support for an Operating System. One of the ways is to provide a hard constraint, which means that the user will not be able to install on that specific Operating System, and the other is a soft constraint which means that the user is given a warning when trying to install on that version of the Operating System.

Consider the variation about using a hard constraint that prevents the user from installing on such an Operating System. What this means is that when the user tries to load the application on that specific version of the Operating System, the application determines the specific Operating System loaded on the computer, and then checks with the supported list of Operating Systems. If the Operating System is not to be supported, then the application installer will give an error to the user and prevent any installation on the user machine. 

Putting a hard constraint is needed when the makers of the software have made a determination that the user should be prevented on that Operating System. This can be when there is a high deal of uncertainty about whether the application will work well on that Operating System without any defects, or when the makers have decided that the version of the Operating System is not in wide user anymore. The hard constraints are also used when the Operating System installed on the user machines is controlled, such as in the case of higher end or specialized software.

The soft constraint means that the user will get a message during the installation process about the version of the Operating System not being supported, and will get an option about whether to proceed or not. If the user decides to go ahead, then the application will get installed. This is normally done when there is an expectation of very few problems on that specific Operating System, and the company does not really want to force the users of that specific Operating System to try alternative solutions. There will be need to be some testing of that specific Operating System, but not at the same level as that of the supported Operating Systems.

Read more in the next post (Determine Operating System support for your application - Part 6)

How to determine the Operating System support for your product - Part 4

In the previous post of this series (Determining Operating System Support for your application - Part 3), I wrote about the process of determining the number of people in your customer base who are using the Operating System in question. There are ways to do surveys and look at industry data, but there is some amount of variability involved even when analysing the data and some amount of assumptions need to be made. Of course, trying to make such decisions without trying your best case on how to get the data required for such analysis is something that organizations should avoid at all costs. Such decisions could cost money that the organization could ill afford, and hence such decision making should be done with a lot of deliberation.
In this post, let us consider another factor that is of great importance in deciding when to drop support for an Operating System from your application. This is related to the drop in support for a particular Operating System by the makers of the operating system. So, if you could consider the case of an operating system such as Windows NT or Win 2000, the support for all of these have been dropped by Microsoft, and if you were to try to get resolution for a problem on these operating systems with Microsoft, they would decline to provide you any support and ask you to upgrade to the newest operating system.
Now you are developing an application that will run on the operating system. Any application, especially those that accesses files on the local machines or that accesses devices on the local machines such as printers (and most applications give a print interface) have a dependency on the files of the Operating System. From time to time, there are problems that crop up where you need to work with the makers of the Operating System (typically Microsoft or Apple) and even expect them to make some fixes for you. When the makers of the Operating System withdraw support, they stop supporting such problems and no longer want to provide fixes for such problems.
So what do you do ? You could still provide support for the Operating System even when the maker of the Operating System is no longer providing any support, but there is an inherent risk in this decision. During the development process, you could run into a problem that could cripple your system and yet you don't have a solution, or a solution on your end is expensive and time consuming  In such cases, it will cause you significant problems; on the other hand, small problems that really are not problems could be all that are caused. And you have to consider that the maker of the operating system would also have thought a lot about dropping support, and there would have been some factors that went into such a decision.
Apple makes it even easier. As and when Apple releases new operating systems, new machines that are released are packaged with these new systems, and they even stop supporting older operating systems on these machines. Deciding on dropping older versions of the Mac is easier than that of Windows, also because the customer base using the Mac Operating System would be less than that of Windows.

Read the next post in this series (Operating System support for your application - Part 5)

How to determine the Operating System support for your product - Part 3

In the past post in this series related to how to determine the Operating Systems support for your application (Operating System Support - Part 2), I talked about trying to determine what your current users support. If your current users are using an Operating System in fairly significant numbers, then it would be hard for you to drop support for such an Operating System; you would risk turning off these users, preventing them from buying the newer version of your software, and drop a significant potential customer base. But, this decision remains a complicated one.
In the previous post, I talked about getting this data from current users. But it is not only current users from whom data needs to be taken. To ensure that you are not dropping potential users from your customer base, you need to do surveys to determine whether your potential users are having an Operating System that you are planning to drop. Consider the case of Windows XP at this point of time. It is an old Operating System and you would might think that most users have moved on from Windows XP. But suppose you decided to drop support of this Operating System from your newer version and then suddenly see a drop in sales, it would seem obvious that you did not do the required survey of your potential users before making such a significant decision.
So what needs to be done ? Well, this is a survey of your potential customers, and is not as easy as just getting data from existing users. However, at the same time, there are many ways to get data related to Operating System usage. At any time, if you just do a search for Operating System usage, you will find that there are a number of articles where surveys have been done to determine the prevalence of Operating Systems among people worldwide, in specific age groups, across geographies and so on. So, if you have a product whose potential customer base is primarily among people above the age of 40 in the United States, there will be some industry data related to such a customer base. Of course, the data will not be exactly in the way that you need, so you need to account for the assumptions, look at the variables and then do an analysis to determine the data appropriate for you and use that as an input for your decision making.
However, it is not just looking at industry data. Another input for decision making is to call for a survey that looks at a sample of your user base and then provides that data to you along with a factor that determines the error assumptions in the survey. The advantage of this method is that you can determine the exact assumptions to be made in the survey, the queries to ask, and then get the results. However, to get accurate results and to ensure that you are not making inaccuracies, the survey needs to be thought through properly, and this can be expensive. But the science of surveys is pretty much standard, and you can be fairly confident about the results.
Now you have got the data required for your decision making, and you need to add variables regarding whether people who have older operating systems will actually buy your software, since people who are comfortable with their current software and operating systems are likely to have a lower percentage chance of buying newer software, even if it is very useful.

More information in the next post in this series (Deciding Operating System Support for your software - Part 4)

How to determine the Operating System support for your product - Part 2

In the part 1 of their series (Determine the Operating System Support for an application - Part 1), I started with the discussion about the various Operating Systems that product teams could support, and some of the complications that come about in the decision making for deciding the Operating System support. In this post, I will talk about some of the other issues that help decide what the operating system support should be.
One simple factor that determines what older versions of Operating Systems you should support include determining the customer impact if you drop a version. In today's day and age, you would be hard-pressed to find a user who has Windows 95 or Windows NT on their machines or an equivalent older version of the Mac OS. Even if you did find somebody like that, the number of people who are actually on such Operating Systems would be very small, and you should be able to afford such users. The tricky park comes with Operating Systems that are closer to the current version, such as Windows XP. Now Windows XP has had 3 newer versions of the Windows Operating Systems that have been available after that, namely Windows Vista, Windows 7, and Windows 8. But, a number of people (especially older people) do not make their software upgrade decisions based on whether a newer version is available. If a newer version is available, and if their existing version provides the functionality that they are comfortable with, you will find a significant % of people will not upgrade their Operating Systems or their machines. I personally know numerous people who heard bad stuff about Windows Vista, decided that their Windows XP installation was fine, and refused to upgrade. If your expected customer base has people who are like this, then it would be foolhardy to do an upgrade unless you are sure about your figures. And this is where things get tricky. You have to do data reporting and data analysis to get enough information to take a decision.
Now even inferring from the data analysis may not be fairly straight-forward. How do you decide the data collection technique ? You would want to know from 2 sources - one would be the current users of the application, and the other would be potential users. None of these are easy methods.
Suppose you want to get this data from current users ? The ideal way would have been to have a mechanism within the application that connects on a regular basis to your computers and provides some information about the computer of the user, including the Operating System and Service Pack version of the software application. If you were getting this information from all your users, then it is very easy to consolidate this information and quickly determine how many of your users are on the Operating System on which there is a query about whether you should continue to support it. Suppose you have set a benchmark of 10% being the limit above which you will continue to support an Operating System, then this data will easily help you make a decision. At the same time, keep in mind that building such a system in the application is not easy. In this day and age of security and privacy considerations, you would need to ensure that such a mechanism passes legal and privacy guidelines. Further, keep in mind that some of your users may not be connected to the internet on a regular basis and hence the data you get is only from those people who are connected to the internet. As always, when you get data, you need to make sure that this data is an accurate as you can verify. The method used for data collection, the logic used for the data interpretation both need to be accurate and verified, else you will commit the grave mistake of taking a decision based on either wrong data or wrong analysis of data, both of which can cause grave problems.

This is it for this post, will continue in this series in the next (Determine Operating System Support - Part 3).

How to determine the Operating System support for your product - Part 1

You are working on your product, and one of the big factors determining the amount of effort needed for testing, and to some extent development, is the platform support that you offer. For both Windows and Mac, there are a large number of Operating Systems that have been released over the years, and if your product has been getting released into the market over a number of years, you would have had to support many of these Operating Systems. Consider the case of Microsoft Windows; it has had a number of operating systems released as time went by - Win 3.1, Win95, Win98, Win NT, Win 2000, Win XP, Vista, Windows 7 and now Windows 8 (I have been working on products that have been in the market supporting Operating Systems from Win 3.1). A number of people would ask as to what is the problem in supporting previous versions of Operating Systems. If you consider a software that is also released on the Mac, there are also different version of Mac OS that have been released over the years.
Now, there is a huge cost of maintaining software on these multiple Operating Systems (and when I say maintaining, I actually mean supporting these OS's on newer versions of the software). When you say that you are supporting an Operating System, this is not possible unless you have done a round of testing on that particular Operating System. So, the more Operating Systems that you have to support, the additional amount of testing that you have to do. Also consider that every Operating System would have had patches that need to be supported. So Windows XP is actually Windows XP, Windows XP Service Pack 2, Windows XP Service Pack 3. And we have seen many cases that the test results could be different because of the difference in the version number of common DLL's such as the Windows Runtime DLL's that are present in these Service Packs.
Many of these Operating Systems are very old, and not supported by Microsoft (or in the case of the Mac, not supported by Apple) anymore. In fact, Microsoft has already removed OS's earlier than Windows XP from their list of supported Operating Systems, and XP is also quickly on the way out. However, depending on your customer profile, decisions such as dropping support of various Operating Systems are not so easy. For products that are meant for layman consumers, not those who upgrade their machines periodically, you would find that a number of people are fine with using Windows XP and see no reason to upgrade to a newer Operating System. So, if your user base is comprised of such types of users, then dropping support for XP would mean that you no longer want business from such users. Further for people who on XP and have a previous version of your software, it means that you are no longer offering a path to buy a newer version, and they may end up using a software that is from a rival and you would have lost a customer.
So what are some of the other variables involved in decision making and how do you finally make a decision ?

Read the next post in this series (Selecting the supported Operating Systems - Part 2).