Monday was the Tutorial Day. Two half-day sessions, for which you go to pay an extra thousand bucks or so. The company sprang for myself and Dan (the other Architect who is really passionate about this stuff).
The first session was Design Patterns: From Theory to Practice, by Alan Shalloway, who set the tone that the best lecturers are coots. In tone, looks and occasional crankiness, he rather reminded me of a younger Harlan Ellison. This was a cut-down three-hour version of what is apparently normally a three-day class -- this mainly resulted in him having *far* too many slides (280 total, which he had to go whipping through pretty fast).
The conclusions I drew were mostly pretty comforting. While I've been aware of the patterns thing for years, I really hadn't dug into it. This talk mostly boiled down to a discussion of the *mindset* behind patterns, rather than a survey of patterns themselves, and the message was that the mindset is the important thing -- if you are thinking about the problems correctly, you can derive most of the resulting patterns on your own. Nothing in the mindset was especially alien: mostly to keep your classes small and focused, and keep instantiation separate from use, both principles I tend to generally follow anyway. So while it's still probably worthwhile to get myself read into the subject to see what clever insights people have had, it doesn't sound like I've missed anything deadly crucial.
The lunchtime keynote was How We Screw Ourselves: Misunderstanding the Economics of Software Development; the speaker was Michael Schrage, an economist from MIT. His argument, intriguing if not 100% convincing, was that companies do better if they think of their internal processes as markets, and treat them accordingly. His really compelling point was that companies tend to mess up their incentives, both internally and externally, and get suboptimal results because of it. He also argued for a fair while that treating your most valued customers as partners is good practice -- not simply for warm fuzzies, but because you can usually get a lot more indirect benefit out of them as a result. (His canonical example being the Win95 beta program, which he estimates as having received an effective $1 billion labor subsidy from the users.)
Afternoon was spent in the Agile Model Driven Development Workshop, run by Scott Ambler. This was an interesting but scattershot presentation. Ambler's main point was that it's worthwhile to familiarize yourself with a wide number of the modeling techniques in currency today, because each is useful some of the time. But that said, it is rarely worthwhile to invest too much effort in any given model, and for heaven's sake don't keep the silly things -- most of them lose their value very rapidly, and you simply waste time maintaining them. In the middle, we had breakout sessions, wherein he gave out a case study and had each table develop useful models to explore it. Sadly, I was at a table mostly made of people shyer than myself -- I wound up taking the whiteboard and desperately trying to coax the rest into saying *something*, with only partial success. I suspect it would have been more fun with a louder bunch.
Today was mostly classes -- I managed to miss the Expo entirely (not that it sounded very interesting), and unfortunately didn't get down to the conference bookstore before it closed. But there were some good classes.
First up was Agile Methods and Usability, by Larry Constantine. He proves to be a fairly good presenter, but is much too fond of cute Powerpoint tricks. (Sorry, I stopped being impressed by dancing graphics synch'ed to music a long time ago.) He presented several different examples of how to manage good usability design in an agile project. My main takeaway was that you generally want to figure out the "grand scheme" of the usability design upfront, but beyond that it isn't clear how much detailed design is worth doing. This was one of those sessions whose main lesson was "It Depends".
Next up was Hype: Reality Ratio: Case Studies of Secure Web Service Implementations, by Bret Hartman. This was the least satisfying of the sessions -- I was hoping for a survey of SOA architectures, but instead we got an extended screed about how you absolutely should be having dedicated hardware boxes doing your SOAP management. All of which would have been less irritating if he wasn't the VP of a company that sells (you guessed it) dedicated hardware boxes for SOAP management. All of the examples were using his own tools, and there was a five-minute ad for his product line in the middle. The whole thing left a bad taste in my mouth -- the point might well be correct (I think it's entirely plausible both on performance and security grounds), but he undercut his own point with the partisan presentation.
The lunchtime keynote this time was Agility and Architecture, by Robert Martin, and was unquestionably the highlight of the conference. Martin is the coot's coot, dancing all around impassionedly while he concisely made the case for agile development in a lecture that was at times chokingly funny. He is the master of the left-field metaphor, whether it be a five-minute diversion onto the two-slit experiment (to demonstrate that our intuitive beliefs of how the world should work are sometimes wrong) to a skyscraper shaped like a picnic basket (no, really) to demonstrate that architecture can be strange. He compellingly argued that traditional software development is just plain broken -- moreover, he pointed out that the Waterfall method is basically a modern aberration. (The most remarkable part of the presentation was a brief sidebar about Royce, who is apparently credited as the original promulgator of Waterfall -- in a paper that, if read carefully, turns out to say that the Waterfall approach *does not and cannot work*. Most people stop reading before they get to that conclusion.) Fun stuff, which changed my mind about which class I was going to take later in the afternoon.
For my next class, I went for something hardcore technical: Lock-Free Data Structures in C++ by Andrei Alexandrescu. This was exactly what I was hoping for: an advanced technical class on a subtle and important subject. He started out by spending about half an hour motivating Lock-Free programming, arguing that:
- While the number of transistors on a chip continues to skyrocket, serial process speed is no longer doing so;
- Therefore, parallel processing is becoming ever more important if performance is going to continue to improve;
- Many gains of past years have been made by automated instruction-level parallelism, but we are reaching apparent limits in how much we can gain from that;
- Therefore, explicit parallel processing is becoming crucial for high-performance software;
- Traditional lock-based programming is both fairly inefficient and very dangerous, especially when you try to scale it up to a complex data environment;
- Therefore, data structures that permit lock-free programming are a Very Good Thing.
Of course, C++ is not a garbage-collected language, and it turns out that the generic algorithm has a serious memory-leak problem due to the thread interactions. The last half-hour of the class was spent outlining the rather terrifyingly clever algorithm for managing the resulting memory, which involves both global and thread-local linked lists, temporary hash tables and set math. The amount of labor involved is nothing short of spectacular, but he demonstrated that, while it's a large amount, it's an effectively constant large amount (more precisely, proportional to the number of modifications you make to the shared data), so the usual O(k) arguments apply. He claims that, in practice, it already proves to be faster than locking in many scenarios. None of which means that I'm ever going to have any reason to use it, but it's fun to get to play with high-end toys like this.
The last session was Automated Dependency Tools and Metrics, with Bob Martin again. (I having quickly concluded that, if I was ever going to be a fanboy about a software guru, this was one worth fanboying.) Again, he managed a delightfully entertaining and persuasive lecture on a fairly dry topic, presenting in an apparently haphazard but actually pretty organized way the case for keeping very tight control over your dependencies. (The crux of the point was that a vast number of software evils, and especially maintenance headaches, come from insufficient discipline in managing your dependencies.) Most of this was stuff I already knew in practice (having gotten it deeply ingrained by Tom Leonard at LG and Buzzpad), but having the argument clearly laid out is quite useful for proselytizing these ideas. And he concluded with some very clever ideas about how to quantify the dependencies in your system, and automatically find bad smells in it. (Note to myself: he believes that there may be a .NET version of the JDepend tool -- go see if I can find it.)
And thence home. Not a perfect conference, but well worth the time investment, not least in recharging my programming batteries -- it's really rather inspirational to be immersed in discussions of Good Code like this. Now I just have to bring some of that rigour back to work: time to refactor that C++ code I've been writing for the past couple of weeks...