Structure is workflow, workflow is structure

Nearly 5 years ago, I was hired in a pre-seed startup as lead developer/hands-on CTO.

My first task was to hire a frontend developer as my frontend skills were limited, while they would a high pressure to have a custom UI.

In the interviews I gave, on a simple shared document, I asked my favorite interview request: design me a rectangle and a square.

Every-time, I was getting a variation of the following snippet:

class Rectangle {
  public constructor(protected readonly width: number, protected readonly height: number) {}
}

class Square extends Rectangle {
  public constructor(width: number) {
    super(width, width);
  }
}

The aim of this request is not only evaluate the knowledge of software engineering and design principle of the applicants, but also their ability to take a step back.

This snippet is wrong, at all levels.

On a purely technical level, from an object-oriented programming (OOP), it does not respect Liskov substitution principle (LSP), from the SOLID principles, which are the cornerstones of OOP. It is true that, in mathematics, a square is a rectangle which have its width equals to its height, but, with inheritance, we loose the ability for a rectangle to have its width and height changed independently.

I could have accepted a square being a consumer of a rectangle as follows:

class Square {
  private readonly rectangle: Rectangle;
  public constructor(width: number) {
    this.rectangle = new Rectangle(width, width);
  }
}

This is actually a technical detail, the real issue was the inability to take a step back.

All the applicants focused on the data model, assuming that we would need the size of these shapes, while I could want things like a price, a quantity, a position, a color, etc.

Beyond that, it is also, in my opinion, the result of conditioning and education.

I vividly remind my lessons of database and data modeling during my technical, engineering and master degrees, but no behavior or workflow modeling (I had one of workflow analysis).

Worse, during my studies, one of my girlfriend was studying to be a hospital director, and she had lessons in "database modeling" (they called it like that, I was not able to help her with her homework as there was few overlap with my lessons on database modeling).

Note: when I have discovered that non-IT-related had lessons to help them to understand what we are doing, I realized that our industry completely lost touch with the rest of the world we are supposed to help.

Back to my request, the only valid answer I expect is: what will we do with them?

Data-modeling is a side effect of behavior modeling.

Of course, there are times when we have some mandatory information to design as such (e.g. invoices should have an amount, a sender, a recipient, etc.), but, most of the time, stakeholders focus on constraining the data-modeling, preventing leveraging other techniques such as event-sourcing and trapping the behavior design.

Focusing on behavior rather than the data has also the benefit of allowing us to rely on what things are doing, instead of what hey are.

For instance, let us say, I want to build a Candy Crush Saga-like, but, beyond item-types, we gain extra points when they are representing some shapes.

Instead of having a hard-coded type name as follows:

class Square {
  public scoreFactor(items: Item[]): number | null {
    if (items.every((item) => item.isSimilarTo(tems[0])))
      return 10;

    return null;
  }
}

To a version relying only on the required operations declare in an interface as follows:

class Square {
  public scoreFactor<Type extends Comparable>(items: Type[]): number | null {
    if (items.every((item) => item.isSimilarTo(tems[0])))
      return 10;

    return null;
  }
}

In OOP it is referred as interface segregation principle (ISP).

If we take a step back, in modern programming paradigms, data are not emphasized.

• OOP is defined as behaviors with and encapsulated state, communication between objects (messages) are driving the design
• FP (functional programming) as described originally by Alonzo Church only had functions definition and application

Even in today's architectures and patterns such as event-sourcing, most of the valuable information does not come from the data-modeling, but from the events, the workflow, designed and actual.

The workflow defines the structure of the system, and this structure becomes the system's workflow.