As of yesterday afternoon, a subset of the Jazz.net community site is now publicly available with some basic information on Jazz.
Also the Community page has some information on the “Building Jazz with Jazz” BoF session we’ll be doing at EclipseCon in a few weeks. If you see me at the BoF, please stop over and say hi.
This video must be seen to be believed.
From the poster’s description:
Microsoft sent this tape to retailers to explain the benefits of Windows 386. Boring until the 7 minute mark when the production is taken over by crack-smoking monkeys.
Via Josh.
My wife Chunhui was born and raised in Jinan, China. One of the fun challenges of an American-Chinese marriage is to recognize the subtle cultural differences so that you don’t unintentionally violate the other person’s cultural assumptions and mores. Recently we had an interesting discussion with another American-Chinese couple on the different customs with regards to finishing ones meal.
We observed that in American culture, you’re expected to take what food you want from the center of the table, and finish what you take. In Chinese culture, you can take food from the table, but other people at the table are just as likely to eagerly give you food in a spirit of generosity, especially if they think you like something. What makes your Chinese friends and family think that you like something? If you finish it!
This can easily lead to some crossed cultural wires. Americans feel culturally-obligated to finish what they take, and Chinese people feel culturally-obligated to give more food to someone who seems to enjoy it. The trick is that when you want to be done with a particular dish, you simply leave a small but visible portion of the food on your plate, so none of your Chinese friends and family assume that you want more. This way you don’t overeat, and you don’t get into an awkward “No, I really am full!” conversation with your Chinese friends and family as they try to put more food on your plate.
Marcus Aurelius begins his Meditations by giving thanks for the qualities he gained through observation of others who exhibited those qualities. On a much humbler scale, I recently reflected that my personality has changed as a result of observing the constructive behavior of my project leaders.
One example of this happened at the end of 2006. The day before we were supposed to freeze code for the year, I assisted another developer on a late-breaking severe defect. Unfortunately we didn’t test the fix adequately and it led to another defect which I discovered two hours after the final scheduled build completed. Sleep-deprived and stressed, I forgot about the code freeze and delivered a fix to the second defect. Fifteen minutes after delivering the patch, one of our senior technical people sent out an email reminding everyone that the codebase was frozen. I felt horrible because I’d committed a major faux pas at the most critical period in the development cycle. With great embarrassment, I sent a follow-up email to the project, notifying them of my mistake.
The next morning I came into the RTP lab for the end-game planning call with the PMC and component leads. I went to a meeting room and found John Wiegand and Scott Rich, who at this point were fully aware of the mistake I made. With a sheepish smile, I asked “Can I buy anyone a coffee?” Scott replied “You’re not forgiven that easily. What you did last night requires coffee and donuts.” John said, “Well, we all screw up from time to time, and the important thing is that you recognized the mistake and, to look at the positive aspect of it, the feature now works.” And that was that. In the end it turned out that there were a few other lingering bugs in the final scheduled build so we did one more build and all was well.
Another example was my mid-year checkpoint with Erich Gamma, reviewing the progress on the subsystem that I lead. My team was struggling at the time. In some very new technical territory, we were progressing more slowly than anyone would have liked. I was dreading the call, because Erich’s sort of a professional hero of mine, so I really wasn’t looking forward to hearing him tell me that things weren’t going well. But the call wasn’t like that at all. He began by reflecting on the things we’d accomplished and what had gone well. Only after a few minutes of discussing accomplishments did he gently segue into the discussion of areas that needed improvement. We prioritized a list of architectural features and user scenarios, and then worked through the details of what my team would need from other teams to succeed. I left the call feeling energized about what I was confident we could achieve, and over the past six months, I’m confident that we’ve met or exceeded those expectations.
Some excerpts below. Click on the person’s name for the full content.
There’s a phrase from systems engineering that applies here, the principal of least astonishment. When an abstraction fails, a well-designed one will (hopefully) fail in predictable ways. It’s when an abstraction fails and it fails in an unexpected way that we have evidence of a leaky abstraction. Unfortunately, I don’t think this kind of behavior is avoidable, although it is the case that tracing down the roots of such failures and then refactoring the stuff at those roots will generally lead to a better separation of concerns. The problem is, in software, we generally never take the time to do that refactoring, and so we occasionally continue to be astonished at the most inopportune times.
Josh:
I’ve struggled with this issue too.
I haven’t come to any concrete conclusions either other than to emphasize that abstraction *costs*.
And not only does it cost, but it usually costs *more* than we think it does – because the person designing the abstraction is not the same person who has to invest the effort to learn how the abstraction works later on.
According to Joel all abstractions are leaky. When this happens transparency helps. Both are required, because I believe people who need to know about abstraction and transparency are different. Abstraction is for users, transparency is for problem solvers.