The Lewin's change model theory: The Angular style guide usecase

Image of the author

Gerome Grignon

There is no secret: our first reaction towards change is to resist it. Habits are hard to break: they are comfortable and make you feel secure at using them.

That’s a real challenge for companies to gather their employees when changes have to happen. It might be small changes, like a new tool, or a new process, or a new way of working. But it might be big changes also, the ones impact the way you work in a big way.

When it happens, managers can be tempted to use the “Lewin’s style guide” to help their employees and ensure changes are not only accepted but also adopted, moving from the first rejection, to understanding and valuing the change.

I happened to use it ten years ago as a manager as the company was dramatically changing its way of working:

What is the Lewin’s change model theory?

Lewin’s change model theory is a set of guidelines that help you to adopt a new way of working.

It’s based on 3 stages to achieve the adoption of a new way of working:

  1. Unfreezing: the process of breaking down the current state of the organization to make room for the new way of working.
  2. Changing: the process of implementing the new way of working.
  3. Refreezing: the process of solidifying the new way of working and making it stick.

The Angular style guide usecase

The Angular team lately updated their style guide, reviewing the old version and making it more aligned with the latest updates of the framework.

One major change is impacting the Angular CLI: Angular is quite well-known for providing commands to generate components, services, pipes, etc. Not only it creates a dedicated boilerplate for each of them but suffix their file and class names with the related type.

By running ng generate component home, you’ll get a new component called HomeComponent in a home.component.ts file. Or at least it was the behavior before Angular 20 release.

Part of the new style guide is to recommend not using suffixes anymore. The motivation of this change is to encourage developers to use more meaningful names for their components, services and directives. Rather than having a HomeComponent in a home.component.ts file, you should create a home-page.ts file with a HomePage class. Rather than having a ProductService in a product.service.ts file, you should create a product-api.ts file with a ProductsApi class.

The Angular team not only recommends this change as new projects starting with Angular 20 do not generate the suffixes anymore.

The unfreezing phase

How is it a big change for Angular projects?

Part of the unfreezing phase was the RFC discussion on the Angular GitHub repository. Other parts are private ones, where the Angular team gathered feedback from different other sources.

Not focused on this change exclusively, the goal was to gather community comments about the new style guide. While the discussion got a lot of positive reactions, a lot of concerns were raised about the naming convention once shared on social medias.

A truly abhorrent addition nobody asked for. I don't see why they want to reinvent the wheel it risks breaking the uniformity we've relied on for years this just seems like someone's opinion rather than an actual improvement A little unnecessary, but ok hahaha It seems like overengineering! Bring it back. I think this is a step backward This change by Angular community was not needed at all

Remember about the rejection phase?

Based on community feedback, we retrieve the feeling of a new change impacting the way we work, and saw in a negative way. Rejection is enforced when the change is not explained clearly:

looks like changes for changes with no values Can someone explain how v20 naming convention is good?

That’s the key point of the unfreezing phase: you need to explain the change in a way that is easy to understand and that is not seen as a negative change. And such an action should start before the change is implemented.

The Angular team started by explaining the motivation of the change in the RFC discussion but leading to more confusion as either stating:

The changing phase

The changing phase is not meant to always happen as a one-shot action. It’s a process that can use an agile and interactive approch to incorporates the feedback of the community.

That’s what the Angular team started by only updating the tutorials part of their official documentation so far. That’s a good idea but implemented in an incompleted and wrong way:

The incomplete implementation

You’ll find me looking at details but the tutorials are not only text but videos too. If we all know how hard it can be to update video learning content to keep it up to date, that’s some consideration which should no matter for a new user. When an experience start with confusion, that’s a bad experience.

The second issue with the incomplete implementation is not providing explanation about the change: as part of the tutorials, there are links towards other parts of the documentation. These pages are still using the old way. A banner would help to provide some guidance about the current state of the documentation.

the wrong way

While the Angular team encourages the use of the new naming convention, it’s poorly demonstrated in the tutorials.

An example is the ‘housing location’ feature. It both refers to a Component and a DTO. That’s current the main concern of devs: how to resolve the situation when the term was used both for a component and a DTO:

If we remove the Component suffix, both use the same name: HousingLocation.

The way the Angular team changed it not only deny using more meaningful names but also provide a code most people see as made by a junior and would not approve a related PR:

Part of common recommandations were always been not to sufffix DTO with terms such as Info, Model, Data, etc.

But the worst part might be file name changes:

The refreezing phase

The refreezing phase is the last phase of the Lewin’s change model theory. It’s the process of solidifying the new way of working and making it stick.

By updating the CLI behavior for any new project, the Angular team has already been solidifying the new way of working. But such a change is meant to happen when the change is adopted and properly introduced to any beginner.

However the developer experience for a beginner is still confusing:

The last part can sound the beginner responsibility to learn through official docs but the honest reality is a lot of people learn from community content.

Conclusion

The change is a good idea but it needs guidance and proper implementation. Part of chaos inside React projects is the lack of guidance and the Angular CLI has always been a great tool to enforce basic structures.