{"id":15894906,"url":"https://github.com/clayrisser/adaptive-resilient-software","last_synced_at":"2026-03-18T17:09:40.032Z","repository":{"id":50206452,"uuid":"125401708","full_name":"clayrisser/adaptive-resilient-software","owner":"clayrisser","description":"Process for building software that can recoil from transition quickly","archived":false,"fork":false,"pushed_at":"2023-07-06T12:31:37.000Z","size":831,"stargazers_count":2,"open_issues_count":0,"forks_count":1,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-10-10T14:56:43.488Z","etag":null,"topics":["adaptive","adaptive-resilient-software","ars","resilient","software","whitepaper"],"latest_commit_sha":null,"homepage":"https://ars.jamrizzi.com","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/clayrisser.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2018-03-15T17:15:38.000Z","updated_at":"2023-07-06T12:31:42.000Z","dependencies_parsed_at":"2024-10-28T04:02:07.200Z","dependency_job_id":"76259d5d-570c-410b-bc9a-dc3ba4242127","html_url":"https://github.com/clayrisser/adaptive-resilient-software","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/clayrisser/adaptive-resilient-software","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/clayrisser%2Fadaptive-resilient-software","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/clayrisser%2Fadaptive-resilient-software/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/clayrisser%2Fadaptive-resilient-software/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/clayrisser%2Fadaptive-resilient-software/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/clayrisser","download_url":"https://codeload.github.com/clayrisser/adaptive-resilient-software/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/clayrisser%2Fadaptive-resilient-software/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28274297,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-11T02:08:32.518Z","status":"ssl_error","status_checked_at":"2026-01-11T02:08:32.093Z","response_time":60,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["adaptive","adaptive-resilient-software","ars","resilient","software","whitepaper"],"created_at":"2024-10-06T08:42:32.533Z","updated_at":"2026-01-11T03:04:36.110Z","avatar_url":"https://github.com/clayrisser.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Introduction\n\n![](assets/adaptive-resilient-software.png) \n\nTraditionally, resilient software is software that can recoil from failure\nquickly. We will define adaptive resilient software as **software that can recoil\nfrom transition quickly**. A transition can occur negatively as vicissitude, but\noften it happens as a result of progressive evolution.\n\nA common vicissitude is the inevitable departure of a software engineer or\nsoftware team. It is easy for software engineers to focus on the current\nobjective and fail to prepare the software for when they leave. This failure\nis a result of few incentives to give thought towards the future of the\nsoftware. In fact, often there are more incentives to develop software that is\nnot adaptive. Software that is dependent on a few engineers is a form of job\nsecurity. Purposefully writing nonadaptive software happens more frequently than\nsoftware engineers will admit.\n\nNot all transitions are negative. Companies often pivot their strategies which\ncan result in significant software transformation. Planning for such shifts are\noften overlooked by software engineers. In summary, writing nonadaptive software\nwill naturally occur unless processes are put in place to prevent it.\n\nMany large corporations have processes to encourage adaptive resilient software.\nHowever, they have a strong incentive to do so. The most significant culprit\nthat fails to write adaptive resilient software is development shops because\nthey do not bear the consequences of nonadaptive software.\n\nThe first section of this paper will cover some practical methods to build\nadaptive resilient software. The next section will cover some practical open\nsource tools for implementing adaptive resilient software. The last section will\ngive some tips for detecting whether a software engineer or development shop is\nwriting adaptive resilient software.\n\nWe can build adaptive resilient software by creating flexible, maintainable,\nscalable, and transparent software.\n\n## Practical Methods\n\n### Flexible Software\n\nWe should first implement processes to create flexible software. We will define\nflexible software as software that can pivot and evolve without requiring large\namounts of refactoring. Flexible software helps it recoil from a transition\ninvolving progressive evolution. Some processes that will help create flexible\nsoftware include unit tests, continuous integration, documentation, observability,\ninfrastructure as code, abstractions such as containerization and development\nprocesses such as merge requests and code reviews.\n\n### Scalable Software\n\nWe should additionally implement processes to create scalable software. We will\ndefine scalable software as software that can accommodate its growth potential\nwithout requiring large amounts of refactoring. Scalable software helps a\nplatform handle a growth transition. Some processes that will help create\nscalable software include unit tests, quality control gates, containerization,\nand orchestration.\n\n### Maintainable Software\n\nWe should also implement processes to create maintainable software. We will\ndefine maintainable software as software that can transcend individual software\nengineers. Maintainable software helps a platform recoil from the inevitable\ntransition of software engineers. Some processes that will help create\nmaintainable software include linting, unit tests, documentation, continuous\nintegration, and quality control gates.\n\n## Practical Techniques\n\nThe following techniques can help build adaptive resilient software that\nis flexible, maintainable, scalable, and transparent.\n\n### Linting\n\nLinting contributes to maintainable software because it forces standardization\nacross the codebase. A standardized codebase makes it easier for a software\nengineer to understand and navigate the codebase.\n\n### Unit Tests\n\nUnit tests are difficult to create for large complex functions with side\neffects. Thus, unit tests have the added benefit of forcing engineers to split\ntheir code into small individual pure units, which are naturally easier to\nextend and reuse. Extendable and reusable code positively contributes to\nflexible software.\n\n### Continuous Integration\n\nContinuous integration is used to automate software tests, builds, deployments and\nother tasks necessary in the software development lifecycle. Without continuous\nintegration, the software development lifecycle is at the mercy of individual \ndevelopers and cannot be enforced in a consistent manner. Using continuous\nintegration helps onboard new developers faster because they do not need to know\nall the nuanced details about how the software is put together to be productive. \n\n### Documentation\n\nDocumentation helps keep track of the software's application programming\ninterfaces. In other words, it allows engineers to recall and understand how the\ncode works without reading the entire codebase. Documentation contributes to\nflexible software because it speeds up the time it takes for software engineers\nto extend and modify the codebase. Documentation can also enable a project owner\nto understand the essence of the software without being required to understand all\nthe implementation details.\n\n### Containerization\n\nContainerization creates a partition between software engineers and dev-ops\nengineers. This partition also contributes to flexible software, because a\nsoftware transition will not require a significant change in the dev-ops world.\nOften, software engineers can make extensive changes to the codebase with no\nmodifications needed by the dev-ops team.\n\n### Infrastructure as Code\n\nInfrastructure as Code is a technique that describes an infrastructure topology\nusing code. One of the most powerful things about infrastructure as code is that\nis forces every detail of the infrastructure to be documented with code. This \nensures the critical knowledge of systems are protected even if the developer\nwho created the infrastructure leaves. This also increases the ability to debug\ninfrastructure and makes it possible to have very few people maintaining very\ncomplex systems.\n\n### Continuous Integration\n\nContinuous integration automates the often complex deployment process. Automated\ndeployment allows new software engineers to dive into the code without requiring\nthem to understand the deployment process. It also forces engineers to record\nthe deployment process, rather than dangerously keep that vital knowledge to\nthemselves.\n\n### Quality Control Gates\n\nQuality control gates are automated barriers that prevent deployment when\nenabled. These barriers are activated when a codebase fails to meet defined\ncriteria. The defined criteria can involve the code coverage percentage, the\nnumber of code smells, the number of vulnerabilities, the number of\nduplications, the code size, and the number of bugs. Quality control gates force\nengineers to improve the maintainability of the software. Quality controls gates\ncontribute to scaling because they can detect places where the code can be optimized.\n\n### Unit Tests\n\nAs stated previously, unit tests force software engineers to split their code\ninto many small modular pieces. Modular code can help engineers run diagnostics\nto pinpoint areas that can be optimized. Optimizing software is a crucial part\nof scaling software.\n\n### Containerization\n\nContainerization enables a dev-ops team to scale a platform horizontally across\nmultiple servers with minimal complexity. This scaling is possible due to the\nimmutable nature of containers.\n\n### Orchestration\n\nOrchestration is the software that handles coordination of containers across a\npool of servers. Like containerization, it is a critical piece to enable\nhorizontal scaling across servers with minimal complexity.\n\n### Transparent Software\n\nLast of all, we should implement processes to create transparent software. We\nwill define transparent software as software individuals can understand without\nthe requirement to understand the code. Transparent software is specifically\napplicable for leaders or those who carry the vision for a software platform.\nThis transparency creates a powerful feedback loop that once in place will\nvastly improve a transition of leadership. Some processes that will help create\ntransparent software include documentation, quality control gates,\nand project management.\n\n### Observability\n\nObservability is used to measure the internal state of a system or process. With\ndetailed knowledge of an existing state, steps can be taken to improve the respective\nsystem's performance, reliability and usefulness. Observability can help take\npreemptive measures when a potential future issue is detected. Data collected from\nobservability can also be used to help efficiently prioritize efforts.\n\n### Quality Control Gates\n\nQuality control gates allow a leader to see the quality of the software through\nsimple metrics.\n\n### Project Management\n\nProject management enables a project owner to know the current status of the software\nconcerning the goals and vision of the project. It also creates accountability\nwith the developers working on a project. The best project management system is one\nthat is tightly integrated with development process.\n\n## Detecting ARS\n\nIt can be difficult to detect whether a software engineer or software team will\nwrite adaptive resilient software. One practice that may be helpful is to review\ntheir processes and compare it with the practical development methods for\nbuilding adaptive resilient software.\n\nIn many situations, a development shop will not be practicing all of the\nrecommended processes suggested. These situations do not necessarily conclude\nthe software team failed to build adaptive resilient software. Regardless of the\nspecific processes, you should look for a team that creates flexible,\nmaintainable, scalable, and transparent software. Ultimately it is up to you to\ndetermine what procedures are essential and choose the team that best matches\nyour goals.\n\nOnce you choose a team, it will be much easier to determine how they operate.\nYou should first look for transparency in the software team. If the team is not\ntransparent, it will be difficult to know if they are building flexible,\nmaintainable, and scalable software. If the team is transparent, you will want\nto make sure the team gives thought to what happens when they are out of the\npicture.\n\n## Practical Tools\n\nBelow are some specific tools that can help software engineers implement the\nprevious processes. All of the tools listed are open source.\n\n### Linting\n\nLinting requires different tools depending on the programming language used.\n\n#### [Pylint](https://www.pylint.org)\nA Python source code analyzer which looks for programming errors, helps to\nenforce a coding standard, and sniffs for some code smells\n\n#### [Eslint](https://eslint.org)\nThe pluggable linting utility for JavaScript and JSX\n\n### Unit Tests\n\nUnit tests also require language-specific tools\n\n#### [PyUnit](https://wiki.python.org/moin/PyUnit)\nAn easy way to create unit tests with Python\n\n#### [Mocha](https://mochajs.org)\nA feature-rich JavaScript test framework running on Node.js and in the browser,\nmaking asynchronous testing simple and fun.\n\n#### [Jasmine](https://jasmine.github.io)\nSimple JavaScript testing framework for browsers and Node.js\n\n#### [Jest](https://facebook.github.io/jest)\nDelightful JavaScript testing\n\n### Documentation\n\nOne can write documentation manually, but it is much easier to use a\ndocumentation generator.\n\n#### [Sphinx](http://www.sphinx-doc.org)\nA tool that makes it easy to create intelligent and beautiful documentation\n\n### Continuous Integration\n\n#### [Jenkins](https://jenkins.io)\nThe leading open source automation server\n\n#### [Drone](https://drone.io)\nAn open source continuous delivery platform that automates your testing and\nrelease workflows\n\n### Quality Control Gates\n\n#### [SonarQube](https://www.sonarqube.org)\nThe leading product for continuous code quality\n\n### Containerization\n\n#### [Docker](https://www.docker.com)\nA platform to create, deploy and manage virtualized application containers on a\ncommon operating system\n\n### Orchestration\n\n#### [Kubernetes](https://kubernetes.io)\nA system for automating deployment, scaling, and management of containerized\napplications\n\n#### [Mesos](http://mesos.apache.org)\nAbstracts CPU, memory, storage, and other compute resources away from machines,\nenabling fault-tolerant and elastic distributed systems\n\n#### [Docker Swarm](https://docs.docker.com/engine/swarm)\nA native Docker clustering system\n\n#### [Rancher](https://rancher.com)\nDeploy and manage Kubernetes with ease\n\n### Project Management\n\n#### [Taiga](https://taiga.io)\nA project management platform for agile developers who want a beautiful tool\nthat makes work truly enjoyable\n\n## Conclusion\n\nTransitions are a necessary, inevitable part of software development. It is time\nto prepare for them as part of your development strategy by building adaptive\nresilient software.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fclayrisser%2Fadaptive-resilient-software","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fclayrisser%2Fadaptive-resilient-software","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fclayrisser%2Fadaptive-resilient-software/lists"}