Category: Quality

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!

Step one

Hi everyone

I feel like starting with a good ol’ rant: developers suck!.Computer Voodoo

Ok, this mays sound harsh, but for the record, that includes me. We suck because we write buggy and unmaintainable code. And whenever we overcome those issues, someone will modify the code at a later date and ultimately will render it buggy and unmaintainable! And of course, that someone may be ourselves in the first place.

So what are the causes of this Great Curse?

They are numerous, but ultimately most of them relate to complexity:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it? (B.Kernighan)

So, in our daily IT related actions, we need to relentlessly focus on simplicity. A lot of work has already been done around design rules, coding rules, frameworks and framework usages, documentation processes. I will refer to significant progress and effort along the way, but my main intention for this blog is to focus around what is usually called multi threading or parallelism. I certainly feel that simplicity if nowhere on the horizon for parallel programming, while our typical 2011 CPU has at least 4 cores.

My first multithreaded development experience dates from the mid 90’s, when I was working on custom three tiers application dedicated to check processing. For the past 6 years, I have been more intensively active on this topic, as I have been working on electronic trading systems for an investment bank. I did

  • design multi threaded architecture systems
  • code part of them
  • test them
  • instrument them
  • design a event driven multi core aware framework that has been implemented in numerous systems (IA+ Threading)
  • hold training sessions and conferences around the subject

My languages of choice are C++ and .Net and I have a significant experience around the Windows kernel.

My next post will be focused on multi threaded related assumptions.