Quality is too serious to be left in the Craftsmen’s hands!

First contact

I must confess I have something of an ambivalent relationship with the ‘Software Craftsmanship‘ movement. My first contact with it was the discovery of some post about ‘developer’s pride’. personally, I am more a ‘developer’s humility’ kind of guy! Boasting pride sound stupid and short-sighted to me. Reading the manifesto and other articles somewhat moderated my initial reaction: striving for continuous self-improvement, promoting test driven practices are objectives I deeply believe in. Then my next realisation was that Software Craftmanship was basically promoting XP practices. But, instead of making them core to a team based effort, the craftsmanship movement promotes the idea that those must be a personal initiative.

Kinda cute but…

It looks fairly naive to me. Don’t get me wrong, it is important to embrace a quality driven approach, but if you believe you can transform such a large industry by the sheer goodwill of some engineers, I am sorry to say you are gonna be very disappointed. Furthermore, I think this may even be counterproductive as it will eventually create a split between craftsmen and your average developers, the formers being more consistent in their delivery than the seconds, but being significantly more expensive too.

By the way, lets speak it out in the open: quality has a cost, period. And let’s go to the core of the argument: Quality is too serious to be left in the Craftsmen’s hands.

Of course

Yes, it is often a smart investment, but it has an upfront cost. Therefore, it must not be hidden to the customer/product owner/sponsor. Most IT projects main deliverable is a code base and processes that transform this code base to a working software. And this code base is more often than not expected to be extendable, at least decently maintainable. That implies that automated tests are part of that deliverable, and one that significantly enhance the maintainability of it.

The question is then: what is the business value of tests?

Every other industry that I am aware of have a decent appreciation of the value of tests.

At the lower end you will find cheap plastic contraptions made by some sub par eastern factory: we don’t need test to understand we sell crap and replacing is cheaper than fixing.

At the higher end you will find the aeronautic industries where extensive testing is the norm: whenever someone fails, the whole industry is at risk.

Both of those testing strategies are relevant to the business model of the respective industry.


negotiate with your customer/product owner the investment on tests. You have metrics to prove the effort:

– coverage (line or branch)

– mutant testing (demonstrate effectiveness)

Of course, regulatory constraint may as well drive the expected level of quality and testing.

So what about Craftmanship?

If you wanna engage on the Craftmanship journey, you have my full support. But understand that you have to adapt your testing practices to the wishes of your customer.


The danger of microbenchmarking

Performance measurement is a hot topic

in IT, and it has always been so. How fast is the new hardware, which RDBMS has the highest TPS, which implementation has the lowest memory footprint…

Nowadays, pretty much anyone with a decent knowledge of a programming language can write some benchmark and publish his results, so benchmarks flourish everywhere.

Please read them with the colloquial grain of salt: measurement is hard and more often than not, the benchmark may include some bias favoring the author expectations. The bias will probably be accidental and of limited impact, but it will be there nonetheless.

But I wanted to discuss about microbenchmarking, with a focus on concurrency related ones.

Continue reading “The danger of microbenchmarking”

NFluent 0.5 is out

NFluent 0.5 is out

The beta version of nFluent as just been released on nuget by T.Pierrain. For those who may be wondering, nFluent aims at bringing to the C# ecosystem all the benefits provided by the FEST assertions library.

It supports english like test assertions and rely on auto-completion to guide developer into the writing of tests.

Plus it provides explicit error messages, making test driven fast and fun!

PS: for transparency, please note that I contribute to this initiative.

Multithreading and skillset

Is multithreading a complex subject that should be handled only by experts?

This is a fundamental question, that deserve proper care. If experts are mandatory, the problem is that they are hard to get by. Assuming you have enougth of those, we need to address the problem of code integration with non expert developers. Having the expert turning non multithreaded code to multithreaded one does not work; actually it can work at the algorithm level, but at the application level. And then, non experts can no longer modify the code.
The other way around would be having experts lay down some scaffolding code for the rest of the development force to fill in. It looks like a better approach because fix can be made by anyone, as long as it does not pertain to the scaffolding code.
Let’s go one step further and isolate scaffolding code from so called ‘business code’.
Et Voilà!, we have a nice framework. Which has been designed by experts from the ground up.
That is in essence my opinion: all developpers must be able to leverage multithreading. But like several others technical fields, such as databases, middlewares or 3D to name a few, we need to remove the burden from the mass of developpers.

The next question is then: how do we design such a framewok to be a pit of success.

Timebox approach

Mike Griffiths published an excellent post about where and why the ‘plan everything’ approach for projects usually fails and where the ‘timeboxed and iterative’ agile vision provides a clear benefits.

While none of the listed arguments are new, this is the first time I saw most of them in the same post to build a perfect demonstration.
My personnal preference goes for the stakeholders graph!