Drill down on semantics and rhetoric, as software development is not an exact science like physics. Find out what the context and meaning behind the group talk between the stakeholders is based on. Do they understand the terms the same way? Are we aligned with today’s priorities? What are we trying to do and why? Breaking down ambiguity is our main game and moves the needle in myriad ways.
Words and concepts can have surprising interpretations despite everyone in the group being assured they share a similar understanding. Often, teams think the context is “obvious” or that they are dealing with axiomatic concepts. However, when asked by 5 random software engineers what agile means, you will get 5 different answers based on their background.
Once, I was working on a graphics framework with a team of 3. There were many unknowns, as none of us had created such a framework from scratch. Over the span of a few meetings, I suggested creating prototypes and demos because that is how I like to evaluate things. We did some demos, but the prototyping eluded the other two. They were adamant: “Just implement it in the main code base. It’s easy”. Instead of incremental evaluations, we ended up dealing with unnecessary merge conflicts and work that wasn’t peer-reviewed. I learned too late that they thought I was talking about product prototypes, alpha-versions, or MVPs. We were apparently too hung up on the semantics of “prototyping” that the reasoning I provided did not reveal the misunderstanding.
Questions sometimes annoy people. Asking them is essential for meaningful work and to prevent regressions. It takes skill to construct the question so that the one asking it is not seen as ignorant, incompetent, or even just antagonising. Software engineering is presumed to be standardised: they have the same degrees, they do the same line of work, they deal with the same concepts – why do we have to play Socrates and ask for definitions and bicker about semantics?
I would argue that in software engineering, there is a subdomain that assumes it can exercise exact science. Probably due to computer science being related to STEM, implying that software engineering could be included in STEM by proxy. But software engineering is a discipline, not a science. Some would argue that software engineers are not even “engineers” because they don’t build bridges or make rockets fly. I don’t think the totality of a discipline should be compressed into the pinnacle of its representative fields. The definition that resonates with me is that engineering is a discipline that applies the scientific method to solve problems.
And, before problems, engineering solves ambiguity first. Working to solve ambiguity comes across, for example, in these cliches in software:
- Exhibit A: “Break down large problems into smaller ones until they become near trivial”.
- Exhibit B: “It depends – what are you trying to do?”
- Exhibit C: “Gun to your head, you have 24 hours to fix it, how would you do it?”
However, despite being experts at making things unambiguous, we have blind spots for the language we use, which is often riddled with ambiguities.
Meanwhile, outside of STEM, the humanities work to precisely define and further refine their concepts as they research fuzzy life observations in the spirit of the scientific method. That practice could bring clarity to software engineering. We could also try to define and further refine the concepts we use. My colleague at work aptly pointed out that the blogosphere is riddled with people renaming things, sometimes reusing defined concepts for unrelated ones. Exhibit D: “Agents”.
We should stop to question the semantics if something seems amiss. Usually, there are signs that things are ambiguous or misunderstood. For example, when there are moments of confusion, mistrust, and contradictory statements or actions, one should start asking questions and sifting to spot out unfitting language. The way we use terms and jargon in software is rife with ambiguity, leading engineers to gradually become “a person who asks stupid questions with authority and purpose” – someone who drills to the core when others can’t or won’t – addressing the social complexity before the technical complexity.
I think we should acknowledge that software engineering is engineering in the sense that it’s based on logic, but it also deals a lot with hermeneutics. It has real rigour in some contexts but lacks it in others. We could learn from humanism and probe our understanding on several levels to improve the hygiene in our communication, as well as, albeit indirectly, improving empathy by understanding others.