25+ years of industrial software engineering, 15+ years leading technical teams on complex systems. Applied maths engineer focused on software and database architecture, high-performance data processing, and long-term maintainability.
kotlin, java, rust, c++, python, sql, gnu/linux, docker, agent-augmented coding
One of the greatest nuisances of the software world is trends. It seems like often CTOs will build their company infrastructure using trendy components without questioning their real pertinence.
My long-standing example in the Java world is the Spring+Hibernate duo — still, a decade after I first wrote this paragraph, widely adopted without much soul-searching. These frameworks contain talented engineering and a few good ideas, but are they really needed? Every mature database engine already has a caching layer. Is Hibernate's memory persistence, with all its join and freshness complexity, really worth the overhead compared to a simple ORM sitting over the database's own cache? Do you need all of Spring's ceremony to benefit from dependency injection and loose coupling, which a plain J2EE setup never prevented? My answer has stayed the same, and so has the codebase fatigue I see on projects that went the other way.
Frameworks, with their top-down philosophy, look reassuring at first glance; the bottom-up approach has many advantages. Frameworks impose enormous constraints on underlying components, on architectural flexibility and transparency, on design choices, on customization, and on the learning curve. The J2EE norm itself is not a low-level norm whose complexity needs to be hidden — it is an elegant and very clean architectural standard.
In a nutshell: frameworks are like dinosaurs. Tools are like small mammals.
I first wrote that while waiting for the next meteorite. One has arrived, in the shape of agent-augmented development. LLM-based coding agents don't particularly care about the human ergonomics of a framework — but they do care, intensely, about the cost of reasoning over a codebase. A large Spring application — with its magic injection, proxy classes, and annotations that only become real at runtime — is a hostile environment for an agent trying to build an accurate mental model. Smaller, composable tools with explicit wiring are natively more legible to agents, and to the humans who read the agent's diffs.
The next meteorite may be further consolidation of AI-native tooling. It may be something else entirely. The discipline that matters is the same either way: question trends before adopting them, and favour tools that stay legible to both the people and the machines that will read your code tomorrow.
I have been living in Marseille (Southeast of France) since 2008, and am often staying in Paris for business or leisure.
I practise rock climbing in the Calanques, one of the main reasons why I chose to live in the South.
I'm a big fan of the game of Go, and am volunteering to my local Go club and some system administration on the French Go Federation server where we host about a hundred club sites.
I have been practising improvisational theatre for several years, with a group that performs regularly in public.
I contribute to some open source projects, mainly Apache Velocity (a template engine), Modality (an ORM), and a few others.
Some of my personal projects are visible here and there.
The first and main point about open source software is that it made the productivity of individual developers really explode. So economically speaking, it’s a great success. Add to this that using established open source software is a guaranty of code quality, security, customizability, reactivity, autonomy, community presence and low costs ; and you really wonder why some people still want to pay for less quality. Habits, maybe.
Now, when it comes to your code: should it be opened or not? Well, not necessarily. You do not want to expose your goose that lays golden eggs. Nor do you want to show everyone your quick and dirty code that fulfills your current needs. Note that going full open source is sometimes a viable path if it makes sense to be paid for services, exploitation rights or extra features, and you’ll cut many testing, debugging, commercial and marketing costs. More often, a good candidate to open sourcing will be a side module, not specific to your business, sufficiently complex and/or generic that there is more sense in letting a community maintain it than spending the resources yourself to keep it afloat.
And here, we are specifically talking about code. But there is more to it. Next to open source lies open data, open electronics, open governance... Today you can already find open source mobiles, open source cars, but not yet any open source dishwasher, alas.
As a regular remote worker, I tend to think that it is pretty important to physically meet your coworkers from time to time, especially at the beginning of a project. But, once trust has been built, remote work can reveal itself more motivating and efficient than on site work, provided to ensure contact with some kind of team chat like Slack, Discord, Mattermost, etc.
Earlier engagements: