# Defects Published articles for Defects. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Atlassian Automates Root Cause Analysis by Correlating Metrics, Logs and Traces DevFeed: [Atlassian Automates Root Cause Analysis by Correlating Metrics, Logs and Traces]() Original publisher: [Read original article]() Author: Craig Risi Published: 2026-09-15T12:00:00Z Content type: news Language: en Sources: [InfoQ]() Topics: [incident](), [atlassian](), [telemetry](), [SIEM, Security, Observability](), [tracing](), [Cloud Native Ecosystem](), [OpenTelemetry]() Tags: [atlassian](), [atlassian-automated-rca](), [cloud-native](), [defects](), [devops](), [distributed](), [incident](), [incident-response](), [logging](), [logs](), [metrics](), [news](), [opentelemetry](), [root-cause-analysis](), [services](), [telemetry](), [traces](), [tracing]() ### AI overview Atlassian has outlined an approach to automating root cause analysis for large-scale cloud-native incidents. It correlates metrics, logs, distributed traces, and service topology to detect anomalies, align them in time, trace dependencies, and produce ranked hypotheses about likely fault origins and propagation paths. ### Source excerpt Atlassian has outlined a new approach to automating root cause analysis for large-scale cloud-native incidents, using correlation across metrics, logs, distributed traces, and service topology to generate ranked hypotheses about where failures originate and how they propagate. By Craig Risi ## Find technical debt at dependency-injection boundaries DevFeed: [Find technical debt at dependency-injection boundaries]() Original publisher: [Read original article]() Published: 2026-08-18T00:00:00Z Content type: article Language: en Sources: [Koin - Cloud-Inject.io -Kotzilla]() Topics: [Dependency injection](), [Framework](), [Code]() Tags: [architecture](), [defects](), [dependency-injection](), [errors](), [review](), [structure](), [technical](), [test](), [tests]() ### AI overview This article explains how dependency-injection code can expose architectural debt. It identifies signals such as oversized modules, string qualifiers, lifetime inversion, construction that starts work, broad production-container tests, and definitions spread across UI locations. It recommends paying down debt at product-slice boundaries, separating construction from behavior, adding focused graph and behavior tests, and measuring ownership, verification, startup, and test setup. ### Source excerpt Dependency-injection code is often treated as plumbing. It is also a compact map of architecture decisions. Review it for debt signals before adding another binding. Signals worth investigating An oversized application module usually means feature boundaries are not explicit. String qualifiers can hide a missing type. Definitions that open databases or start jobs during graph creation mix construction with behavior. A process-scoped object that accepts a screen-owned dependency indicates lifetime inversion. ## TDD: Writing Testable Code DevFeed: [TDD: Writing Testable Code]() Original publisher: [Read original article]() Author: Eric Elliott Published: 2024-01-21T23:50:43Z Content type: tutorial Language: en Sources: [Eric Elliot]() Topics: [Test-driven development](), [Software Engineering](), [coding](), [CI/CD]() Tags: [advice](), [complexity](), [defects](), [javascript](), [modularity](), [react](), [software-engineering](), [tdd](), [technology](), [typescript]() ### AI overview This tutorial explains how to write more testable code through modularity, clarity, separation of concerns, and independence from external systems. It also describes tight coupling as a barrier to testability and maintainability, noting that dependencies can cause changes to cascade into bugs elsewhere. ### Source excerpt Writing testable code is a vital skill in software engineering. Let's explore practical advice, strategies, and tactics for writing more testable code, unlocking the benefits of modularity, reusability, and high quality software in your projects. Embracing testability in your coding practice isn't just about catching bugs; it's about fostering a culture of quality and efficiency in your projects. A good quality process is an essential prerequisite to continuous delivery, which is the ability to ship code to production at any time, allowing you to iterate quickly and respond to user needs and changing expectations. We'll start by exploring the importance of separation of concerns -- a principle that's crucial in achieving testable code. This approach isn't just a technical necessity; it's a mindset that simplifies complexity and enhances the overall quality of your work. Whether you're a seasoned developer or just starting out, this article aims to provide practical advice and strategies that can be immediately applied to your projects. Overview of Testability in Code Testability in code refers to how easily a software system can be tested. Highly testable code allows for more efficient and effective identification of defects, ensuring higher quality and reliability. Key characteristics of testable code include modularity, where the code is organized into discrete units; clarity, meaning the code is understandable and its purpose is clear; and independence, where units of code can be tested in isolation without reliance on external systems or states. Understanding the Problem: Tight Coupling in Code Tight coupling is often a subtle yet significant barrier to achieving highly testable and maintainable code. Coupling is the degree to which a change in one part of the code may impact or break the functionality in another part of the code. Tight coupling occurs when two or more parts of the code are highly dependent on each other, making it difficult to change one part wi ## Responsible and Effective Bugfinding DevFeed: [Responsible and Effective Bugfinding]() Original publisher: [Read original article]() Author: regehr Published: 2020-08-17T18:36:43Z Content type: article Language: en Sources: [Embedded in Academia]() Topics: [bug](), [Software](), [Open Source]() Tags: [article](), [bug](), [computer-science](), [defects](), [report](), [software-correctness]() ### AI overview The article explains how to conduct external bug-finding efforts so they maximize overall benefit. It argues that bug finders should work carefully and collaboratively with software developers instead of overwhelming projects with large numbers of reports. ### Source excerpt NB: This piece is not about responsible disclosure of security issues. For almost as long as people have written code, we have also worked to create methods for finding software defects. Much more recently, it has become common to treat "external bug finding" -- looking for defects in other people's software -- as an activity [...] ## PGP's Legacy Design and Cryptographic Deficiencies DevFeed: [PGP's Legacy Design and Cryptographic Deficiencies]() Original publisher: [Read original article]() Published: 2019-07-17T01:14:00Z Content type: opinion Language: en Sources: [Latacora]() Topics: [Cryptography](), [Encryption](), [Security, Privacy and Abuse Prevention]() Tags: [certificates](), [compression](), [crypto](), [cryptography](), [defects](), [parsing](), [passwords](), [pgp](), [signing]() ### AI overview This commentary argues that PGP has significant design and cryptographic deficiencies rooted in its 1990s origins. It examines the complexity of PGP's packet structure, key management, parsing, compression, signing, and encryption features. ### Source excerpt Cryptography engineers have been tearing their hair out over PGP's deficiencies for (literally) decades. When other kinds of engineers get wind of this, they're shocked. PGP is bad? Why do people keep telling me to use PGP? The answer is that they shouldn't be telling you that, because PGP is bad and needs to go away. There are, as you're about to see, lots of problems with PGP. Fortunately, if you're not morbidly curious, there's a simple meta-problem with it: it was designed in the 1990s, before serious modern cryptography. No competent crypto engineer would design a system that looked like PGP today, nor tolerate most of its defects in any other design. Serious cryptographers have largely given up on PGP and don't spend much time publishing on it anymore (with a notable exception). Well-understood problems in PGP have gone unaddressed for over a decade because of this. ## Software Rot, Entropy and the Broken Window Theory DevFeed: [Software Rot, Entropy and the Broken Window Theory]() Original publisher: [Read original article]() Author: umer Published: 2016-05-02T00:00:00Z Content type: article Language: rll Sources: [Code Ahoy - Articles]() Topics: [Software](), [Code quality](), [Refactoring]() Tags: [code-quality](), [complexity](), [defects](), [developers](), [projects](), [refactoring](), [software]() ### AI overview The article explains how software projects accumulate complexity and defects when teams take shortcuts, causing software entropy or code rot. It argues that refactoring or rewriting may provide only short-term relief unless teams adopt practices to control future complexity, with psychology and team culture identified as important contributing factors. ### Source excerpt "Complexity is the business we are in and complexity is what limits us." - Fred Brooks, The Mythical Man-Month Software projects go through many modifications over their lifetime. As they evolve, the code grows in size and complexity creeps in. Software developers spend a large portion of their time maintaining existing software either by adding new functionality or fixing bugs. Often times, they are forced to take shortcuts to meet deadlines. Developers add new functionality in a 'quick and dirty' manner and apply duct-tape to defects. While the organization meets its short-term goal of getting the software out of the door quickly, the code quality suffers and deteriorates. After a while, things start to get really bad. The software becomes so complex and buggy, that it is virtually impossible to maintain. Fixing a bug would introduces more bugs and modifying one part of the software would break several others. Let's look at a related concept called software entropy. Entropy is the amount of disorder in a system. It is a physical phenomenon but Ivar Jacobson et al used it to describe the disorder in a software system: The second law of thermodynamics, in principle, states that a closed system's disorder cannot be reduced, it can only remain unchanged or increased. A measure of this disorder is entropy. This law also seems plausible for software systems; as a system is modified, its disorder, or [software] entropy, always increases. This is called Software Entropy. When the 'disorder' or the software entropy increases, it leads to software or code rot. The system ends up becoming so complex and disorganized that it is too costly or impossible to maintain. People get frustrated and consider major refactoring or, in some cases, rewriting from scratch. These arduous solutions fix the problem in the short-term but the software will rot again if the team doesn't adopt a plan for keeping future complexity under control. While there are many factors that lead to software r ## Accept Imperfect Code and Use Code Review to Improve It DevFeed: [Accept Imperfect Code and Use Code Review to Improve It]() Original publisher: [Read original article]() Author: Andrew Khmylov Published: 2014-03-17T00:00:00Z Content type: opinion Language: en Sources: [Despite the odds]() Topics: [Code](), [Code review](), [engineering-culture]() Tags: [code](), [code-review](), [defects](), [developers](), [formatting](), [knowledge-sharing](), [requirements]() ### AI overview This opinion article argues that developers should accept that code is often imperfect without settling for poor quality or endlessly pursuing a perfect solution. It recommends code review to catch formatting, minor code issues, design pitfalls, and to share implementation knowledge. ### Source excerpt So you are sitting at your desk wondering how come your beautifully- and carefully-thought abstractions have turned into an ugly monster, and why your precious codebase smells like a giant mess. You may be not the smartest guy around but you are not that stupid or unqualified after all. Well, just accept that your code sucks and stop worrying about it. Even the most brilliant programmers I know come up with the messy code or leaky abstractions sometimes. To fail is human. The business requirements come and go, the product evolves, you are growing as a professional. Don't be OK with it, just stop torturing yourself trying to find the 100% perfect solution. If it works for now and it looks easy enough to be changed later, then it's probably fine. On a side note, I would rather wonder why you are OK with any code at all. If you can't spot an issue here or there then you are probably just not skilled enough to see the defects. I'm not talking about some 'forget the code, WE ARE SHIPPING THE PRODUCT HERE, BEATCH!' management bullshit. The beautiful code and design is what makes your product easy to maintain and improve in the long run. The more skilled and experienced you become, the more likely you are to fall into "disappointed in everything" mental trap. Try to think about it rationally - you've been around for quite some time, you've built some great stuff, your projects haven't fallen apart due to awful technical decisions. And though your code sucks from your point of view, perhaps it's not that bad on the absolute scale of code awesomeness. What can we do make it less painful? Code review really helps a lot. Some developers complain about code review not being effective enough, i.e. it only helps you find the most basic formatting and code issues. I was a bit skeptical myself not so long time ago, but even if it helps to fix the formatting and minor code issues, than it's a great improvement! I would say it's a matter of trying and figuring out for yourself. From ## When do you know, how much testing is enough? DevFeed: [When do you know, how much testing is enough?]() Original publisher: [Read original article]() Author: vivek Published: 2012-05-21T11:56:43Z Content type: opinion Language: en Sources: [Finn.no]() Topics: [Testing](), [test]() Tags: [bugs](), [defects](), [deployment](), [developers](), [quality](), [release](), [signal](), [testing](), [tests]() ### AI overview The article discusses how to judge whether testing is sufficient before release. It recommends continuing to test when defects are found or important functionality has received little coverage, while stopping may be reasonable when sustained testing of a particular area finds no new defects. It warns that untested features and confidence based only on successful compilation can create false confidence. ### Source excerpt Let me begin with an example, from every days scenario at work. You are at the end of the sprint and have some errors reported. You think that the quality of code and tests are good enough for release. Based on this the reported bugs the failures are minor and won't have big impact after fixing them. But the reality may be different, that you really are on opposite ends of the quality. The code and test quality is low, and the reported tests are few or no bugs. Your worst case scenario could be that deployment/release will go very bad and can be very expensive in a technical or business nature. It's important to evaluate the possibility of finding more defects based on results you have gathered so far. The key is to analyze your rapport thoroughly because: If you have just found a defect, this is a signal to keep testing. It may seem counter-intuitive but in general the more defects you find the more likely it is that there are additional defects. If you have only exercised a small portion of the overall functionality and have found defects, then this is a signal to continue testing. If you have been testing a particular piece of functionality for a while and are not finding any new defects, then this is a signal for you to stop testing. How much of the system's functionality have you tested? If there are significant features that are mostly or entirely not tested, then you will likely not be prepared to recommend it is good to go. False confidence is a very real danger. This is especially true for developers. I have seen or heard of many who have an unrealistically high level of confidence that their code works, in some cases without any testing whatsoever. As a specific example, I have heard developers state that if their code compiles, it is good enough to be promoted to acceptance testing. Testing by definition is comparing an expected result to an observed result. So it should be easy to answer the question how much testing is enough? But the answer could be ba ## Why Zero-Defect Goals Are Unrealistic in Software Development DevFeed: [Why Zero-Defect Goals Are Unrealistic in Software Development]() Original publisher: [Read original article]() Published: 2009-03-19T15:41:57Z Content type: opinion Language: en Sources: [Blog by Michael Dubakov]() Topics: [Software Engineering](), [Development](), [bug](), [Test-driven development](), [unit tests]() Tags: [bug](), [defects](), [refactor](), [software-development](), [tdd](), [unit-tests]() ### AI overview The article argues that a zero-defects mentality can suppress initiative, discourage refactoring, and encourage risk-averse decisions. Because software is difficult to test and predict, production bugs cannot be eliminated entirely, though development practices such as Test Driven Development and unit testing can help minimize them. ### Source excerpt Are you familiar with zero defects mentality? It looks very good from the first sight. Zero defects... Let me think... Well, cool! I like it! I'd like to have zero defects in my projects. So, what is zero defects mentality? Here is the quote from Lean Software Development an Agile Toolkit book: "One of the fastest ways to kill motivation is what is called in the US Army a zero defects mentality. A zero defects mentality is an atmosphere that tolerates absolutely no mistakes; perfection is required down to the smallest detail. The army considers a zero defects mentality to be a serious leadership problem, because it kills the initiative necessary for success on a battlefield" -- Mary & Tom Poppendieck Obviously, zero defects mentality is not something that HOUSE M.D. likes ;) Moreover, I think Dr. House hates zero defects mentality. It causes several unpleasant effects: Not enough courage to refactor complex, messy, buggy, but important piece of code. Can't make important decision, instead make less risky, but wrong decision. Do everything to avoid responsibility, that leads to coward and stupid behavior. "Zero defects" may sound good. But in reality you still have errors after production. Even in predictable and (quite) easily testable industries (hardware, automobile, etc.) there are problems with 100,000 power adapters that should be replaced (or hard drive problems, or engine problems, I bet you can continue the list). How can we expect zero defects in software development? It is harder to test, harder to define in details, harder to predict. Software development is a complex adaptive system, we can't predict all effects. Bugs in production is a normal thing, and by "normal" I mean we can't bring them to zero. We can (and should) minimize them using all possible ways, but The Last Bug is a mirage. There are several obvious strategies that may help: Test Driven Development. Nice side effect of TDD is a unit tests suite. You have tests for new code, and you have unit te