Don’t Repeat Yourself… but just a little bit anyway
It’s better to have a little intentional duplication than premature abstraction that mixes business rules that have no business being together.
Posts tagged “Craftsmanship”
LLMs: You’ve become a manager, whether you like it or not
Coding with an LLM is like managing a team: you have to balance delegation and move forward in small steps.
Bug, error, or nominal case: what is the business intent?
When should you throw an exception, return an error, or model the absence of an error? The answer lies in the business intent.
Design tokens: the grammar of your Design System
Before components, tokens. How to structure a coherent Design System using a well-thought-out token architecture.
Hexagonal Architecture: Do We Still Need an ORM?
An ORM lets you build the domain on entities it exposes, which are directly mapped to the database. This is the opposite of Hexagonal Architecture.
What if your TypeScript model prevented inconsistent states?
TypeScript is often used only superficially. This is particularly true for Union Types, which help prevent inconsistent states.
You’re using exceptions incorrectly
Exceptions are not meant to handle predictable errors. Discover the Result type, an alternative to try/catch.
Testing Randomness: A Textbook Example of Property-Based Testing
PBT verifies that a business invariant is always satisfied regardless of the parameters and the return value of the function being tested.
Whatever works
A call for pragmatism in software development: avoid dogma, observe what works, and leave room for doubt.
Software quality means moving fast, for the long haul
Moving fast is easy. Maintaining that pace for years is more difficult and is the true mark of software quality.
Bugs: The Developer, an All-Too-Easy Scapegoat
It’s easy to blame developers. But bugs also stem from design, organization, and culture.
Domain-Driven Design: Why There Is No Universal Model
A model is never a faithful representation of reality, but an abstraction designed for a specific purpose. A model exists only through its use.
The Trials and Tribulations of Optimization
An example of algorithm optimization (the skyscraper game) and the lessons that can be learned from it. Pareto’s Law applies fully.
The Hexagonal Architecture: Developing from the Domain Up
Hexagonal Architecture, formalized by Alistair Cockburn, aims to isolate the domain. It is based on dependency inversion and dependency injection.
Command-Query Responsibility Segregation
CQRS is based on the idea of distinguishing between write and read models when operations are highly asymmetric. Use sparingly.
100% Code Coverage: The Never-Ending Race
This metric isn’t very useful if you don’t know what it represents… However, it’s still interpretable—especially when it’s low!
50 shades of tests
Not all tests fit into a single test pyramid. Several aspects must be considered: purpose, granularity, and assertion methods.
An architecture that leaves doors open
"The job of an architect is to build a structure that allows decisions to be delayed as long as possible": 5 examples illustrating Uncle Bob’s point.
End-to-end tests: how to get off on the right foot
End-to-end tests should be used sparingly, as they are costly to write (Page Model) and costly to run. Here’s how to proceed.
Product: when you get attached to your baby")
We take care of a product, we help it grow, we tend to it day after day just as we care for a baby. We become attached to it, and that’s perfectly fine.
Architecture Decision Record
ADR helps streamline a team’s architectural decisions and prevents them from being constantly called into question.
Don’t write code that guesses the future
Avoid over-anticipating: don’t lay the groundwork for future features; they remain hypothetical. Instead, write code that can evolve.
"User" is not a Bounded Context—and yet, the user matters
You don’t address all users in the same way. Each persona has its own language—and therefore its own context—and its own BFF (Backend For Frontend).
Is your code universalizable?
Ecology and software quality share Kant’s principle of universality: my action can only be good if everyone can act as I do.
You build it, you run it
This phrase, a DevOps mantra, is rooted in common sense. Yet the organization sometimes resists its implementation. CEOs, lay the groundwork.
Refactoring: Avoiding the Tunnel Effect
Until everything is done, it’s as if nothing has been done. To avoid a refactoring’s tunnel effect: the Strangler Fig pattern, which lets the old and the new coexist.
Modular Monolith is the new Microservices
You probably don’t need these microservices, which are so difficult to deploy. The monolith—provided it’s modular—is right for you.
Walking Skeleton
The Walking Skeleton aims to lay a solid foundation for reaching the MVP while minimizing technical debt. It’s a step worth formalizing.
Example Mapping, the Most Underestimated Agile Practice
It would be a mistake to believe that functional design is the sole responsibility of the PM: we think more clearly when working together and using concrete examples.
Trunk-Based Development, a radical solution to “merge hell”
Trunk-Based Development, which stems directly from Extreme Programming, is an excellent alternative to GitFlow, but be sure to thoroughly review the prerequisites.
Bounded Contexts 101
2 common mistakes in dividing into Bounded Contexts: dividing by technical layers and dividing by entities. Think action verbs!
An object is not what you think it is
Building an object means starting with its behavior. The data it encapsulates is derived from that and constitutes an implementation detail.
Bug or feature?
In a legacy system on which many other systems depend, fixing a bug is not always recommended. It’s better to isolate it and maintain it.
I’m not going to sell you a “Clean Code” training course
"Clean Code" is a reference book: reading it linearly, from A to Z, would make little sense. You need to read it, experiment with the concepts, and revisit it frequently.
Library vs. Framework
You call a library, but it’s the framework that calls you. The difference is inversion of control.
Coaching is language-agnostic
Working on software quality means working on architectures, paradigms, and methodologies—particularly clean code. The programming language doesn’t matter.
Test-Driven Development: Just One Tool Among Many
While TDD is a wonderful tool, it is not suitable for all development projects, as it risks falling prey to the “law of the instrument.”
Refactoring: Overcoming the “tunnel effect” with the Mikado method
The Mikado Method involves mapping out the dependencies of the refactoring, then refactoring starting from the leaves of the tree thus established.
Emulation of nominal typing in TypeScript
Structural typing is limiting when it comes to defensive programming. Fortunately, it is possible to emulate nominal typing (branding).
You’re mistaken…
A distinction must be made between development errors—which are handled with exceptions—and user input errors.
Developer Profile: Clément Cornen
A portrait of Clément Cornen, a developer and, above all, a friend. Our values are very much aligned, both in development and in life.
3 Metaphors for Computer Code
Code is intangible. So, to make it more understandable, we use metaphors from the real world, particularly real estate.
Hexagonal architecture: when faced with two evils, choose the lesser of the two
Hexagonal Architecture aims to isolate the application and the domain from the infrastructure. The trade-off is that the infrastructure knows the domain.
Strategic DDD vs. Tactical DDD
First, focus on the system’s modularity at a large scale (strategic DDD). Tactical patterns are important, but they come later.
TDD is dead. Long live testing.
A point-by-point rebuttal of the seminal article by David Heinemeier Hansson, a critic of Test-Driven Development.
DevOps: The Big Misunderstanding
As it has become more widespread, the DevOps approach has strayed from its original spirit, sometimes to the point of being misinterpreted. Let’s set the record straight.
Because form is restrictive, the idea bursts forth more intensely
Code katas are the perfect setting to experiment with new ways of working by imposing constraints. Example: coding using only the keyboard.
Event-Driven Architecture or Event Sourcing?
EDA: a communication model that promotes the decoupling of contexts; ES: a coding model dedicated to traceability within a context.
5 Questions for Antoine Sauvage, CTO of Ovrsea
Now, let’s hear from one of my clients, Ovrsea. Antoine, the CTO, explains how the idea to bring in coaching for his teams came about and what it has changed.
Danger zone
As agility has become more widespread, it has been misused, becoming synonymous with micromanagement and absurd practices. Yet we need agility now more than ever.
JavaScript: When You Are the Compiler
I challenge anyone to prove to me that it’s more efficient to do without static typing when building a JavaScript application.
Your First Steps in Software Craftsmanship
Clean Code is a good starting point, followed by TDD and Functional Programming. Wait a bit before diving into DDD and refactoring!
Refactoring: The Golden Master Technique
The Golden Master method aims to prevent regressions during refactoring and relies on the prior creation of a set of functional logs.
Architectures endure; technologies come and go
Technologies are fleeting: invest in mastering architectures, paradigms, and methodologies, which will serve you throughout your life.
I love Kubernetes
Technology is beautiful and fascinating, but it is not an end in itself. Information technology is there to solve problems in a pragmatic way.
Everything You’ve Always Wanted to Know About Refactoring
Refactoring comes with two challenges: avoiding regressions and overcoming tunnel vision. To help you: Golden Master, the Mikado Method, and the Strangler Fig pattern.
The debt wall
Technical debt is dangerous because it accumulates silently, until the day the company hits a wall. CEOs, take the lead.
Why is software so expensive?
Writing code isn’t that hard; evolving it is. Readability, testability, modularity: the three pillars of software craftsmanship.