{"id":16945248,"url":"https://github.com/offgriddev/esta","last_synced_at":"2026-04-18T09:31:34.033Z","repository":{"id":143898933,"uuid":"613537681","full_name":"offgriddev/esta","owner":"offgriddev","description":"ESTA is an objective estimation automation tool based on data, not subjective feelings (story points)","archived":false,"fork":false,"pushed_at":"2023-05-02T21:04:53.000Z","size":38981,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-08-14T05:37:14.085Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"JavaScript","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/offgriddev.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":"2023-03-13T19:08:50.000Z","updated_at":"2023-05-01T20:14:18.000Z","dependencies_parsed_at":null,"dependency_job_id":"75585a45-7157-4677-9e3b-39a40998034d","html_url":"https://github.com/offgriddev/esta","commit_stats":null,"previous_names":[],"tags_count":5,"template":false,"template_full_name":null,"purl":"pkg:github/offgriddev/esta","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/offgriddev%2Festa","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/offgriddev%2Festa/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/offgriddev%2Festa/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/offgriddev%2Festa/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/offgriddev","download_url":"https://codeload.github.com/offgriddev/esta/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/offgriddev%2Festa/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":31963966,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-18T00:39:45.007Z","status":"online","status_checked_at":"2026-04-18T02:00:07.018Z","response_time":103,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"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":[],"created_at":"2024-10-13T21:21:45.745Z","updated_at":"2026-04-18T09:31:34.017Z","avatar_url":"https://github.com/offgriddev.png","language":"JavaScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# está overview\n\n`está` is a GitHub Action responsible for analyzing the Cyclomatic Complexity of a TypeScript repo for export to a storage for future analysis. The philosophy behind `está` is that it is not harmful to a team to analyze estimates for projects for the sake of validating their validity. Valid estimates should be something we all strive to provide as engineers. Validating our estimates is part of our engineering practice. If we are not open to validating our estimates, we must be already aware that they are nonsense. Instead of running away from validation, we should be open to seeing what the _actual_ estimate was in relation to the one we've given for a certain task. Only when confronted with the reality of the actual estimate are we able to reflect on what happened.\n\nAn estimate is a theory. It's a theory about the future state of a project and what the work will be like when we approach it. In the software industry, we've opted to reduce our estimation practices to theater. We've feigned ideas out of thin air called \"Story Points\" and have concocted _games_ to drive an estimation process that is completely subjective. Subjective estimations like Story Points resent validation because a Story Point does not represent anything at all. It's a metaphor. We cannot operate in a rational manner by relying on figures of speech to drive estimates that inform businesses of the realities of software engineering.\n\nThis is why `está` exists. `está`, which originates from Spanish `estár`, which is a temporal state of existence. Frederick Brooks states that Complexity is \"the business we are in\" as software engineers, and complexity is a time-bound phenomenon. This action will take a snapshot of the cyclomatic complexity of a TypeScript repository so your team can use it as an _objective_ metric for driving estimates. Software _is_ a given complexity for a moment in time. Complexity grows in a system, and as teams commit, this can be reduced or increased. This is an important fact to be aware of as engineers. If a module in your system gets too complex, it has been linked through numerous studies that it will become the thorn in the side of the developers maintaining it.\n\n## cyclomatic complexity as a basis for estimations\n\nCyclomatic Complexity, as defined in Thomas McCabe's 1976 paper \"A Complexity Measure\", is the application of a graph theory's Circuit Rank to the control flow graph within a given codebase. This is a concrete, objective measurement from the code that developers labor over. Developers produce code, and as code is produced overtime, simply analyzing the complexity of the codebase and the size of each module can not only inform the team of where to drive future optimizations, but how to understand their _true velocity_.\n\nStory Points are fake. They're a made up measurement of development work that has no grounds in our experience. We _slice_ our projects into \"stories\" and rank them by size, but there is no \"story\" that I can perceive _in the world_ whereby I can \"measure\" it's magnitude, thickness, color, size, shape, or any other secondary characteristic of its existence. Therefore, we could _never_ understand our _true velocity_ by it as we build software. You may as well be counting how many angels are dancing on the head of a pin.\n\nComplexity, as measured in software by McCabe, provides us with a _concrete_ and _real_ measurement. Teams can use the GitHub commit data with the complexity measurement of the repository, to observe the organic growth of their systems and modules. With this, they can see how quickly they _deliver complexity_ and measure their _speed_ over time. This is a measure of efficiency in teams.\n\nTherefore, when you are asked by your stakeholders how long something will take to build, you can provide a _reasonable estimate_ based on data, not just the subjective feelings about the invisible size of a \"story,\" which has no relation to a stakeholders _budget_ or _capital investent_. Complexity, however, can easily be converted into time without the classic \"cheatsheet\" for story point estimates because are observing the _rate of production_. Software is complexity. Observing complexity emerge in code is observing the _rate of production_ in software engineering organizations.\n\n## ground rules for complexity\n\nMcCabe's states that Cyclomatic Complexity is a mathematical measure for modularization of software. As we reduce the amount of logical, linear paths that can be traced through code, maintainability and realibility of the code increases. This also follows from _simplification_. Therefore, when we approach estimations, we must limit the complexity of the modules in our design.\n\nMcCabe recommends 10 max CC functions, but I've worked on teams and kept it to 5 with great success here. The point of estimating the complexity of modules happens at a distinct point in the SDLC.\n\n# process explained\n\nThe Software Development Lifecycle (SDLC) is a series of conversations / feedback cycles oriented around taking a product vision and requirements and resolving it\n\n![SDLC Overview](docs/img/sdlc-overview.png)\n\nThe need for teams to discuss the requirements typically collapses into a \"card breakdown\" session. Everyone may have unique names for this event, but it's a ceremony wherein developers, meet to discuss the requirements and begin the brainstorm the solution. This conversation can go undirected if there isn't preliminary work done to conceptualize the domain. This can be done by another developer or someone concerned with architecture.\n\n`moar later`\n\n# how to use esta-action\n\nTBD\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Foffgriddev%2Festa","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Foffgriddev%2Festa","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Foffgriddev%2Festa/lists"}