Nicolas Fränkel

I had been pleasantly surprised last time when, after connecting on LinkedIn, a recruiter sent me a personalized mail. It was the first time it happened, and I found this gesture showed that the recruiter cared about the relationship. Besides, the job I currently have was found on LinkedIn - or more correctly, a recruiter found me for this job. This is to say that I have nothing against neither recruiters nor LinkedIn. Unfortunately, more often than not, I usually receive such messages: Hel

While attending JavaZone recently, I went to a talk by Neal Ford. To be honest, the talk was not something mind-blowing, many tools he showed were either outdated or not best of breed, but he stated a very important fact: application servers are meant to address resources scarcity by sharing resources, while those resources are no more scarce in this day and age. In fact, this completely matches my experience. Remember 10 years ago when we had to order hardware 6 months in advance? At that time

Some resources on the Internet are written in a very imperative style - you must do that in this way. And beware those that don’t follow the rule! They remind me of a french military joke (or more precisely a joke about the military) - but I guess other countries probably have their own version, regarding military rules. They are quite simple and can be summarized in two articles: Art. 1: It’s mandatory to obey the orders of a superior. Art. 2: When the superior is obviously wro

Last week, I had a heated but interesting Twitter debate about Code Coverage with my long-time friend (and sometimes squash partner) Freddy Mallet. The essence of my point is the following: the Code Coverage metric that most quality-conscious software engineers cherish doesn’t guarantee anything. Thus, achieving 80% (or 100%) Code Coverage and bragging about it is just as useful as blowing in the wind. For sure, it’s quite hard to have a fact-based debate over Twitter, as 140 chars

This week, I’ve lived again an experience from a few years ago, but in the opposite seat. As a software architect/team leader/technical lead (select the term you’re more comfortable with), I was doing code reviews on an project we were working on and  I stumbled upon a code throwing a NullPointerException: that was a big coding mistake. So I gently pointed to the developer that it was a bad idea and that I’d like him to throw an IllegalArgumentException instead, which exactly th

Two weeks ago, I was at the JavaZone conference for the first time. There, I facilitated a Vaadin 7 workshop and presented an Introduction to Mutation Testing. Moreover, I attended many great talks by brilliant speakers, but one was really head and shoulders above the lot: 'Software Design, Why, When and How' by Kent Beck.

I guess many of you readers are familiar with the Open/Closed principle. It states that: Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification This other Open/Closed principle is completely unrelated, but just as important. It states that: When 'something' is opened by one’s code, one MUST close it as well!

Many knows the tradeoff of using exceptions while designing an application: On one hand, using try-catch block nicely segregates between regular code and exception handling codeOn the other hand, using exceptions has a definite performance cost for the JVM Every time I’ve been facing this quandary, I’ve ruled in favor of the former, because 'premature optimization is evil'. However, this week has proved me that exception handling in designing an API is a very serious decision. I&#