Thursday, October 23, 2014

The line between Research and Engineering

Here is a good post from Joe Duffy, that pretty much says the same I've been thinking about the difference between Research and Engineering:
http://joeduffyblog.com/2013/07/13/blurring-the-line-between-research-and-engineering/

The basic message he's trying to pass is that there is not much point in having ideas if they're not practical to implement, which means that to be a good researcher you have understand what is practical and what is not, which implies some degree of exposure to the real world, and more specifically for Computer Science, a good knowledge of the tools, systems, and languages required to implement the idea.

Personally, I go even further, and see the Engineering / Research divide as a Cooking analogy.
A good engineer is like a good chef: given a recipe book and good ingredients, she can make wonderful dishes, and sometimes even with crappy ingredients and crappy recipes she can make good dishes as well (that's the difference between an excellent engineer and a good engineer).
A good researcher is more akin to a Master Chef or one of those guys running restaurants with two Michelin Stars. They may not even be the top best executioners of a recipe (they do have to be pretty good though), but they make their own recipes, they're the ones that write the cookbooks. They experiment with new combinations and sometimes come up with totally unique flavors. Their skillset is a merge of Creativity with Technical Expertise, and you won't be a Master Chef without both.

Perhaps the name "Researcher" is not appropriate to what I'm describing because in academia pretty much every one is called a "researcher"... hummm a more suitable name would be "Innovator" (although Master Chef does sound pretty cool because it reminds me of Master Chief)

Every IT company (and job applicant) is interested in the differences between good engineers and excellent engineers, but these "Innovators" are the unspoken elements, mostly because people with such a high degree of technical expertise are rare on itself, but out of those then select the ones whose creativity allows them to make up new stuff instead of just being really good at "following recipes", and then you're left with a very small subset of individuals, so small a set, that each of them is close to unique in the way he/she innovates, and therefore, there is no point in trying to come up with generalizations to identify them (apart from the fact they are really good technically, and creatively, and they come up with ideas that are actually useful).
You see, the problem isn't coming up with ideas, we have entire Universities and research centers full of PhDs, Post-Docs, and even companies with very bright engineers, all of them with plenty of ideas to go around. In the Universisites, most of the ideas are focused on stuff that can "get a PhD thesis" or "get a grant for another year", and unfortunately that's not the kind of goal that is always innovative or useful to the field of study or the progress of Mankind as a whole. On Companies, many good and excellent engineers have ideas all the time, but these are usually very narrow focused to solve specific problems (at least those are actually useful for something).
Again the cooking analogy applies here: the excellent chefs can take a recipe and adapt it to the circumstances, applying their creative skills, they can take or add a few ingredients or processes and improve an already know recipe to almost perfection. The Master Chefs on the other hand go way beyond changing known recipes.

I guess that what I want to close with is that, we need it all: we need the "Research" and the "Engineering", we need a lot of "good researchers" and "good engineers", we need plenty "excellent researchers" and "excellent engineers", and every once in a while, we also need a few "Master Chief".

Sunday, October 19, 2014

Tony Van Eerd on "Lock-Free by Example"

One of the talks on CppCon 2014 was given by Tony Van Eerd on the subject of lock-free queues.

The title of the talk is a bit misleading because although the techniques he describes are the ones used on lock-free algorithms and data structures, the queue shown on the presentation is not actually lock-free for either pop() or push().

The interesting thing about his talk is that he focuses on the thought process needed to arrive at a lock-free queue. Most papers and talks just give us the "end result" with the algorithm as it should be, but they don't explain why it has to be the way it is. His talk goes into the common pitfalls of designing a lock-free queue, which makes it particularly instructive for people new to the field.

There was one statement that caught my attention, that lock-free algorithms need to maintain invariants at all times. This is sooooo true!
The main reason why designing lock-free (and wait-free) data structures is hard, is due to the fact that the invariants must hold at every step of the way, for every method of the data structure, and every shared (atomic) variable. The more methods you have on a lock-free data structure, the more complex the problem becomes. The more variables are shared among those methods, the greater the complexity and possible interleavings, and higher number of states, where each one must still uphold all the invariants.
Designing data structures with locks is much easier because, the code within a lock()/unlock() can temporarily break invariants without worry, as long as the invariants are restored before the call to unlock().

Sunday, October 12, 2014

Concurrency Track of Eurosys 2014

Eurosys 2014 had a Concurrency Track and they recorded the videos for the four presentations.
Here is the link to the recording: