Bring the power of generative AI to engineering teams with GitHub Copilot. Learn how you can maximize developer velocity and innovation.


Copilot card

Stay one step ahead by shipping your software securely within GitHub: Identify and fix security issues directly in the developer flow.

Security Card

Learn why more than 90% of the Fortune 100 use GitHub—the leading developer platform compared to alternative solutions.

Why GitHub? Card

Form_Ungated_Contact

Become a GitHub expert in CI/CD, application security, governance, and AI-developer tools through expert-guided learning pathways with tips and insights from leading enterprise organizations.

Resource Page for /learn/build-like-the-leading-tech-innovators

CO-GHG-CONTACT-FY23-10Oct-01-WW-Resources-Contact-Request

GitHub Learning Pathways

aicha-bah-gersing.png

Aicha Bah Gersing

Senior Director, Premium Support

Home Page 2022-04-01

If you've ever incurred financial debt, you likely did it to get something sooner than you would have if you'd waited until you could pay in full, even though it cost you more in the long term. Technical debt (also called "tech debt") works in a similar way. In [software development](https://resources.github.com/software-development/what-is-software-development/), technical debt refers to future consequences that result from prioritizing speed of delivery over achieving an optimal solution. Choices made to achieve a short-term goal accrue a "debt" that will need to be repaid later in the form of additional work and long-term costs associated with maintaining and evolving the software.

If technical debt isn't addressed, it can accumulate over time and hinder a team's ability to deliver new features, fix bugs, and respond to changing requirements efficiently. And like financial debt, technical debt comes with interest—the longer it persists, the more costly it becomes.

## **Defining technical debt: intentional vs. accidental**

One important aspect of understanding technical debt is recognizing that it can be intentional, accidental, or both. When it's intentional, development teams take on technical debt as a strategic choice to meet tight deadlines or deliver a product more quickly to gain a competitive advantage. The expectation is that the debt will be addressed and repaid.

With accidental technical debt, unforeseen challenges or lack of knowledge may be responsible. For example, developers can inadvertently introduce technical debt while trying to quickly navigate changing requirements or unexpected technical constraints, or because they don't understand the full scope of the problem they're trying to address.

In practice, software projects often incur a combination of intentional and accidental technical debt. It's important for development teams and stakeholders to be aware of the trade-offs involved in accumulating technical debt and to have a plan for managing and repaying it over time. Proactive management of technical debt is crucial to maintaining the long-term health and sustainability of a software system.

## **Importance of technical debt in software development**

Stakeholders and development teams may decide to intentionally take on technical debt for strategic reasons, including:

- **Rapid delivery and time to market**: Intentionally taking on technical debt may be a strategic decision to meet deadlines and gain a competitive advantage by getting a product to market quickly.
- **Flexibility and adaptability**: By making pragmatic decisions and accepting some level of debt, teams can quickly iterate on features and respond to user feedback, adapting to evolving requirements and market demands.
- **Learning and prototyping**: In the early stages of a project, when requirements are still evolving and there's a need for experimentation, technical debt may be incurred as a byproduct of learning and prototyping. Once the requirements are better understood, the debt can be repaid through refactoring and optimization.
- **Risk management**: Technical debt can be a way of managing risks associated with uncertainties in project requirements. By deferring certain decisions or taking shortcuts initially, teams can gather more information and make better-informed decisions later, reducing the risk of investing heavily in the wrong direction.
- **Team dynamics and** [**collaborative software development**](https://resources.github.com/innersource/best-practices-collaborative-software-dev/): Acknowledging and managing technical debt encourages open communication within development teams and between developers and stakeholders. It fosters a culture of transparency about the trade-offs made during the development process and helps in making informed decisions collectively.

## **Types of technical debt**

Technical debt has been characterized in multiple ways over time. Some approaches focus on the intent and consequences, while others address the specific nature of the debt. One useful way to categorize the different types of technical debt is based on how they fit into the [software development lifecycle (SDLC)](https://resources.github.com/software-development/what-is-sdlc/). These types include:

- Architecture debt
- Build debt
- Code debt
- Defect debt
- Design debt
- Documentation debt
- Infrastructure debt
- People debt
- Process debt
- Requirement debt
- Service debt
- Test automation debt
- Test debt

For each type, compromises or shortcuts made in that aspect of the SDLC result in issues that may impact the long-term maintainability, scalability, and reliability of the software if the debt is not repaid.

## **Causes of technical debt**

A wide range of factors and circumstances can result in technical debt throughout the software development process. Some common examples of these issues include:

- **Time and resource constraints**: Development teams facing pressure to deliver a product or fix a bug quickly may take shortcuts to meet tight deadlines or market demands.
- **Incomplete requirements**: When the full scope of a project is not well-defined or changes frequently, developers may make decisions that need to be revisited and refined as the requirements become clearer.
- **Lack of experience or knowledge**: Developers may inadvertently introduce technical debt due to a lack of understanding of best practices, design patterns, or the long-term consequences of certain decisions.
- **Legacy code and systems**: Integrating new features or making changes in a legacy environment with outdated technologies and architectures may result in shortcuts or compromises.
- **Insufficient testing**: Inadequate testing practices, such as the lack of automated tests or insufficient test coverage, can make it difficult to identify and address issues early in the development process.
- **Lack of documentation**: Poor documentation can make it difficult for developers to understand and maintain or update the code.

## **Examples of technical debt impact on development projects**

In the short term, technical debt can provide a boost in speed and flexibility that helps an organization achieve its goals. However, technical debt that is not addressed proactively can have severe consequences for the long-term success of the project. Some of these consequences include:

- **Decreased code quality**:  Code with design flaws, inadequate testing, or insufficient documentation is more prone to errors and may not meet the desired standards for reliability, performance, and security. Poorly designed or hastily implemented code may lead to a higher incidence of bugs and defects.

- **Increased maintenance costs**:  Over time, the codebase becomes more difficult and expensive to maintain. Developers need to allocate more time and effort to address issues, refactor code, and implement changes.

- **Compromised security**:  Outdated dependencies, insufficient testing, and poorly designed security features can create vulnerabilities, exposing the system to potential security breaches.

- **Difficulty in attracting and retaining talent**:  The perception of a challenging and error-prone codebase may deter potential hires. For existing team members, working with challenging code may lead to frustration, burnout, and higher turnover.

- **Longer time to market**:  Code that is more difficult to understand, modify, and extend takes more time to navigate. Developers spend more time on refactoring instead of focusing on innovation, extending the time to market for new features and releases.

## **Identifying and measuring technical debt**

Taking steps to proactively identify and measure technical debt is essential to understanding its potential impact on the project and the organization. Some key indicators of technical debt include:

- [**Code reviews**](https://github.com/features/code-review): Perform regular code reviews to identify code smells, duplication, and other signs of poor code quality.
- [**Static code analysis**](https://github.blog/2023-03-31-codeql-zero-to-hero-part-1-the-fundamentals-of-static-analysis-for-vulnerability-research/): Use automated tools to analyze code statically to identify potential errors and vulnerabilities.
- **Testing metrics**: Analyze testing metrics for indicators of incomplete or inadequate testing, such as low code coverage or a high number of defects.
- **Documentation assessment**: Evaluate the completeness and accuracy of documentation to identify deficiencies.
- **Deployment and infrastructure audits**: Review deployment processes and infrastructure components for inefficiencies or outdated elements.
- **Dependency analysis**: Check for outdated third-party libraries or frameworks.
- **Team feedback**: Solicit feedback from development teams regarding challenges, frustrations, and perceived technical debt.

## **10 best practices to mitigate technical debt**

Effectively mitigating technical debt involves a combination of proactive strategies and ongoing efforts. Here are 10 best practices you can implement to manage and reduce technical debt:

1. **Prioritizing refactoring**:  Regularly allocate time for refactoring to improve code quality and address design debt.
2. **Automated testing**: Implement robust automated testing practices to ensure comprehensive test coverage and identify defects early.
3. **Continuous integration and deployment (CI/CD)**: Adopt CI/CD practices to streamline development and deployment processes.
4. **Documentation updates**: Maintain up-to-date and comprehensive documentation to facilitate knowledge transfer and reduce documentation debt.
5. **Training and skill development**: Invest in the training and skill development of team members to address people and knowledge debt.
6. **Agile and iterative development**: Embrace [agile methodologies](https://resources.github.com/devops/what-is-agile-methodology/) to adapt to changing requirements and reduce the risk of accumulating technical debt. Using more rigid approaches like waterfall development increases the likelihood of incurring technical debt.
7. **Technical debt backlog**:  Maintain a technical debt backlog to track and prioritize debt mitigation tasks.
8. **Collaborative decision-making**: Foster collaboration and open communication within the development team and between developers and stakeholders to make informed decisions collectively.
9. **Security audits**: Conduct regular security audits to identify and address potential vulnerabilities, reducing security-related technical debt.
10. **Regular reflection and retrospectives**: Periodically reflect on development practices and project outcomes through retrospectives, identifying areas for improvement and debt reduction.

## **Conclusion**

Technical debt is an inevitable aspect of software development, presenting both opportunities and challenges. While intentional technical debt can be a useful tool to achieve short-term gains, unmanaged and excessive technical debt can lead to damaging long-term consequences. It's important for development teams and organizations to strike a balance between rapid innovation and maintaining a sustainable, adaptable, and high-quality codebase. By understanding the types, causes, and impacts of technical debt, and by adopting best practices for mitigation, you can navigate the complex landscape of software development more effectively, ensuring the success and longevity of your projects.

## **Frequently asked questions**

### **What is meant by tech debt?**

Tech debt, or technical debt, is a concept in software development that refers to the consequences of prioritizing speed of delivery over achieving optimal coding solutions. Like financial debt, tech debt incurs a cost, such as increased complexity and reduced software quality, that must repaid to avoid long-term negative outcomes. Tech debt can be used intentionally as a strategic tool to achieve short-term goals, or it can be introduced accidentally.

### **What's technical debt in scrum?**

Technical debt in scrum refers to compromises made during development to meet sprint goals, sacrificing long-term code quality. It includes shortcuts, deferred refactoring, and incomplete testing that can impede team productivity and increase the risk of defects. Addressing technical debt is essential to maintaining a sustainable pace of development and fostering a codebase that is resilient, easily maintainable, and adaptable to evolving project needs within the scrum framework.

### **Why is technical debt bad?**

Technical debt reduces code quality, slows development, and increases the risk of errors. It impedes adaptability and requires additional effort to rectify, hindering long-term project success. However, technical debt can be beneficial when used strategically to achieve short-term goals. The key to mitigating the impact of technical debt is to address it proactively.

### **Who pays for technical debt?**

The development team and the organization pay the cost of technical debt in the form of increased maintenance efforts, longer development cycles, and a higher likelihood of defects. It can reduce the team's productivity and lead to increased expenses in addressing issues that arise due to compromised code quality.

### **What are the different types of tech debt?**

There are multiple ways to characterize tech debt. One way is to categorize the different types by how they affect different aspects of the software development process, including: architecture debt, build debt, code debt, defect debt, design debt, documentation debt, infrastructure debt, people debt, process debt, requirement debt, service debt, test automation debt, and test debt.

Understand the impact of technical debt on software development. Learn how to manage and mitigate technical debt for long-term code quality and maintainability.

Resource Page for /software-development/what-is-technical-debt

What is technical debt?

Software testing is the process of verifying that an application works as intended and is free of bugs and defects. Software testing also helps determine if the application addresses all of its requirements. It is an essential part of software development because it helps reduce development costs, improve application performance, and create a better user experience.

To perform software testing, testers interact with the software manually, execute test scripts, or use automated testing tools.

## **Understanding software testing**

Software testing involves running the application under controlled conditions to detect errors and verify that it behaves as expected. Testing is not necessarily a separate phase in software development, but rather something that can—and should—be performed throughout the [software development lifecycle (SDLC)](https://resources.github.com/software-development/what-is-sdlc/).

Software testing is separate from software development. The primary goal of software development is to design, code, and create a software product that meets the specified requirements and solves a particular problem. The primary objective of software testing is to ensure the quality, reliability, and functionality of the software.

## **Importance of software testing**

During [software development](https://resources.github.com/software-development/what-is-software-development/), it can be difficult to identify bugs or determine how the numerous components of an application will work together when it is deployed. Software testing can verify that all components work seamlessly together.

Some of the benefits of software testing include:

- **Bug detection and prevention.** The sooner bugs are identified and remediated in the [software engineering](https://resources.github.com/software-engineering/what-is-software-engineering/) process, the better.
- **Enhanced software quality.** Comprehensive software testing produces a higher quality software product with fewer issues for users.
- **Improved user satisfaction.** Organizations that deliver a product that is reliable and that meets the customers' needs will achieve higher user satisfaction.
- **Cost savings.** Identifying and fixing defects during the testing phase is generally less expensive than addressing them later in the development process or after the software has been released. Early detection helps prevent issues from escalating into more complex and costly problems.
- **Reduced software maintenance costs.** Thorough testing helps ensure that software is robust and less prone to bugs and errors. This, in turn, reduces the need for ongoing maintenance and support, saving costs associated with addressing post-release issues.
- **Compliance with standards.** For industries where regulatory compliance is crucial (such as healthcare, finance, or aviation), meeting regulatory regulations and standards is crucial. Testing aids in ensuring that the software complies with industry regulations.

## **Types of software testing**

There are many different types of software testing, each with different objectives, strategies, and outputs.

These types include:

- **Manual testing.** Testers interact with the application manually, without scripts or tools.

- **Automated testing.** Testers use scripts or tools, such as [GitHub Actions](https://github.com/features/actions), to automate parts of the testing process.
- **Unit testing.** The term "unit" refers to the smallest testable part of an application, typically a function, method, or procedure. Unit testing therefore involves testing the individual components or units of an application in isolation to ensure they function as intended.
- **Integration testing.** In a typical software development lifecycle, developers develop and test individual modules or components. An [enterprise application](https://resources.github.com/enterprise/what-is-an-enterprise-application/) might be composed of hundreds of such modules. Integration testing focuses on verifying that these different components work well together. During this phase, testers examine whether the interfaces and interactions between components behave as expected. Integration testing aims to validate that the combination of integrated components functions correctly as a whole.
- **Functional testing.** This type of testing verifies whether the application functions as intended and delivers the expected output.
- **Non-functional testing.** During non-functional testing, users evaluate whether the product not only meets functional requirements, but also performs well, is secure, and provides a positive user experience. These tests help identify potential issues related to performance, usability, [application security](https://resources.github.com/security/what-is-application-security/), and other critical aspects, allowing teams to address them before the software is released.
- **Regression testing.** Regression testing focuses on ensuring that updates to a codebase, such as bug fixes, enhancements, or new features, do not adversely affect the existing functionality of the software. Version control systems aid in tracing which changes introduced a bug. The goal of regression testing is to detect and prevent the introduction of new defects or unintended side effects in the software as it is updated.
- **User acceptance testing (UAT).** This is often the final phase of the software testing process and the goal is to determine if the application meets user requirements. UAT also assesses whether the application satisfies business needs and is ready for deployment to a wider audience or production environment.
- **Usability testing.** This type of testing validates how well a customer can use an application to complete a task.
- **Stress testing.** In stress testing, applications are subjected to extreme conditions to identify the system's breaking points, measure its response to extreme loads, and understand its behavior under stress.
- **Security testing.** Security testing involves evaluating a software system's ability to protect data, maintain functionality, and prevent unauthorized access. There are different types of security testing, including [dynamic application security testing (DAST)](https://resources.github.com/security/what-is-dast/) and [application security testing (AST)](https://resources.github.com/security/application-security-testing/).

The software testing types each organization chooses will depend on their ultimate goals and objectives.

## **Steps in the software testing life cycle**

The software testing life cycle is a systematic process to verify and validate that a software application or system meets specified requirements and functions correctly. The steps can vary depending on the specific testing approach or methodology being used. Here are some common steps that may be followed in the software testing process:

1. **Requirements analysis.** To effectively test software, it's important to analyze and understand the software requirements. Review code documentation, user stories, and other specifications to gain this understanding and determine what needs to be tested.
2. **Test planning.** Develop a test plan that outlines the testing strategy, scope, objectives, resources, schedule, and deliverables. This test plan serves as a guide for the testing process.
3. **Test design.** Design test cases based on the requirements. Test cases describe the specific conditions, inputs, and expected outcomes for testing different aspects of the software.
4. **Test environment setup.** Set up the testing environment, which includes configuring hardware, software, networks, and any other components necessary for testing. Ensure that the environment mirrors the production environment as closely as possible.
5. **Test data preparation.** Prepare test data that is relevant to the test cases. This may involve creating datasets, databases, or scenarios to simulate real-world conditions.
6. **Test execution.** Execute the test cases in the test environment. This involves running the software with predefined inputs and comparing the actual results with expected results.
7. **Defect reporting.** If bugs or defects are identified during test execution, document them in a defect tracking system. Defect reports typically include information about the defect, steps to reproduce it, and its severity.
8. **Regression testing.** Perform regression testing to ensure that new changes or fixes do not introduce new defects or negatively impact existing functionality. This is crucial to maintain software stability as the codebase evolves.
9. **Test reporting.** Generate test reports that provide an overview of the software testing process, results, and any issues encountered. Distribute the test to relevant stakeholders.
10. **Test closure.** Complete the testing process and formally close the testing phase. Closure includes reviewing the test objectives, evaluating the test coverage, and ensuring that all test deliverables are in order.
11. **Retesting.** After defect fixes are implemented, retest the application to verify that the reported issues have been successfully addressed. This ensures that the fixes do not introduce new problems.
12. **Deployment and monitoring.** Deploy the software to the production environment and monitor its performance. When issues arise, repeat the testing steps as needed.

## **Best practices in software testing**

By following best practices, organizations can build a robust testing process that contributes to the delivery of high-quality software that meets business requirements and user expectations. Here are a few practices:

**Early testing.** The cost of fixing a defect increases as the SDLC progresses. Early testing for issue prevention is considered a best practice because it reduces costs, prevents defects from propagating, and reduces rework.

**Comprehensive test coverage.** Testing a broad range of scenarios minimizes the business risks associated with software failures. Comprehensive test coverage also helps ensure that the software meets user expectations, operates reliably, and performs well under various conditions.

**Strategic use of automation.** Manual testing may be adequate for smaller software projects. However, for larger, more complex projects like [enterprise application development](https://resources.github.com/enterprise/what-is-enterprise-application-development/), automated testing can be indispensable. Automated tests can be performed much faster than manual tests. This efficiency is especially crucial in scenarios where repetitive and time-consuming tests need to be performed, such as during regression testing or when running large-scale test suites.

**Realistic test data for simulation.** Using realistic test data for simulation in software testing is crucial because it provides an accurate representation of the production environment. Testing with data that closely mirrors actual data makes it easier to identify potential issues and behavior that may occur in real-world conditions.

**Continuous learning for improvement.** Software development is an incredibly dynamic field, and new tools, frameworks, methodologies, and technologies are regularly emerging. Fostering an environment of continuous learning allows teams to stay abreast of the latest developments and take advantage of new tools and techniques for more effective testing.

**Software testing tools.** Tools play a vital role in software testing by providing support and automation for various testing activities. Software testing tools help testers, developers, and quality assurance professionals perform their tasks more efficiently and effectively throughout the SDLC. There are numerous tools available to meet different needs.

**Test automation tools.** Automation tools enable testers to automate various activities like testing for web applications, mobile applications, or continuous integration and continuous delivery ([CI/CD](https://resources.github.com/ci-cd/)) processes. Many [DevOps tools](https://resources.github.com/devops/tools/compare/) on the market include test automation capabilities.

**Performance testing tools.** Performance testing tools are used to assess and optimize application performance under various conditions. These tools can highlight areas where the application may experience slowdowns or resource constraints, providing insight into response times.

**Security testing tools**. Tools for security testing, like [GitHub security tools](https://github.com/features/security), help teams identify, prioritize, and address security vulnerabilities in software applications. Their use is essential for building resilient and secure software in an environment where cybersecurity threats are constantly evolving.

**Code review tools.** Code review tools facilitate and streamline the process of reviewing source code within a development team. These tools help developers collaborate, find errors, ensure code quality, and maintain coding standards. [GitHub code review tools](https://github.com/features/code-review) are built into every pull request, so they fit easily into teams' existing workflows.

**AI tools.** AI-powered tools, such as [GitHub Copilot](https://github.com/features/copilot), can be useful to help testers perform such activities as writing tests or research potential issues. Learn more about how GitHub Copilot works by visiting the [GitHub Copilot Trust Center](https://resources.github.com/copilot-trust-center/).

## **Get started with software testing**

Software testing is critical for any organization developing software. To ensure your organization operates a successful testing program, foster a culture of quality within the organization, emphasizing the importance of delivering reliable and high-quality software to customers. Encourage collaboration between development and testing teams to streamline the testing process and identify issues early in the development life cycle. It's also important to invest in modern software testing tools and technologies that align with your organization's goals, and ensure that testing efforts contribute to improved customer satisfaction, reduced time-to-market, and minimized business risks. Make sure to stay informed about the evolving landscape of [software testing](https://learn.microsoft.com/shows/Software-Testing-Fundamentals/01), as it directly correlates with the overall success and competitiveness of your organization.

## **Frequently asked questions**

### **What do software testers do?**

Software testers play a crucial role in the SDLC by ensuring the quality, reliability, and functionality of software applications.

### **What are the main types of software testing?**

There are many types of software testing, including manual testing, automated testing, unit testing, integration testing, functional testing, non-functional testing, and regression testing.

### **What is the difference between software testing and quality assurance?**

Software testing is the process of systematically evaluating a software application to identify defects, ensure that it meets specified requirements, and verify its functionality. Quality assurance has a broader scope, and involves the systematic monitoring and improvement of the software development process to ensure the delivery of high-quality software.

### **What is the difference between software testing and automation testing?**

Software testing and automation testing are related concepts. Software testing refers to the entire process of evaluating a software application to identify defects, ensure it meets specified requirements, and verify its functionality. It includes both manual and automated testing. Automation testing refers to the use of tools and scripts to automate the execution of testing.

### **What is the difference between software testing and manual testing?**

Software testing refers to the entire process of evaluating a software application to identify defects, ensure it meets specified requirements, and verify its functionality. It includes both manual testing and automated testing. Manual testing involves human testers executing test cases without the use of automated testing tools.

Software testing is the systematic process of evaluating and verifying software applications to ensure they function correctly and meet specific requirements.

Resource Page for /software-development/what-is-software-testing

What is software testing? 

It seems simple: software should be intuitive, easy to use, and designed to help you meet your technical and business goals. But as soon as you dig deeper on the backend, you’ll likely uncover a complex web of components and processes, all working together to keep things running. To navigate the challenges of software design—and to reap the most benefits—it’s important to plan ahead.  

That’s where software architecture comes in. **Software architecture** refers to a set of fundamental structures that developers use as an overarching visual guide when planning for and building out software solutions. These frameworks also ensure that a project meets its technical and business needs by planning for important functionality such as scalability, reusability, and security. These plans are then broken down into individual components and code during the design phase. 

Let’s explore an overview of software architecture—and software architecture design—and its many strengths and applications. 

## **Key components of software architecture**

At its core, software architecture is made up of interchangeable building blocks called **software components.** Software components come in the form of packages, apps, or services, and they feature data that can be plugged into a larger system framework. 

These components can also be connected to each other through their respective **programming** **interfaces**. By delivering data from one interface to another, components communicate with each other to form a relationship, a system, or a grouping of systems. 

An **architecture style** helps define how these systems are patterned, organized, and used in tandem with each other, forming a cohesive design system that can then be referred back to throughout the entire [software development lifecycle (SDLC)](https://resources.github.com/software-development/what-is-sdlc/). And by templatizing these styles, they can be reused and reapplied to a variety of apps and solutions. 

## **Benefits of good software architecture**

Good software architecture design can help your organization: 

- Easily scale up or down through agile, iterative updates.
- Maintain code quality, reduce errors, and find bugs. 
- Modernize legacy systems, reduce audit and IT costs, and build innovative new customer experiences.
- Streamline development through reusability and automation, in turn saving time and boosting productivity.
- Reduce costs, speed up time to market, and boost customer satisfaction. 
- Optimize the overall performance of your software.

## **Challenges of software architecture**

In contrast, poorly designed software architecture may: 

- Make it difficult to effectively manage interactions between components.
- Leave your software vulnerable and open to security risks. 
- Increase the cost of initial investment. 
- Result in overly complex, overly engineered systems.
- Be too inflexible to adapt to changing scenarios, technology, and requirements.
- Contribute to performance bottlenecks. 
- Create communication issues between architects, developers, and users.
- Result in outdated, difficult-to-maintain architecture, contributing to a lack of integration capabilities. 
- Make it difficult to scale up and down without major architectural changes.
- Require the dedicated skills of an entire software team to fix or maintain it. 

## **Common architectural patterns**

### **Monolithic** 

A monolithic architecture is a traditional type of architectural style where a single container houses every component, service, and function that make up an application, resulting in lower costs, higher performance, and a simpler design. In the container, all the components are merged, which means they share the same codebase and are managed, processed, and deployed in a single, large file. 

Monolithic apps must be deployed in their entirety as a single unit, which means that updating or adding features to the codebase requires redeploying the entire app. This poses a challenge in terms of scalability. As a result of that, a monolithic architectural style is best suited for simpler, more general-purpose apps. 

### **Microservices**

A microservices architecture takes the monolithic structure and breaks it down into containerized collections of small, loosely bundled distributed services. Each service is autonomous, has its own separate codebase or external state, and has its own responsibilities within the context of the system, though they can also communicate with other services. By breaking the app down into smaller parts, developers can better update, test, and manage code. 

Microservices are considered foundational to modern app development and can be found in many major service-oriented apps, including streaming services and rideshare services. 

### **Client-server** 

In a client-server pattern, the client, also known as the host, sends a request for data, apps, specific services, or other resources to a remote computer, or a server. The server then accepts the request, processes it, and delivers the resources back to the client. 

This type of architectural style is best suited for email services, websites, file-sharing apps, or any other type of service that benefits from a call-and-response model. 

### **Layered** 

Also known as N-tier, a layered pattern divides an app into layers that perform specific functions. These layers are only able to communicate with the layers that sit directly below them. For example, a typical web application may be comprised of four layers: user interface or presentation, business, application, and database. In this situation, the presentation layer can only interact with the business layer, but not vice versa. 

Layered architecture simplifies development, testing, and maintenance as each individual layer can be updated or modified without affecting the layers beneath or above. It is the most widely used pattern among enterprise apps, especially among major ecommerce apps. 

### **Event-driven** 

An event-driven architecture is modeled around the recording, dissemination, and processing of events—actions or triggers that a user takes in an app that can cause a change in state, which the system recognizes in near real time—by communicating with decoupled services. The framework consists of event producers, which capture the event, as well as event routers, which transmit the events to consumers. 

Event-driven architecture is ideal for ecommerce websites with frequent user interaction, such as when a user fills a signup form or adds an item to their cart.  

## **Design principles and best practices**

Now that you’re acquainted with some of the most widely used software architecture patterns, you’ll want to consider the following design principles and best practices to help you apply them effectively:

### **SOLID principles**

Founded by software engineer Robert C. Martin, SOLID is an acronym that refers to a set of five object-oriented design (OOD) principles to follow when developing software. By adopting SOLID principles, developers can ensure that their project remains scalable, iterative, extensible, and bug-free. 

SOLID stands for:

- **Single-responsibility**. The single-responsibility principle states that a class—a template for grouping objects together—should only have one purpose or responsibility, and all its properties should serve that purpose.
- **Open-closed.** According to this principle, software objects, classes, or modules should be open for extension but closed for modification. An object can be extended without ever actually touching a piece of code. 
- **Liskov substitution**. Developed by computer scientist Barbara Liskov, the Liskov substitution principle states that interfaces should be substitutable, and that subclasses should be replaceable for their main classes.
- **Interface segregation.** This principle states that interfaces should be broken down into smaller, more autonomous parts for the purpose of minimizing code errors and repetition. 
- **Dependency inversion.** According to the dependency inversion principle, low-level modules can easily get swapped out for other low-level modules without high-level modules being affected. 

### **Separation of concerns**

The separation of concerns principle states that different parts of software should address different concerns. For instance, an app featuring a layered architecture is composed of four different layers—presentation, business, application, and data—with each layer fulfilling a different function for the software.

### **Modularity and encapsulation**

Encapsulation is a principle that states that components should manage their own behaviors and states, emphasizing easy bundling and loose coupling. Through encapsulation, different parts of software are self-contained and insulated from other parts of the app, allowing each component to operate autonomously. Encapsulation establishes modularity in app design, since objects and functions can be easily replaced with other modules—so long as they share the same interface. 

### **Design patterns**

Much like software architecture patterns, design patterns are reusable frameworks that allow you to build software faster and more efficiently through the templatization of code. While software architecture plans for the overarching structure of the solution, software design breaks the app down to the component level. Some popular design patterns include the singleton, the adaptor, and the proxy, though there are dozens to choose from. 

## **Tools and technologies for software architecture**

### **Unified modeling language (UML)**

The unified modeling language (UML) is a standardized visual modeling language for software design and development. As a visual language, UML uses diagrams rather than code to map out the structure of a software system, how it should behave, and how each of the components should interact with each other. 

### **Architectural modeling tools**

Architecture modeling tools help architects visualize, define, and document software architecture through graphical code rendering, or models. Models provide architects with a clear module-by-module breakdown of an app’s functionality. With the help of modeling tools, it’s easy to create and maintain models throughout the software development lifecycle. 

### **Version control and collaboration tools**

Version control systems and collaboration tools provide users with the ability to share code, track changes, manage conflicts, and work with teammates. This, in turn, fosters a culture that emphasizes [collaborative software development](https://resources.github.com/innersource/best-practices-collaborative-software-dev/). Version control tools allow for a more efficient workflow, higher quality code, and greater productivity overall. 

## **Conclusion**

A solid foundation with clearly defined goals is pivotal to the success of every development project. To navigate the complexities of software, it’s important to have a well-organized blueprint as your guide—which is why software architecture and design should always be a top priority for every team and organization.

## **Kickstart development with GitHub Codespaces**

Start exploring architectural styles with GitHub Codespaces, a fully configured, customizable online dev environment that lets you code in the cloud.

[Get started >](https://github.com/features/codespaces)

## **Frequently asked questions**

### **What is an example of software architecture?**

Software architecture provides developers with a structured system or blueprint for building software that aligns with their solution’s technical and business needs. Microservices are an example of a software architecture pattern that uses containers to break an app down into smaller, more manageable parts. This makes up many of today’s modern, cloud-native apps, including streaming services and rideshares. 

### **What are three types of software architecture?**

Three common types of software architecture patterns may include monolithic architecture, microservices architecture, and layered architecture.

### **What is the difference between software design and software architecture?**

Software architecture provides a structured, visualized framework for developers to refer to as a guide when building scalable, reusable software that meets their technical and business needs. 

These plans are then broken down into individual components and code during the software design phase. The design phase digs even deeper by defining what each component does and how they interact with each other, right to the code level. 

### **What is the best software architecture pattern?**

Each software architecture pattern has its own advantages and disadvantages to consider, as well as its own distinctive applications and use cases.  

### **What is the most widely used software architecture?**

Layered architecture, which divides an app into layers that perform specific functions, is the most widely used software architecture pattern among today’s enterprise apps, especially among modern ecommerce apps.

Learn how software architecture helps developers build scalable, efficient systems using best practices, key components, and common styles and patterns. 

Resource Page for /software-development/what-is-software-architecture

What is software architecture?

As proud platinum sponsors of this year's event, we can't wait to connect with you! 

From code scanning, secret scanning and supply chain security, we have you covered. GitHub Advanced Security is built to optimize the developer experience through automation. It helps your teams identify and fix reported security issues quickly and efficiently by integrating security into every step of the developer workflow.

Swing by our booth to see it in action, snag some exclusive swag, and catch our speaking session. Plus, if you're seeking personalized attention, simply complete the form below, and we'll reach out to schedule a one-on-one discussion.
Don't miss this opportunity to immerse yourself in the latest trends and innovations in cybersecurity. See you at BSidesSD 2024! 🚀

__Speaking Session__

How to accidentally host a crypto-mining operation in less than 3 minutes

Public GitHub repositories are a gold mine for credential thieves. In fact, it takes only 3 minutes for AWS tokens written to public repositories to be stolen by crypto-mining bots. Once they have those tokens, your infrastructure quickly becomes their mining operation.

However, AWS tokens are only one of many types of credentials leaked every day. At GitHub, we see this problem as a fundamental risk to the open source software supply-chain.

In this session, we’ll share how GitHub is stopping credentials from being published to public repositories. We’ll talk about the most common types of secrets we see on our platform, how they’re leaked, and how you can identify and prevent them from being stored in plain-text in your environment.

Join us to learn how we can all work together to put a stop to secret leaks and protect the open source ecosystem from security breaches.


form-webcast-signup "Meet the GitHub team"

Meet the GitHub team

Get ready, because BSidesSD is back for an exhilarating one-day extravaganza on March 30th, 2024, at San Diego State University and GitHub will be there! 

BSides at San Diego LP Header

Resource Page for /github-at-bsides-sandiego-mar30

CO-GHS-IPVNT-FY24-03Mar-08-GitHub-BSides-Hacker-Spring-Break-2024

GitHub at BSides San Diego

GitHub Advanced Security continues to evolve as a critical component of the Azure DevOps platform, equipping developers with the tools and insights needed to build secure and resilient software applications. 

With a focus on continuous innovation and collaboration, GitHub Advanced Security is poised to play a central role in advancing the state of application security, enabling developers to deliver secure code with confidence.

Save your seat now by filling up the form below!

form-webcast-signup

Sign Up to Join

GitHub Advanced Security for Azure DevOps is an integrated security solution. This session provides an overview of the latest features and roadmap for GitHub Advanced Security on Azure DevOps, highlighting its evolving functionalities and future directions.

8e452c3209d4e2ec780d9fca252022209507406ceb4a83fa8d60197cf2191e36-1200x630

Resource Page for ghazdo-advancements-march28

CO-GHDO-WBNR-FY24-03Mar-06-GitHub Advanced Security for Azure DevOps-New Features and Roadmap

GitHub Advanced Security for Azure DevOps: New Features and Roadmap

GitHub Advanced Security (GHAS) enables DevSecOps teams to prioritize innovation while maintaining robust security measures. At GitHub Universe, we explored how the AI-powered features within GHAS surface issues in the context of the development workflow, so vulnerabilities are fixed in minutes, not months. Now you can, too, during this exclusive on-demand webinar.

What to expect:
- Discover how AI-powered features in GHAS help developers ship secure software, faster.
- Get ahead of the revolutionary changes that are reshaping the security landscape.
- See real-world examples of AI-powered security tools in action.

Gated video page generic form

Tell us a bit about you

Sign up to watch

From prevention to remediation, AI-assisted tooling changes everything.

The future of secure software development is here. Let’s dive in. 

<div class="embed-responsive embed-responsive-16by9">
  <iframe src="https://www.youtube.com/embed/jpOnKc9lFIc" width="640" height="375" frameborder="0" allowfullscreen></iframe>
</div>

GitHub Advanced Security (GHAS) enables DevSecOps teams to prioritize innovation while maintaining robust security measures. At GitHub Universe, we explored how the AI-powered features within GHAS surface issues in the context of the development workflow, so vulnerabilities are fixed in minutes, not months. Now you can, too, during this exclusive on-demand webinar.

What to expect:
- Discover how AI-powered features in GHAS help developers ship secure software, faster.
- Get ahead of the revolutionary changes that are reshaping the security landscape.
- See real-world examples of AI-powered security tools in action.

A dark background with three large, gradient-filled circle and square, overlapping shapes positioned partially off-canvas, from the top-right of the image. Webinar: Transforming application security with AI.

Resource Page for /security/transforming-application-security-with-ai

CO-GHS-WBNR-FY24-01Jan-04-2024-AI-powered AppSec

Transforming application security with AI

![Supercharge collaboration with AI-powered innersource](//images.ctfassets.net/wfutmusr1t3h/1UDPl4OChWLgUOPUOyQTJx/f7002c2a55c186d58b503104603727a9/Landing_page_header__1200x628__2___1_.png)

Watch our webinar to learn how AI is key to driving cross-team collaboration and realizing innersource’s full potential.

Here’s what to expect:

- Discover how AI helps developers break down the barriers traditionally associated with innersource.
- See how implementing AI tools can help engineering teams overcome silos and enable collaboration.
- Learn what you can do today to prepare your organization for AI-powered innersource.

Innersource centers around bringing the methodologies, learnings, and collaborative spirit from open source into internal development. However, implementing effective innersource practices—by enabling internal development teams to discover, understand, and reuse existing code instead of building from scratch—is challenging.

<div class="embed-responsive embed-responsive-16by9">
  <iframe src="https://www.youtube.com/embed/Ur5G04rwBUg" width="640" height="375" frameborder="0" allowfullscreen></iframe>
</div>

Watch our webinar to learn how AI is key to driving cross-team collaboration and realizing innersource’s full potential.

Here’s what to expect:

- Discover how AI helps developers break down the barriers traditionally associated with innersource.
- See how implementing AI tools can help engineering teams overcome silos and enable collaboration.
- Learn what you can do today to prepare your organization for AI-powered innersource.

Supercharge collaboration with AI-powered innersource

Resource Page for /webcasts/supercharge-collaboration-with-ai-powered-innersource-gated

/webcasts/supercharge-collaboration-with-ai-powered-innersource

In this on-demand webinar, you’ll learn about the tools that are available to help with your migration and best practices you can follow to make your migration a success. We will also show you how to migrate to GitHub thanks to product demos.

__Agenda__
- Introduction to GitHub Enterprise Importer
- Demo showing our GitHub Enterprise Importer tool in action
- Three top tips for a successful migration


If you’re looking to make the move from Bitbucket Server to GitHub ahead of Bitbucket Server’s upcoming deprecation, we know you’ll have data you want to bring with you so your team can hit the ground running quickly. We also know that fear of migration can be a big barrier to switching to GitHub, which is why we’ve worked hard to make moving quick, low cost and painless. 

<div class="embed-responsive embed-responsive-16by9">
  <iframe src="https://www.youtube.com/embed/Rf8hJRx-bLU" width="640" height="375" frameborder="0" allowfullscreen></iframe>
</div>

In this on-demand webinar, you’ll learn about the tools that are available to help with your migration and best practices you can follow to make your migration a success. We will also show you how to migrate to GitHub thanks to product demos.

__Agenda__
- Introduction to GitHub Enterprise Importer
- Demo showing our GitHub Enterprise Importer tool in action
- Three top tips for a successful migration


GitHub logo with purple organic shapes in the background

What is technical debt?

What is software testing?

What is software architecture?

Latest events

GitHub at BSides San Diego

GitHub Advanced Security for Azure DevOps: New Features and Roadmap

Browse by topic

Latest videos

Transforming application security with AI

Supercharge collaboration with AI-powered innersource

Moving repositories from Bitbucket Server to GitHub

Accelerate innovation with the platform developers love

Codespaces

Advanced Security

Actions

Packages

Questions? Reach out to our sales team