Category: Engineering

As engineers, we constantly grapple with the challenge of creating solutions that are efficient, scalable, and maintainable. A key aspect that can make or break our projects is the ability to establish a common understanding among team members. In any team, individuals possess varying mental models, skills, and experiences, leading them to arrive at different abstractions. These divergent abstractions may introduce misunderstandings and hinder effective collaboration. Abstraction serves as a bridge that enables team members to navigate the diverse mental models that shape their perceptions of concepts.

Each team member arrives to a different abstraction (A, B, C, D) from entirely different angles.
The goal is to get everyone to arrive to a common abstract understanding (△). Use that to drive the conversation and problem solving, then approach the concrete solution (E) from the same starting point.

Example

Software architect working with a team of four on a complex problem. The four people think about the problem and the solution in different ways:
(A) Component model diagram in LucidChart
(B) Class model diagram using UML
(C) Pseudo code
(D) JavaScript playground on codepen.io

Led by the architect, eventually the team arrives to a common, abstract view (△) – a one-pager annotated diagram using C4 in Mermaid.

Team builds a web app (E) on the MEVN stack, arriving to the concrete implementation.

Conclusion

The ultimate goal of achieving a common abstract understanding is not to suppress individual creativity or to homogenize approaches. It creates a harmonious collaboration environment where everyone’s insights are valued and leveraged. Additionally, it fosters a sense of collective ownership and responsibility for the project. Rather than working in isolation, team members become invested in the overall success of the solution. It promotes clarity in requirements interpretation, reducing the likelihood of misunderstandings and rework.

As a result, the team’s productivity improves.

Abstraction is a recurring theme in my work.
While it is second nature for some, most folks have too strong of a footing in concrete 😀

Everybody can do abstraction. It is a skill, it is a mental muscle that needs training. Applying it regularly to situations and using it purposefully is a different matter. A short, visual explanation on what I mean by applying abstraction purposefully.

1. The arrow pointing away from concrete indicates the idea of abstracting away. The further we are, the more abstract the concept becomes.
   Arrows shooting out to different directions signifies that abstraction can happen along many different aspects.
2. The arrow pointing towards the centre indicates reducing abstraction. The closer we are to the centre, the more concrete it gets.
3. Exploring other aspects while remaining on the same level of abstraction.
4. Starting from something concrete and walking thorough levels of abstraction before descending back does not necessarily arrive to the same concrete point.

The irony of explaining abstraction in an abstract manner is not lost on me. Future posts will include more concrete and practical points.

Example

• You are the software architect working with a team of four on a complex problem.
• The 4 people think about the problem and the solution in different ways
  A. Component model diagram in LucidChart
  B. Object-oriented class model diagram using UML
  C. Object-oriented pseudo code
  D. JavaScript playground on codepen.io
• Eventually the team arrives to a common, abstract view
  △ One-pager annotated diagram using C4 in Mermaid
• Implementing the solution
  E. Building a web app on the MEVN stack