Jonathan ‘Peli’ de Halleux is a young geek who has already made several major contributions to the community of .NET Developers. Firstly, there was MbUnit, the Generative test Unit framework, that provides basic building blocks that a developer can use to build complex fixtures for Unit Testing, Then came his friendship and collaboration with Lutz Roeder, which led to him writing a number of add-ins for .NET Reflector that range from type graph, code complexity, code review, treemap of types, statement graphs, an attempt at automatic test case generation from a method basic block graph. Then, there was QuickGraph, which provides Generic Graph Data Structures and Algorithms for .Net. Finally, came his contribution to Pex, the radical new approach to unit testing being developed by Microsoft that creates a unit test suite automatically, and suggests how to fix bugs.

Peli is remarkable not only for his code, but his ability to explain, document, communicate and coordinate. His Blog, Peli’s Farm  is compulsory reading for .NET developers.

Peli is now a Research Software Developer Engineer at Microsoft, working in the Foundations of Software Engineering Group in Redmond.

Jonathan ‘Peli’ de Halleux was born and raised in Belgium in a small town called Houtain-le-Val (now in the municipality of Genappe). Like a lot of geeks he started out at a tender age by writing his first BASIC program on a Commodore 64 (10 PRINT “HELLO” 20 GOTO 10) and has kept a passion for coding since then.

Peli graduated as an engineer in applied mathematics from the Catholic University of Louvain, in Louvain-la-Neuve “A lot of fun.” he says. He then took a doctorate (2000-2004) in Applied Mathematics, writing on an obscure subject involving quasi-linear hyperbolic equations and rivers… and some coding of course.

At the end of the doctorate, he had his first encounter with C# while he was preparing an assignment for the C++ class. As Peli says:

“I was prototyping the C++ assignment, and decided to take on this funnily named language C#, the result was Quick Graph and I was hooked to not having to write ‘delete’ again.”

Coming from a C++ background and moving to the CLI was really fun. “Suddenly I had access to metadata, dynamic code, introspection, Reflection and not a single template in sight. As luck would have it I tore my anterior cruciate ligament (one of the four major ligaments of the knee) and was stuck in a hospital bed for 3 days… with my laptop. During those three days, I built the backbone and most of the extensibility ideas that were part of the early MbUnit“

“As I was doing this I began to use a very exciting application called .NET Reflector and discovered that I could write add-ins for it. .NET Reflector is a great platform to experiment with code analysis. Visualization of control flows, method ranking, code metrics, Reflection. Emit language, type graphs; any crazy idea could translate into a .NET Reflector addin. All those pet projects somehow got me into the attention of some folks at Microsoft in Redmond and after a couple emails and a phone interview later, I received my tickets to fly to the US for an interview for the Common Language Runtime (CLR) at Microsoft.”

“It was a pretty exciting moment. Apparently the interview went well enough and I started in the fall of 2004 as a test engineer for the Just-in-Time compiler (JIT), which of course converts MSIL to native code on demand at application run time. I spent two years in the CLR; it was an eye-opening experience, moving from writing a test framework as a pet project to testing a component that ships on millions of machines.”

“People say that joining Microsoft is like drinking from the fire hose. It’s a pretty accurate way of describing things. I learned a lot by living the tester’s life day by day. After two years in CLR I jumped at the opportunity to work on a project called MUTT at Microsoft Research. MUTT (MSIL Unit Testing Tools) is a joint project of the SRR and FSE groups. Its goal is to automate the generation of unit tests for managed code .NET. MUTT of course was the direct ancestor of Pex.”

“It’s been a great ride so far working for Pex with Nikolai Tillmann and the rest of the team. We are really thrilled to get Pex in the hands of developers. On a rather more personal note, I’m enjoying the Northwest with my wife and son (with my second on the way),  and I started to play Ice Hockey two years ago, it’s a blasting experience.. “

RM:

“Where did the name Peli come from?”

PH:

“It comes from Pelican and it was a nickname given to me when I was about two or so months old. My parents can’t really remember how or why they gave me the nickname but it’s stuck since then.
There are two versions of how I got it though.
The first is that it comes from Jonathan Livingston Seagull. Jonathan Livingston Seagull is a bird who teaches us how to follow our dreams and reach our goals, no matter what anyone else might think. He’s a seagull who wants to master the art of flying, even though his flock has told him many times that all seagulls should concentrate on is getting food. My parents went to see a production of it at a theatre when I was born. The seagull then became a pelican for some reason.
The second version is that my godfather, who was a sailor, looked into my crib and remarked to my parents that I had a big mouth like a pelican. “

RM:

“What do you think to the changes Jeff Brown has made to your baby, MbUnit, in version 3?”

PH:

“I think that Andrew Stopford did a great job on turning MbUnit who was mainly a one-man project into a lively open source project with a passionate team of developers. Jeff and the other developers of Gallio have done a great job on their latest release.”

RM:

“What do you think to MSTest as a testing framework?”

PH:

“MSTest is not my product, so I’d rather not answer the question.”

RM:

“What was your initial response when you heard about the .NET Reflector \ Red Gate deal with Lutz Roeder?”

PH:

“Lutz, is a close friend so I was really happy for him. He’s been spending endless hours in keeping .NET Reflector the best developer tool for .NET. I’m confident that Red Gate will keep the level of quality that made .NET Reflector such an essential part of developing .NET code.”

RM:

“What would you like to see Red Gate do with .NET Reflector?”

PH:

“I’m confident that Red Gate will keep on maintaining the high quality of .NET Reflector. I still hope to write a couple more geeky add-ins on top of it.”

RM:

“Pex might be about to save the world but what is its real purpose? Saving time? Making things a little easier for developers ?”

PH:

“Well I don’t think Pex will save the world as such, but it might save you the day if you’re a .NET developer. Pex is about exploring code automatically, in a similar fashion to the way developers execute an application step-by-step in the debugger.
Because Pex understands data flow and control flow, it can come up with interesting inputs to your code that will steer it into different behaviours. So in a nutshell: With Pex, you’ve got an assistant that’s trying to find those corner cases bugs. And with Pex he never stops trying.

RM:

I’m sure there isn’t a programmer on earth who has tried Pex (Program EXploration) and isn’t thankful for it. To actually have an intelligent assistant to the programmer is a real boon. What was the initial inspiration behind developing Pex?

PH:

Well, Pex was actually started by Nikolai Tillman in 2005 and I joined one year later the two of us have been working on Pex since then. My vision is to help the developers with the burden of testing. I certainly don’t believe it is as much fun as some people say it is. That’s where tools like Pex will help, I hope.
Nikolai and I have also spent a lot energy making Pex accessible to every developer. Pex builds on top of some pretty advanced techniques such as dynamic symbolic execution, code instrumentation, theorem proving and more geek goodness.

RM:

Do you think they’ll be a time when we don’t manually hunt for bugs?

PH:

Not anytime soon I’m afraid. You will always need someone to tell the computer whether the outcome of some execution is correct or not. Better languages should prevent us from writing buggy code in the first place, better developing tools should uncover bugs as we code, better testing tools should help us do it semi-manually. Moreover with the multi-core revolution coming up, things are getting to get even more fun: more deadlocks, data races etc.

RM:

What lies in the future for you do you think? What do you see yourself doing in say, 3 years? Do you have further projects bubbling away that you can us about?

PH:

I think we’re only scratching the surface of what tools like Pex can achieve. I suspect – hope – that such techniques will change the way developer write programs (or even teach computer science). Also imagine a near future where every developer has a quad core (at least), one for the IDE, one for the music, and the other ones for Pex, crunching on the code.

RM:

What would be your perfect piece of software and what purpose would you put it to?

PH:

If I knew where to find it, I would already have loaded it in .NET Reflector.