Here at QCon, well-known Java developer Cameron Purdy gave a fun talk called "10 Ways to Botch Enterprise Java Scalability and Reliability".  (He also gave this talk at JavaOne.) While I could quibble with Cameron's counting---there were actually more like 16 points thanks to some numerical overloading---I liked his content.  He echoes many of the antipatterns from Release It.   In particular, he talks about the problem I call "Unbounded Result Sets".

It's often been the case that a difficult problem can be made easier by transforming it into a different representation.  Nowhere is that more true than in mathematics and the pseudo-mathematical realm of programming languages. For example, LISP, Python, and Ruby all offer beautiful and concise constructs for operating on lists of things.  In each of them, you can make a function which iterates across a list, performing some operation on each element, and returning the resulting list.

Eric Evans, author of Domain-Driven Design and founder of Domain Language, embodies the philosophical side of programming. He gave a wonderful talk on "Strategic Design".  During this talk, he stated a number of maxims that are worth pondering. "Not all of a large system will be well designed." "There are always multiple models." "The diagram is not the model, but it is an expression of part of the model." These are not principles to be followed, Evans says.

Kent Beck spoke with his characteristic mix of humor, intelligence, and empathy.  Throughout his career, Kent has brought a consistently humanistic view of development.  That is, software is written by humans--emotional, fallible, creative, and messy--for other humans.  Any attempt to treat development as robotic will end in tears. During his keynote, Kent talked about engaging people through appreciative inquiry.  This is a learnable technique, based in human psychology, that helps focus on positive attributes.

I'm at QCon San Francisco this week.  (An aside: after being a speaker at No Fluff, Just Stuff, it's interesting to be the audience again.  As usual, on returning from travels in a different domain, one has a new perspective on familiar scenes.) This conference targets senior developers, architects, and project managers.  One of the very appealing things is the track on "Architectures you've always wondered about".  This coveres high-volume architectures for sites such as LinkedIn and eBay as well as other networked applications like Second Life.

Has anyone ever been happy to listen to their own voice? Probably not. The Pragmatic Podcast is up and running on the redesigned Pragmatic Programmers site. In the first episode, Daniel Steinberg interviews me about the book. Also available on iTunes.

Here's an list of books about putting time to work as your own weapon, instead of being victimized by it:  The Mind of War  The Art of Maneuver  Lean Thinking  Birth of the Chaordic Age  Agile Software Development  Lean Software Development  Software by Numbers

While I was writing Release It!, I was influenced by James R. Chile's book Inviting Disaster. One of Chile's sources is Normal Accidents, by Charles Perrow. I've just started reading, and even the first two pages offer great insight. Normal Accidents describes systems that are inherently unstable, to the point that system failures are inevitable and should be expected.  These "normal" accidents result from systems that exhibit the characteristics of high "interactive complexity" and "tight coupling".

"Scalable" is a tricky word. We use it like there's one single definition. We speak as if it's binary: this architecture is scalable, that one isn't. The first really tough thing about scalability is finding a useful definition. Here's the one I use: Marginal revenue / transaction > Marginal cost / transaction The cost per transaction has to account for all cost factors: bandwidth, server capacity, physical infrastructure, administration, operations, backups, and the cost of capital.

"Is software Engineering, or is it Art?" Debate between the Artisans and the Engineers has simmered, and occasionally boiled, since the very introduction of the phrase "Software Engineering".  I won't restate all the points on both sides here, since I would surely forget someone's pet argument, and also because I see no need to be redundant. Deep in my heart, I believe that building programs is art and architecture, but not engineering.