Thoughts On ...

Continuation Passing Style

My tour of functional programming idioms in C# 3.0 continues with some continuation tests. These two tests are equivalent:

[Test]
public void ExplicitReturnStyle()
{
    Assert.That(someObject.Identity("foo"), Is.EqualTo("foo"));
}

[Test]
public void ContinuationPassingStyle()
{
    someObject.Identity("foo", s => Assert.That(s, Is.EqualTo("foo")));
}

Given these two overrides of Identity:

public T Identity<T>(T foo)
{
    return foo;
}

public void Identity<T>(T foo, Action<T> f)
{
    f(foo);
}

In the Continuation Passing Style Identity doesn't return a value. Return'ing is simulated by passing what comes after the function (the continuation) as a function object. In many functional languages continuations are so central to how things work that this is how you return values (and those languages are optimized for doing this). For those of you like me who grew up with the imperative children of pascal, this may be somewhat mind-bending at first. It will also likely have you saying "why would anyone do this?"

Rather than steal his entire article, go see Wes Dyer's article on the subject (where I got the identity example) for more about why one might do this outside of a language (like Scheme or Erlang) where this idiom is apparently the norm.

For even more details (including why this isn't quite CPS) see this by Don Box.

BTW, my answer to "Why do this?" is: "When it is the best way to solve the problem at hand." That I don't know when that will be yet, doesn't really concern me. I don't always learn things with a specific application in mind. Sometimes, I learn things so that when a problem arises, I have a lot of different tools in my toolbox. In other words, I am learning it because its interesting, a bunch of people smarter and more knowledgeable than me have found uses for it, and I might someday too (and I definitely won't if I don't know about it!)

Perhaps the best reason to learn this stuff is because Microsoft has put some sharp tools in the C# toolbox and I think its better to know how they work so that - even if I rarely ever take them out - I don't get cut on them while rummaging around in there.

UPDATE: For Wes's take on why it's important, see here (and really his whole series on the topic is worth the read!)

UPDATE2: If you want to take a deeper tour of these and many other functional concepts, this series of articles by Dustin Campbell goes far and wide if you follow all the links (and the links' links and so on...)

Closures and Sequence Points

Immersing myself in the functional intricacies implied by the C# 3.0 extensions has led to a couple of interesting tests. Thought I'd share it for it's amusement value:

The first one comes from the wikipedia discussion of a "Sequence points":

[Test]
public void ThisIsNotIntuitive()
{
    int i = 0;
    i = i++;
    Assert.That(i, Is.EqualTo(0));
}

This behavior is apparently undefined in C and C++ (It may be in C# too, dunno).

The second one is taking this a step further and incorporates a closure to show how really evil doing this sort of thing is:

[Test]
public void NeitherIsThis()
{
    int i = 0;
    Predicate<int> f = (x) => x != i;
    Assert.That(f(i++), Is.True);
}

Since there is a sequence point before function code is entered (again at least in C/C++) then at first glance, one might assume the test should assert IsFalse, but no - because i's value is placed into x *then* incremented, then the function body is entered so that by the time the evaluation occurs the numbers don't match.

This is visible in the disassembly of the expression call (I pulled it to a separate line). ebp-48h is "i" and ebp-4Ch is "x" (as an aside: notice how the value stuffed into "x" is retrieved and incremented and then mov'd to "i" rather than getting it from "i" in the first place. Works, but weird):

bool result = f(i++);
0000008d  mov         eax,dword ptr [ebp-48h] 
00000090  mov         eax,dword ptr [eax+4] 
00000093  mov         dword ptr [ebp-4Ch],eax 
00000096  mov         eax,dword ptr [ebp-4Ch] 
00000099  inc         eax  
0000009a  mov         edx,dword ptr [ebp-48h] 
0000009d  mov         dword ptr [edx+4],eax 
000000a0  mov         edx,dword ptr [ebp-4Ch] 
000000a3  mov         ecx,dword ptr [ebp-40h] 
000000a6  mov         eax,dword ptr [ecx+0Ch] 
000000a9  mov         ecx,dword ptr [ecx+4] 
000000ac  call        eax 

In addition to the two links above, this guy has more on this subject including (the hopefully unnecessary) "don't do this in your code."

Is This Thing Still On?

If there is anyone still subscribing, then hello! You know you've been gone from your own site for a while when you have to use password recovery to log in.

The reasons for my silence over the past couple of years have been due to a combination of intense writer's block due to anxiety about discussing work-related matters on my blog (to date, the source of most topics discussed here) and -- for the past 1.5 years -- being away from software development in my work (though I still try to keep up with what's going on).

Lately, though I have been feeling the itch to write again - and resurrect this site. So, what I hope to do over the next couple of weeks is flush out any old material still lying around, and then start writing again when I feel I have something useful to say.

Business and IT converging?

A Computer World article talks about business and IT alignment/integration:

As more CIOs move toward business and IT alignment over the next 
several years, the makeup and structure of IT will change. IT and business unit
employees will work more closely together -- and in some cases, 
interchangeably.

(Via Slashdot)

I speculated on the roots of this split, and the eventual convergence of business and IT last year.

I believe that it is through such closer interaction and blurring (but not elimination) of distinction between business and IT -- and not the application of Agile to large classic IT projects where they are doomed to become their opposite -- is where the principles and practices of XP and related methodologies will have their lasting impact on software development.

Applying Technology is not Technology

Via Bruce Schneier:

I've long said that the fundamental problems in computer security are no 
longer about technology; they're about applying technology. Workshops 
like WEIS are helping us understand why good security technologies fail 
and bad ones succeed, and that kind of insight is critical if we're going 
to improve security in the information age.

Bruce referring to a conference (WEIS) that looks at the relationship between economics and computer security.

I think this is a great point, but Bruce doesn't go far enough. I think this can be generalized to: The fundamental problems in professional computing are no longer about technology but applying technology.

I'm sure that people who are still pushing the boundaries in things like AI, nanotech, etc. would beg to differ, but for the vast majority of people who are involved with technology (i.e. those supplying and using computer-based systems in the business world), the problem has shifted.

Not that long ago (i.e. within my time as a professional programmer), hard drive size, memory size, bandwidth and processor speed were forefront concerns for any business application design, often requiring workarounds or selection (or anticipation) of new technlogies. Now the discussion has shifted to how we effectively apply the tools and technologies at our disposal (I haven't heard anyone say something along the lines of "well we can do that if we just get more memory" in a long time). Even my phone has more processing power now than some of the desktop machines used by companies 10 years ago.

This is not to say our work is done. But rather that its just getting started. Now the challenge is to understand how to use the things we have effectively and efficiently (arguably a bigger challenge).

It also might explain the growing sense that CS degrees are insufficient to prepare people for a career as a professional programmer. As the fundamentals become more commodotized, the application becomes more central to success.

Knowledge Nodes

One could (and I guess I am about to) argue that the various communication tools that are central to Extreme Programming -- namely the practices: small team; pair programming; co-location; daily-standups; continuous integration; on-site customer; and iteration planning game -- are aimed at producing a situation where everyone knows everything about the design and features of the system being worked on.

As the number of people on a software team grows, it becomes harder to accomplish this goal, and so there becomes a need for people who are what I term knowledge nodes: these people seek to understand the entirety of the design and features being worked on, so they can communicate relevant bits of that information to others who then have partial (but presumably sufficient) knowledge to do their jobs. Further, it appears common (and a function of both culture and team-size) to break the two areas of knowledge (i.e. design and feature-set) from each other and create specialized nodes for each of them.

The name of role such a person plays on the team varies, but Project Manager, Analyst, Lead Developer, Lead Programmer and Architect are all commonly used. Each of these incline toward the design or the feature (i.e. technical and business) aspects of the information on a project-by-project basis.

What do the people who are good at these roles have in common? In my experience, they are good communicators: they are skilled at gathering, explain ing and sharing knowledge about the design and/or the features of a software system.

The interesting thing (or at the very least: the reason I started writing this today) is that even very small teams need at least one such person. Even on a team with a half-dozen people or so (such as the one I work with now), if the knowledge of the system fails to reach a knowledge node -- it is less likely to get shared with everyone.

Right or Wrong I have always seen myself in this role. I've also (right or wrong) had a tendency to feel like if I didn't know something about the design or features of the system I was working on it wasn't known.

(and so, yes this entire analysis may be nothing more than ego gratification of my self-perceived role on software projects)

So now that I've found yet another way to describe my role on a software project, so what? Well, for those of you who also find yourself in this (or working with someone playing this) role, I have some advice:

That while you may think that things are not known (objective) unless you know them (subjective) remember that's your ego talking (but it still may be true if your team has come to rely on it).

If you are not someone who likes to talk endlessly (I've heard the word 'pontificate' a few times in my career) about design and feature ideas, get your thoughts to someone who does -- they'll make the rounds for you.

On small teams, one or two such people are more than enough (too many, and there will be no work, just talk) -- but you do need at least one to forge a team (otherwise everyone will just work on their bit without knowing about the rest).

Don't confuse knowledge nodes with knowledge creators -- good teams have both, and often the same person isn't good at both.

Particularly (as in my case) people are rarely good at both at the same time. I find that I can share design and feature knowledge, or I can create it, but when I am doing a lot of one, I am doing very little of the other. (team-size, iterations and pairing help with this -- as does some self-discipline on my part to keep it balanced).

Finally, the (presumed) XP goal of everyone knowing everything is in pratice accomplishable by making sure the knowledge node(s) of the team know everything and then get it shared around. If you are playing this role, you have to gather *and* share. If you are disinclined to do so, you have a responsibility -- at least -- to get what you know to such a person, so they can share what you know about the system with everyone else. This use of knowledge nodes may be (I don't know I just musing here) the key to an effective software team.

How to Start an Interplanetary War

H.G. Wells apparently got it backwards.

The thought of firing a space-based railgun at an unsuspecting planet in order to observe the resulting "debris plume, looking for any evidence of life" sounds somewhat Onion-esque to me.

XP Exaggerated Redux

Here's a wayback machine link to what I believe was the best proceedings summary from XPUniverse 2001. (via Alan Fancis)

XPEX was a parody summary that (as Alan points out) came to us after many rounds of Guinness in the Hotel lobby (somewhere right after Alan declared that XP needed a Flag if it were to conquer the world, if I recall correctly).

There's a lot of in-jokes of course (some *very* dated to the conference), but a lot of more general pop culture and Extreme Programming community references. For fun, see how many you can find.

Big thanks to Alan for resurrecting this. I needed a brief light moment before I dive back into the crazy rewrite/refactoring that has been my sole focus for the past two weeks.

Job Postings

Those of you who read this site regularly may remember that I left ThoughtWorks last year to join a software team full-time.

Well, my team is hiring. Specifically, we are looking for a Reporting Analyst, and a Junior Developer.

If you think you might be interested (or know someone who else who may be), please feel free to follow those links to the job descriptions and follow the resume submission criteria there (the above point to Craigslist, they are also on Monster, here and here).

Please don't send anything directly to me -- while I will be closely involved in the hiring process, I am not managing the process itself, so sending something to me will probably just ensure that you don't get considered nearly as quickly or reliably.

I have refrained thus far from talking a lot about Redbox, and what I've been doing here. That may change in the near future, but for now, I will only say that we are building a great software system, we have a great team, and yes we are practicing Extreme Programming.

I look forward to hearing from you.

Competition

What if you're team is better than 99% of team's developing software? What if you are better at software development than 99% of the people who've ever tried?

What if you've climbed to the base camp of Mount Everest? Then you would be farther along the path than 99% of who've ever lived.

Now all you have to do is climb Mt. Everest.