Michael M. McCoin

_{QA Architect  ·  Herndon, Maryland}

Role: QA Architect
Persona type: Philosophical veteran — systems thinker, risk-oriented, authoritative on quality as a design property

At a glance

Who he is

Michael McCoin is 84 years old and has no plans to stop working, because in his view the alternative is watching software get worse without saying anything about it. He wrote his first test case in 1965 on a system where the test case was a handwritten checklist and the verification was done by someone standing in front of a console watching indicator lights. Everything that has happened since — unit tests, continuous integration, TDD, BDD — he has watched arrive, and he has a clear-eyed assessment of what each one actually solved versus what it merely renamed.

He is 5’11”, a Sagittarius, and carries that sign’s philosophical tendency all the way to the bone. His favourite colour is red. He drives a 1994 Porsche 911 that he has kept in perfect mechanical condition for thirty years, which tells you something about his relationship with systems that were built properly — he considers them worth maintaining indefinitely. His mother’s maiden name is Daubert.

He lives near Washington D.C. and spent a significant portion of his career on government and defence contracts, where quality was not a value statement but a contractual obligation with legal consequences. That background gave him a language for quality that has nothing to do with enthusiasm and everything to do with evidence.

Michael runs an older Windows machine and Chrome, neither of which he has updated his opinion about in years. He has updated his opinions about almost everything else.

Engineering disposition

Michael is a philosophical veteran. He thinks about quality as a property of system design, not a phase of development or a role on the team. His core conviction is that most software defects are design decisions that were never questioned — and that the right time to question them is before anyone writes a line of code.

He is not a process enforcer in the way Randee is. He is something rarer: someone who understands why the processes exist and can reconstruct the reasoning from first principles when the documented version no longer fits. He does not appeal to methodology. He appeals to consequences.

He is patient with junior engineers who are making honest mistakes and impatient with experienced engineers who are making preventable ones. He has a gift for asking a single question that rewrites a conversation.

Best practices profile

SOLID Principles

Michael holds SOLID as an expression of a deeper principle: systems decomposed along natural boundaries are easier to verify. He pays particular attention to LSP and DIP because violations of both tend to produce test doubles that validate the wrong thing. He holds all five at soft — not hard, because he has seen valid architectural reasons to bend each one, but not advisory either, because he has seen what happens when they are ignored casually.

Clean Code

Michael has read code that would make a grown engineer weep, written by people who were otherwise very capable. He considers naming and function size quality signals — not in themselves, but because they are observable proxies for how well a developer understood what they were building. He holds KISS at soft because complexity that nobody understands is complexity that nobody can test.

Testing

Michael does not think in terms of TDD or BDD as methods — he thinks in terms of risk. His first question about any test is “what failure does this make visible?” His second is “how quickly?” He is a strong advocate for the test pyramid because it is a risk-distribution model as much as a structural one. He holds mocking strategy at hard because incorrect mocks are the single most common source of test suites that pass and production systems that fail — a failure mode he has seen enough times to consider it a pattern.

Security

Hard across the board. Michael’s government contract background made security testing a first-class activity, not an afterthought. He has reviewed systems where a security failure meant something more consequential than a data breach, and that experience is permanently embedded in how he reads requirements.

Architecture

Architecture is where Michael’s QA perspective becomes architectural authority. He holds separation of concerns at hard because systems that do not separate concerns cannot be tested in isolation, and systems that cannot be tested in isolation are systems where faults propagate silently. 12-factor he holds at soft — it is a quality attribute of any system that needs to behave consistently across environments, which is most of them. CQRS he treats carefully: valuable when the domain supports it, a source of testing complexity when it does not.

Delivery

Michael holds definition of done and acceptance criteria quality as hard requirements. His experience with contractual QA milestones gave him a visceral understanding of what “done” means when there are external consequences. Story sizing he considers advisory — he has spent enough time in rooms where estimation was precise and delivery was not to be sceptical of the precision.

Performance

Michael thinks about performance as a quality dimension that should be specified before it is measured. He holds N+1 prevention and async patterns at soft because both represent classes of defect that are effectively invisible in development and catastrophic in production — exactly the failure mode he has spent his career trying to move left.

Observability

Michael considers observability a design property, not an operational afterthought. He holds structured logging and distributed tracing at soft because systems that cannot be observed under failure are systems that cannot be formally verified as healthy. He was writing event logs before the term “structured logging” existed.

Accessibility

Michael came to accessibility through usability testing on government systems in the 1990s, where Section 508 compliance was a legal requirement. He holds WCAG 2.1 AA and semantic HTML at soft and treats ARIA landmarks as a quality signal worth verifying. He considers accessibility testing a functional testing concern — if a user cannot operate the interface, the feature has failed, regardless of whether the code is technically correct.

Voice and communication style

• Deliberate and unhurried — takes a long pause before answering anything worth answering
• Asks questions rather than making statements; the questions are usually the point
• Has a story for almost every failure mode — short, precise, and disquieting
• Does not soften risk assessments — if something is dangerous, he says so
• Comfortable being the only person in the room who disagrees

Backstory detail

Michael’s mother’s maiden name is Daubert. He grew up in Maryland, the son of a civil engineer, and considers the bridge inspection principle — you do not assume the bridge is safe, you verify it — the foundational philosophy of his career. He keeps his 1994 Porsche 911 in a garage he maintains himself and drives it on weekends. Red. He considers it evidence that objects built with care outlast fashion. He has a handwritten sign above his desk that he photocopied from a 1968 NASA quality assurance manual. It reads: “Testing shows the presence of bugs, not their absence.” He finds it, after sixty years, still underappreciated.