Testing and the Project Singularity

In mathematics, a singularity refers to a point that is basically undefined because it is infinite or what is known as degenerate. In physics, a singularity is a “region” that has infinite density with an infinitesimal volume. So what does this extreme concept have to do with testing? Well, let’s talk about that.

Okay, so singularities. Nifty things.

In that image, the singularity would the dot at the center of the funnel and while the dot seems to have extent that’s just an artifact of the drawing. By the definitions given, singularities can’t be measured. They do, however, transform anything measurable that passes through them. When testing is taken as a social discipline and a truth-preserving mechanism I think this has an interesting corollary with the idea of the singularity and my previous thoughts on the character of projects.

But what are the two sides of that “funnel” there? That would be past and future. Here’s a common physics conception of the same thing:

The past and the future are two of the most prominent polarities that we shift between. But that project singularity changes everything.

So I’m going to go on a bit of an analogy rant here. Some of the following analogy is very much one from John Gaddis that I am appropriating here because I think it’s so well considered. My contribution to this analogy is how “project time” itself forms a natural singularity about which our projects must pass through. In doing so, these projects are transformed. That transformation takes place over a smeared out moment of “now”, where “now” becomes a duration that is measured in terms of sprints or whatever else we call our discrete project activities. Stretching this analogy to what is no doubt its breaking point, I also want to visualize how our projects can become pathological in this context.

The Duration of “Now”

In the character of projects I talked about how the notion of “now” is not really a moment in time for us:

The ephemeral moment of “now” is when everything is actionable for us. Here “now” is a duration that comes into being and persists for a project.

The “present” is thus a temporal spread. Our singularity is thus a bit smeared out. Part of why I said “agile” and “waterfall” were irrelevant in that prior post was because they don’t at all deal with the consequences of the temporal spread. But I will say that I think “agile” has the better focus, which is keeping the “now duration” as small as possible. If we keep our singularity from smearing out too much, we get this:

But if the “now duration” is allowed to become longer and longer, the singularity of our project smears out more and more:

The more smeared out the singularity, the greater the transformation process that takes place. In the interesting book Time, Continuity, and Indeterminancy, Sandra Rosenthal says:

“The ‘cut’ of the present contains past and future because it contains the continuities or possibilities that extend into the future.”

I like that notion of continuities so let’s stick with that a bit.

Continuities and Contingencies

Since our projects are essentially reflections of life, let’s consider that within our projects, just as within life, there are continuities and there are contingencies.

  • Continuities refer to patterns that persist and extend across some amount of time. These are events that recur with sufficient regularity to make themselves apparent to us. Our ability to generalize comes from continuities.
  • Contingencies refer to events that do not form patterns. These events don’t fall within the realm of repeated experience, at least so far as we can tell. We generally learn about these, and reason about them, only after they’ve happened.

In Tacit and Explicit Knowledge, Harry Collins discusses what he calls “contingent tacit knowledge,” which refers to, as Collins describes it, the “contingencies of social life.” That resonated with me because remember that I fully believe testing is, first and foremost, a social discipline. Thus testing, as an activity, should focus on the “social life” of our projects. But those projects are going to have contingencies as well as continuities.

So now think of the present moment — but the “smeared out” present moment that I’m referring to — as a singularity through which the future has to go through in order to become the past.

Here’s where we tie the ideas together. The present achieves its transformation by locking into place the relationships between the continuities and the contingencies. As Gaddis says (in The Landscape of History):

“On the future side of the singularity, these are fluid, decoupled, and therefore indeterminate; however, as they pass through it they fuse and can’t then be separated.”

A key point here is that in the future, the contingencies and continuities coexist independently of one another. The past, however, is where their relationship is fixed. The present is the singularity that brings the two together. This means that continuities intersect with contingencies, contingencies run up against continuities. Ultimately this is the process by which what we call “history” is made.

Everything is the Past

As I said in the shifting polarities, everything we rely on is in the past. Our emphasis is ultimately on the history of our projects. It is the history that contains the actions we took and the artifacts we produced. That means we are mainly dealing with where the relationship between contingencies and continuities are fixed.

Okay, yeah … so what? I mean, what’s that really saying? Well, let’s state the obvious here: the trouble with the future is that it’s so much less knowable than the past. Because the future lies on the other side of the singularity that is the “now duration”, all we can count on is that certain continuities from the past will extend into it. We can also count on the fact that those continuities are going to run into uncertain contingencies.

Now, some continuities will be sufficiently anti-fragile that contingencies will not deflect them. But the “problem” is that our projects have a human component at all times. And, as we know, when it comes to actions people themselves choose to take — in other words, when consciousness and sapience are one of the primary contingencies — forecasting and planning becomes a far more problematic activity.

Likewise, however, details about the past can also be less knowable in many ways. Remember the singularity transforms everything that passes through it. This means distortion is is inevitably made. Micro-decisions made and rationales promoted are subsumed by the artifacts that get left behind. We tend to reason about those artifacts more than we do the human reasoning processes that produced them.

Visualizing Project Pathologies

I won’t dig too deep into this point because my thoughts are still percolating. But I do think this focus on the artifacts rather than on the means of production is akin to how we might focus on the structures of history rather than the forces that created the structures. This can lead to certain project pathologies and, again, this can happen in agile, waterfall or any variation thereof.

Here’s one:

Consider the “tube” you saw in my first visual for this article. Here the tube gets twisted back, not so much on itself, but rather on the “consistency” we have on our projects. It’s a feedback loop but, in this case, it’s a loop that lets nothing else in. This is like when we keep using the same artifacts, often incurring the same technical debt (however you choose to define that) and thus our projects look like this: a loop of activity that ultimately keeps us in the same state.

Here’s another:

Here is a variation on the previous, where the tube is ultimately twisted back on itself. This it the pathology where, on our projects, we simply don’t learn. We’re on a sort of treadmill. The bigger the loop, the less we realize we are on a treadmill.

Here’s one more:

This is where our tubes lead us into islands of sophistication and reservoirs of knowledge. This means that our discoverability is ultimately compromised because it’s reliant on these localized distributions of information, artifact and knowledge. Everything is potentially knowable, of course, but the reality is that as the “bubbles” grow, it becomes more and more difficult to effectively share information.

I realize these may seem like a pathetic attempt to stick to my theme, treating singularities as a project pathology. As I said, thoughts are still percolating.

Reasoning in the Present

Here’s another aspect that I want to investigate more. As in historical studies, having direct experiences of an event or a time are not necessarily the best path to understanding them. This is because when we are directly experiencing an event, our field of vision tends to extend only out to what is necessary for our most immediate senses to function.

So, as an example, in the thick of encoding a business domain as tests for a particular feature in a given sprint, we often can’t do the one thing we need to do, which is reason about the entirety of the system. And, likewise, as a discipline, testing and quality assurance, rarely look back on themselves with a wide-angles lens.

This means, to me, a component of a quality assurance function is having at least some people who are not mired in any sprint. They are aware of it, certainly. But they are an architect of history which means making sure that the truth-preserving mechanism of testing does, in fact, preserve through the singularity.

I want to drill this point home a bit more. If we have detachment from, and consequent elevation above, something this means we get a departure from the immediate. This can provide us with a new perception on what we do, how we do it, and so on. An elevation that provides a shift in perspective tends to enlarge our experience.

In my post talking about how testing is like cartography, I mentioned that

Maps thus serve as a way to package up a vicarious experience by providing a representation.

When we perform an act of representation, this can lift us above the familiar and the immediate to let us experience vicariously what we can no longer experience directly: a wider view. We can’t reclaim the time when the decisions were made on our projects. But we can create representations of those decisions and come to a historical understanding of why and how they were made. This is, in part, the truth-preserving aspect of testing that I believe must be encouraged more. Concepts like BDD, with copious feature files based on communication, may be seen as trying to provide this but, in fact, the opposite is true — or so I would argue.

What most of our “methodologies” (i.e., agile) or our “processes” (i.e., BDD) are simply encouraging tradition: a streamlined means of how to act on projects. Far from enlarging our experiences, I believe these things constrain them.

Representation and Abstraction

I have said, in various contexts, that one of the key skills for testers is choosing the right abstractions to work with. See the following, if curious:

I point those out because they are examples where my own thinking was — maybe — on the right track but too focused on limited contexts.

A purpose of representation is distillation: you want to package up a large body of information into a compact usable form so that someone can, ultimately, reason about and make decisions about things using that information. So part of what my test artifacts do is distill the micro-decisions and rationale that went into the creation of a given feature; they provide a context into how that feature sits relative to other features.

What you are doing is offering a compression of historical experience that can vicariously enlarge personal experience. It’s a way of recovering information that passed through the project singularity.

In terms of harnessing those continuities mentioned earlier, the idea of abstraction is a separation from context and this is what can make generalizations hold up over time. This is pretty much the idea of choosing the appropriate abstractions in testing. Or it’s pretty much that idea if you view testing as primarily a social discipline that puts emphasis on the means by which a culture makes decisions, implements those decisions as artifacts, and then encodes relevant information for historical discovery.

Abstraction and Liberation

It’s important to keep in mind that abstraction arose as a form of liberation. Abstraction, in both art and science, was a way to provide a new view of reality that put an emphasis on the flow of time. That process works, though, by distorting space. This means we end up with compressions and distillations of thought and experience. This is what I believe we do in testing as well, both as a social discipline and as a truth-preserving mechanism: we use compressions and distillations of the past in order to make it usable in the future. This is another example of moving between polarities.

But this means there is always a tension between the literal and the abstract, between the detailed depiction of what lies at some point in the past, on the one hand, and sweeping sketch of what extends over long stretches of it, on the other. Thus we find ourselves facing other polarities: that between generalization and particularization as well as the gap between the abstract and literal representation.

So I’ll close here with something I said in testing and the human element of history:

I do believe that testing is about moving between polarities of thought. I believe this is what, as a whole, our discipline is in danger of not doing as we fall prey to the technocrats, the complex methodologists, and the “guiding” hand of technological sophistication rather than the nuance, and uncertainty and messiness, of human reason and communication.

I believe this more than ever and I’m on a quest to tie the idea of polarities to the idea of the social discipline and truth-preserving mechanism of testing.


This article was written by Jeff Nyman

Anything I put here is an approximation of the truth. You're getting a particular view of myself ... and it's the view I'm choosing to present to you. If you've never met me before in person, please realize I'm not the same in person as I am in writing. That's because I can only put part of myself down into words. If you have met me before in person then I'd ask you to consider that the view you've formed that way and the view you come to by reading what I say here may, in fact, both be true. I'd advise that you not automatically discard either viewpoint when they conflict or accept either as truth when they agree.

2 thoughts on “Testing and the Project Singularity”

  1. Thank you for sharing your fascinating thoughts on testing. I’d like to offer you critique of your thoughts here. Not to tell you you are wrong, but to inspire you to think about whether the premises of your thinking are correct. I cannot judge your thinking, as logically you are correct, but I can offer you a different perspective.

    And I do see a problem in the way you work.

    You correctly identify testing as a social activity.

    But by starting out with theories of time, space, and matter, your thinking is limited, and accidentially, you reduce the social in the activity to a question of cause and effect with random input. This quote is particularly revealing:

    But the “problem” is that our projects have a human component at all times.

    Let me ask you the following two questions:

    Are the human components not in fact the only anti-fragile component in projects?
    Do continuities not only happen because of the human components?

    Again: Thank you for sharing your fascinating thoughts and allowing us to comment. Happy thinking!


    1. I appreciate and desire critique!

      Regarding that quote, note that I put the word “problem” itself in quotes. What I didn’t do is properly indicate that this was sometimes how people looked at things: “people are the problem.”

      But it is also true to say that when you add in the free will of human agents, projects (of course, right?) become more complicated. That’s why, ultimately, our projects are not just reductionist exercises wherein you can look at the sum of the parts and work the project as you would, say, solve an equation.

      So — in short — you raise an excellent point. I presented my thinking there in a shallow way. And I have to ask myself if that’s because my thinking is shallow in that context. I will investigate this. Let’s take a stab at your questions.

      Are the human components not in fact the only anti-fragile component in projects?

      I’m still parsing Nassim Taleb’s book Antifragile so my thoughts are very in flux, thus I hesitate to pontificate too much. What I can say I believe is that many things can be anti-fragile. But do they come down to humans ultimately? Let’s consider “faith” as an example.

      I would argue that anyone’s faith that can be crushed by some questioning — even hard questioning — is not much of a faith. But notice it’s not the “faith that is antifragile.” It’s the network of associations, arguments, and concepts that operate in human minds that can lend a notion of antifragility to the concept of that person’s individual faith.

      But humans can build systems that are antifragile outside of their thoughts about those systems. I can work with people to build software infrastructures that are potentially antifragile.

      I’m not sure if I’m responding to your question well but I appreciate that it’s giving me something to think about further.

      Do continuities not only happen because of the human components?

      Excellent question. So in an article I just published today (this one), the continuities that we have in the past are the structures that have survived. Those were created with some processes and, in the context of our projects, yes — that would be because of humans. Unless software starts writing itself. In other disciplines — like geology, for example — this is not the case. Operative processes in nature — without human intervention — could have left structures.

      Consider our source code. That’s a continuity. But it got there by humans. Consider the “agile approach” we used as a team to create some software. That approach — the way we incremented and iterated — left structures, including memories. But, again, without humans in the mix, what would we have ended up with?

      So — responding to those human aspects — there is nothing (in my mind) wrong with the notion of humans being “problematic” in that this doesn’t have to be a bad thing or a good thing. It simply is. Humans are complicated. Things we deal with become complicated because we apply our own values, thoughts, desires, biases and so on to those things.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.