Tim's Thoughts on AOP

I’ve been bothering Tim Ewald for a while to post a followup to my comments about AOP and code generation, since he was the one that inspired me to write about it in the first place. Well, he’s having trouble with his blog, so I’m posting it here. Now if only Ted Neward would get off his butt and post his response. :)

From Tim Ewald:

I've been hanging out with Craig a lot lately, he's doing some work for our team. He posted his thoughts on AOP a couple weeks ago and mentioned my work in that area. We've been carrying on the conversation ever since, and I promised him an online response.

 

I did a ton of work with AOP when I wrote Transactional COM+. By the end of that project, I had reached one main conclusion: call-interception is not a good, general purpose extensibility point. COM+ (at the time) was an entirely closed system with a fixed set of services that could be used in conjunction with one another. Even in that very finite universe, the interplay between the services is quite complex. Making that universe infinitely large by allowing third parties to mix in additional interceptors with arbitrary behaviors‚ is a mistake. The complexity goes through the roof, because, as Craig noted, the services typically are not orthogonal.

 

Is interceptor-based extensibility any worse than other types of extensibility? I think so. Method-level interceptors change the path from a call-site to a method's code. It's pretty hard to write reasonable calling code if you don't know how method invocation actually works and it varies on a case-by-case basis.

 

Probably the best example of the potential pitfalls is error handling. I want to get the exceptions thrown by the methods I call. If there are n interceptors between me and the method, that may or may not happen. Maybe an interceptor will catch the original exception, and throw a new exception. If I don't know that happened, how will I ever track down the real error? And what if the original function didn't cause an exception at all, it just left the world in a state that some interceptor didn't like? How do I know what happened? The path from a call-site to method code should be sacred. Interceptors can alter in ways that are not clear (and often are not documented), in essence encouraging "programming by side effect", which is a really bad idea.

 

COM+ 1.5 added support for "Services without Components", aka CoEnterServiceDomain, and Everett exposes this new functionality as managed code. No components means no interception, which I like. These APIs were really designed to allow COM+ services to be deeply integrated with low-level plumbing, but I like to use them in my own application code. Craig and I wrote an MSDN Magazine piece about how this works. However, judging by the ratings, most readers don't find the idea too attractive (or they just don't like our prose ;-).

A Different LOC Metric

I had dinner with a good friend of mine here in Boston tonight. He’s technical, too, so we got to talking about code. I mentioned something about how I’ve been programming a lot lately, and it detoured us into a discussion about lines of code (LOC) metrics.

He brought up an interesting one that he’d heard recently. The idea is that it’s not so much a good idea to measure how many lines of code a developer is producing (e.g. 7 per day), but rather how many lines of code they are responsible for. And that there’s an absolute maximum. In other words, once I’ve got 50KLOC, I’m done – all my time is going to be spent in maintenance.

I’m not saying 50K is the number – in fact the number will be different for different developers – but the idea that a single developer has a capacity resonates with me. I know how hard it is to go back to things I haven’t looked at for even a week when I’ve got a lot of stuff going. And forget about supporting code that I wrote two years ago.

What does this mean? A few things, I think:

1)      Refactoring is super important. The fewer LOC you have, the more functionality you can support.

2)      As you write code, you need to hire more people. Duh, but if someone can figure out the numbers, it may help plan. Or motivate refactoring.

Also, in light of recent discussion, it begs the question: does a line of code spit out ten times by a code generator get counted once or ten times? I’d guess the former, but it’s an area I’d love to see experimental data on.

Do Not Touch The Tools

 OK, reading this
one actually hurt – both the thought of it, and the laughing about it.

"Do not touch the tools."

[BitWorking]

CryptoGram

Bruce Schneier just published the latest issue of his newsletter “CryptoGram”,
available here. My favorite
bit was his link to this
story, wherein an Idaho police department gave their officers laptops with wireless
access to the police network. As you may know, it’s basically trivial to crack
a 802.11 networks, even with WEP encryption enabled. To get around this, the police
department

added security by using a hard-to-crack
proprietary encryption protocol

This is a huge red flag
– secure protocols are generally not proprietary,
but rather developed in the public eye where they can undergo scrutiny by a community
of experts.

I’ve been down this road myself – I’ve invented security
protocols for clients only to invariably discover serious flaws in them months later
when I came to understand the problem better. When I went back to fix the problems,
I almost always converged on something that already existed – SSL, Kerberos,
whatever. Just look at WEP, the wireless encryption standard – even using “128-bit
encryption” it can be cracked in a matter of hours by freely available tools.
And even protocols that are thought by most experts to be secure can be cracked trivially
when they are implemented poorly.

Rule number one in security is: don’t
invent your own. We’ll see how long it is before that police department
gets bit by their mistake.

Lost at 10,000 Feet

There we were, lost in the middle of the forest at 10,000 feet. We’d hiked all day the day before, having flown in from sea level just the day before that, so we were tired. We’d followed the trail easily enough for the first two hours of our hike from Ouzel Lake, but now, just a mile from Thunder Lake, it sort of disintegrated into a hundred different sets of footsteps wandering off across the thick snow cover in all directions. We did our best to pick out the trail, but pretty soon we found ourselves standing in the middle of the woods saying, "Now what?"

It might not have been so bad if it hadn't been raining. And snowing. And hailing. It might not even have been so bad if there had been less than four feet of snow on the ground. Or if we were able to take more than twenty steps across said snow without punching through to our ankles, to our knees, or even occasionally to our hips. Or if our packs had weighed a little bit less, enabling us to crawl out of the the little snow sinkholes more easily.

I've done a fair amount of backpacking before, and I'd have to say this was the closest I've ever been to worried. We were fortunate that we had a decent map and knew how to read it. We were lucky that we happened to know we were between two streams, and that the trail was somewhere downhill. And we were damn happy when we finally found the campsite and were able to stop walking.

All in all it was a great trip. And it's getting better. Like most backpacking trips, I'm often wondering "why do I do this to myself" when I'm out there, but by the time I get back it's already turning into a fond memory. Some pictures here.

 

Keith's New Book Developing Online

Keith Brown is writing his new book out in the open – he’s posting it on here on his website as he writes it. The tentative title is A .NET Developer's Guide to Windows Security. If you’ve read Keith’s Programming Windows Security, you’ll know this is something to be excited about it. Read it! Send him feedback!

Optimization - It's All the Rage

Quite a few people have been talking about optimization lately. Notably Sam, Don, and Tim. I particularly like what Tim has to say:

1.      Design and code your app, trying hard not to do anything really stupid, and striving for flexibility.

2.      If it’s fast enough, don’t worry any more.

3.      If it’s slow, get out your profiler and measure things until you understand where the problem is.

4.      Fix the problem, which may well require major refactoring, but that’s OK because that’s probably coming at you pretty soon anyhow with the next batch of requirements. Furthermore, you couldn’t have avoided it because nobody is smart enough to predict where the bottlenecks will be in a complex application before it’s running.

I can’t even count how many times I’ve seen people ask questions on the mailing lists that show they’re trying to optimize their system at a micro level before they’re even done coding. It’s soooooo tempting – I find myself constantly fighting the battle with myself (and last week, with my coworkers). I often lose. And then I find something like this is the slowest thing in my application.

Why do we do this to ourselves? Is it because we measure our professional worth by how cleverly we program? Is it because CS degrees have at least some focus on algorithms?