Month: January 2008

Ice cream may, in fact, be eternal

When the New York Times writes about the near-demise and miraculous return from tax-evasion death of a Cambridge, MA ice-cream maker, you know there’s something special going on. And, in fact, there is.

To my astonishment, in the nearly seven years of this blog I’ve only written about Toscanini’s once, in conjunction with last year’s Ig Nobel awards. But my roots with Toscanini’s go back right to 2000, to almost the day I first set foot on MIT’s campus, where at the time there was a Tosci’s under the entry stairs at the west campus student center, one in Central Square, and one in the same block just south of Harvard Square as the stationery store. They had basil ice cream. Basil ice cream. Like the pure essence of Italian summer, like back yard gardens, like pure golden-green herbal explosions in your mouth. I was instantly hooked.

I only tasted basil ice cream twice, but there were other flavors. Green tea. Guinness, of course. And khulfee and burnt caramel and all the other spectacular flavors that they had. Completely unlike every other ice cream that there ever was.

With the Atlantic opening up their paywall, you get a little better sense of how good it really was. Ice Cream for Beginners – 00.06 describes the origins of burnt caramel, and a little of the creative atmosphere of the place. As well as how he might have gotten into the tax problems in the first place: the bit about Adam Simha wandering into the kitchen to filch ingredients probably raised no eyebrows in the happy-go-lucky creative late 90s but makes me wonder now how many other employees thought of Tosci’s as their own version of Andy Warhol’s Factory, or their Stop’n’Shop.

But all of this pales at the thought that I might be able to taste basil ice cream again. Perhaps I ought to drop Gus Rancatore a line. Right now, he might be susceptible to special requests.

Sonian: Outsourcing scalability to Amazon

A former co-worker of mine, Jeff Richards, has surfaced at Sonian Networks, which is offering a new on-demand email archiving service. What’s unique about Sonian Archive SA2 is its architecture. It’s built almost entirely using Amazon Web Services, and is architected in such a way that each customer gets their own “virtual stack.” As additional customers are added, the service scales transparently, according to the Amazon Web Services Blog.

It’s a pretty cool play, and the price sounds right, at $3 per mailbox per month.

Edwards out. At least until the convention

John Edwards bowing out of the race is no surprise after South Carolina, and I guess neither is his refusal to endorse a candidate. I think he’s setting himself up as a kingmaker, and unless either Hillary or Obama are particularly persuasive, he’ll probably hold off on an endorsement as long as possible. But popular also-rans don’t always help sway the party’s decision. I’m pretty sure John Kerry’s selection wasn’t influenced by Howard Dean.

The application is the perimeter

An interesting trio of articles hit yesterday. One is a summary of industry response to the announcement that President Bush intends to fund a massive network security initiative. The money quote is from Veracode’s co-founder and CTO, Chris Wysopal, who compares the initiative to “posting police on every corner in a dangerous neighborhood, but failing to fix shoddy locks on the houses.” The second is an article by Chris about improving development processes to reduce the number of security-related flaws that go into your software in the first place. And the third is an interview with Chris, co-founder and chief scientist Christien Rioux, and senior director of security research Chris Eng (the three Chris’) about the founding of Veracode.

The interesting bit about President Bush’s proposal is that it proposes to put so much money at the network layer while neglecting to recognize a key fact: the application has become the perimeter. All the network security in the world won’t stop an attack against a flawed application that is sitting on an open Port 80—as it has to be to be accessible over the Web—and that, if compromised, can hand an attacker access to sensitive customer and transaction data as well as potentially compromise other machines inside the company’s infrastructure.

The world has changed. In the early 90s, the only security that anyone thought about was viruses and the attack vector was floppies. The advent of the Internet brought about the rise of the network firewall and other network layer technologies. When attackers proved to be able to route around that, the machine-level firewall appeared, signalling a shift of the perimeter to individual computers and servers. But no firewall can guard against an intrusion that occurs in the form of a fraudulent interaction with an application, using the application’s own interfaces and protocols. To guard against that, the application has to be hardened.

In short, the administration’s focus on network security proposes to spend lots of money on a problem that hasn’t been at the real perimeter for about eight years now. Worse, it proposes to do it by placing “sensors” into government and private networks, which sounds like the introduction of additional points of vulnerability to me.

Chris’s article proposes an alternative to doing this, an approach that has actually had a fair amount of success at Microsoft: focus on how you can write secure code and not introduce the flaws to begin with. Because once you recognize that the application is a critical part of the security perimeter, the question should become: how do I catch those potentially exploitable flaws before they reach my production environment?

New York to Boston: Winnahs (ssh!)

I think the New York Times is getting a little ahead of itself by preemptively declaring Boston a city with three winning teams. Someone touch wood, quick.

Of course, the article is “balanced” enough to include the dismal history of our teams. Two favorite passages: “Last spring, the team was accused of losing games on purpose so it could finish with the N.B.A.’s worst record and increase its chances of landing the No. 1 or 2 pick in the draft. The Celtics botched that, too” and “The Patriots’ history has been the most pathetic. Beyond frequent 3-13 seasons, their first true home, Schaefer Stadium, opened in 1971 with massive toilet overflows and barely improved thereafter.”

Revised Glee Club record date: 1951

While doing some Wikipedia related research last night, I stumbled across something interesting. The record album Songs of the University of Virginia, which I’ve long thought was recorded in 1947 based on photographic evidence from the University archives, was apparently not released until 1951. How do I know this? From a 1951 Washington Post article, of all places.

If it seems funny that a Paper of Record would cover goings-on at the University, consider that the WaPo didn’t get that reputation until the time of Woodward and Bernstein. Prior to that, it was viewed as a sleepy society paper, and apparently not above covering the doings down Route 29.

Also interesting in the article was the following: confirmation of the 1871 founding date (the record was said to honor the eightieth anniversary of the founding of the Glee Club); identification of the Beta Chi chapter of Kappa Kappa Psi (the “national honorary band fraternity”) as the sponsor—an organization that, as far as I can tell, isn’t on Grounds any more; and identification of Thomas Jefferson Smith III of McRae, Georgia, as the co-chairman of the project (with Jack Hardy) and president of the Glee Club at that time. Plus, apparently, the Music Department was resident in Minor Hall then, rather than Old Cabell.

But the main point of the article for me was its claim regarding the aim of the project, which I reproduce here in its entirety:

Many songs which should be a part of University heritage have been lost, some because they were set to popular tunes of the times and died out when the tunes were forgotten, some because a college generation is a brief time in the life of the school. Words to these songs can be found in university publications, but no one sings them because the tunes have been lost.

The famous “wah-who-wah” [sic] of the University’s alma mater is an example of these lost songs. Once it was sung; then all the band music for it was lost. Now no one knows the music, and it has become a yell, used chiefly at football games.

So “Songs of the University of Virginia” will preserve songs which otherwise might be lost in future years. The album will help alumni of present and future to recreate the days of “purple shadows” on the lawn.

The irony, of course, is that the album itself faded almost completely into obscurity too. Note the part about wa-hoo-wa—they are referring to the song about which the “Good Old Song” was written (no, the “Good Old Song” is not self-referential!), which is lost.

Radical transparency, part 1

My last post about Agile software development processes and corporate culture addressed one of the major challenges of adopting Agile within a company: the need to get the buy-in of other stakeholders, such as sales, marketing, and the executive team, who think in terms of specs-as-contracts rather than features as conversations. I got feedback from at least one reader who said, quite rightly, that this is very hard to do on both sides. It’s hard for developers to be open and transparent with sales and marketing, and even with product management. I’ll talk a little bit about the second challenge today, and circle back around to the first one another time.

Why should developers have difficulty achieving transparent communication with product management? It shouldn’t be hard, right? After all, product management is the face of the product to the rest of the company, and the face of the market to development. It’s a role that is accustomed by definition to speaking to multiple audiences, and spends more time than just about any non-technical role in communication with engineering. So it should be easy to build that conversation, right?

Sadly, all too often, this isn’t true. Product managers, as has been said eloquently by others, are detail oriented and prone to micromanaging. They tend to stomp on the engineer’s turf by talking implementation and second-guessing the developer’s expertise. Worse, product managers force firm commitments with outside stakeholders on delivery dates for functionality of uncertain scope; often, they actually make the commitment without consulting development. Then when reality strikes, the project becomes a deathmarch and the developer is working nights and weekends trying to make an unrealistic release date that the product manager casually committed to. Lastly, remember that Agile as a whole came out of a deep dissatisfaction with the way that software development projects were relating to the market, and for some product managers were the embodiment of that problem—feature creep, churn, deal-driven “vision” that whiplashes development according to the whims of the latest sales prospect.

Building trust between developers and product managers is really hard for both the structural reasons cited above, and any trust that’s built is going to be fragile at best. So how do you get over these hurdles?

That’s a little like asking, How can I be a good spouse? Because the relationship between product managers and developers has to be a long term one. It’s built interaction by interaction, by showing that one party can trust the other to do its part, by sharing responsibility. And by being open: about the market challenges, about the problems faced by sales, about the competitive landscape, and about the technical challenges that stand in the way of success.

One very simple way to build trust and get to a shared understanding of goals is to build in frequent working meetings. Many Agile processes, such as Scrum, have these built-in already in the form of daily or thrice-weekly standups, where developers can articulate progress and discuss challenges. If your team is doing this, participate. Make sure that you communicate an appropriate level of detail about what you are doing about the release. Often times, developers have no idea that you’re off talking to customers about the features that they are working on, and many find the opportunity to get detailed feedback helpful. But save the discussions of features outside the iteration, future roadmap concerns, and other things for other meetings, probably with the dev manager and maybe an architect or a designer. Keep focused on the business at hand. But even more than talking, it’s important to listen. I found the most satisfactory standups to be the ones where I actively listened, maybe asked clarifying questions, but mostly communicated to the team that I respected their time and energy and judgment. Once the developers see you in that context and get that you really understand where their challenges are, there will be one less barrier between you and them.

How secure is Mac OS X? And how long will it stay that way?

I have been struck by an occasional series of Daring Fireball posts in which the question is raised: What explains the relative lack of Mac for-profit malware? The conclusion seems to be that there are two factors: a system-dynamics-based answer that says that the overwhelming Windows market share keeps the attention of malware authors; an aspect of user culture; and some element of technical superiority on the platform.

I would argue that there is yet another factor: developer education. After all, no matter how secure the OS, if an application that is widely distributed on it has flaws, the machine is vulnerable. But Objective C is not exactly a trivial language to pick up and learn, and writing in Carbon doesn’t buy you any development ease points either. So Mac software vendors have to be fairly well educated, and presumably in that process they learn how to avoid introducing flaws like potential buffer overflows. Of course, Apple makes the majority of the software that many casual Mac users use every day, too: Mail, Safari, iTunes, iPhoto… and the company has proven to have a reasonable track record with avoiding exploitable issues there.

The big exception, though, is QuickTime: cross-platform, widely used on websites, widely installed on PCs thanks to iTunes, and vulnerable. There are in the range of 50-60 CERT vulnerability notes indicating potentially exploitable flaws in QuickTime. So clearly Apple doesn’t have a virtuous monopoly on programming skill.

Compare this, though, to the history for iTunes, also cross platform, also widely installed: just two vulnerabilities that affect iTunes directly. The rest are vulnerabilities rising from QuickTime. The suggestion here is that Apple programmers defer much more to the lower level frameworks provided by Apple than their Windows counterparts—consider the wide impact of something like an exploitable buffer overflow in JPG handling in Windows, which affected the OS, AND Microsoft Office, AND half a dozen other Microsoft products, because the vulnerable code was distributed with each application rather than centralized at the OS level.

So, OK, a new theory: because Mac OS X apps rely heavily on centralized system frameworks, more attention can be devoted to keeping those central resources secure. That in turn keeps the OS secure.

Which is why the news that Apple introduced a way to hide program behavior into its port of the DTrace tool is so alarming. For the uninitiated, DTrace is an open source tracing and debugging utility that allows inspecting the internals of program operations—essential for software development, and also for security testing. Apple’s implementation introduces a way that software authors can flag their process so that it is ignored by DTrace (the soon to be infamous PT_DENY_ATTACH request).

From a security perspective, this won’t have a lot of effect on researchers’ ability to observe Apple applications. Following Chris Wysopal’s admonition to use tools that are free from interaction with the platform being analyzed means that security researchers will use non-crippled tools to analyze what’s going on. But it sets a very bad precedent. By creating a way to hide what software is doing on Mac OS X, Apple creates something that smells a lot like a rootkit. And we know what sort of trouble that gets people into.

Best albums of 2007

I had been meaning to post this for a while and finally got around to it. I couldn’t quite pull off a top 10 for 2007, but I did manage a top 12, and you can find it on Lists of Bests (where you can create your own list of “Best of 2007” and see how your tastes stack up against other LoB users).

My number one, unsurprisingly, was Radiohead’s In Rainbows, which stayed at the top of my playlist for a good three months—longer than any other album this year. Right behind it, of course, was Black Francis’s Bluefinger. And behind that? A few surprises. Marissa Nadler’s Bird on the Water totally pwned me the first time I heard it, and it’s one of the few albums I listened to twice in a row this year. Only a little weakness in some of the lyrics kept it out of the top 2. M.I.A.’s Kala, on the other hand, snuck past me when it came out; it took her KEXP in-studio appearance to get me to listen to it again, and now I’m hooked. And Feist’s The Reminder is a nice chocolate ice-cream of an album, in that it’s probably unhealthy how many times I spun it this year to enjoy its sweet pop hooks.

The rest of the list is probably unsurprising—Ga Ga Ga Ga Ga Ga, new records from Iron & Wine, the White Stripes, the Arcade Fire, and PJ Harvey. But two were kind of surprising to me personally. I didn’t expect Nick Cave’s side project Grinderman to be as much fun as it is, and I was totally blown away by Rickie Lee Jones’s rambling, honest, and deeply devotional Sermon on Exposition Boulevard—highly recommended for all, and a must listen if you’re a seminarian. (Ahem).

If Agile is about conversations, who’s listening?

The other category I planned to start almost two weeks ago was this one—it’s high time that I started writing more systematically about product management. And what better place to start than with the latest craze, agile software development?

As Steve Johnson at the Product Management blog at Pragmatic Marketing is fond of pointing out, Agile (as it’s usually capitalized) isn’t exactly new, having appeared on the horizon back in 2001 with the Agile Manifesto. But it has taken a long time to achieve anything like industry momentum. Why? In my experience, it’s because Agile requires a culture change throughout the whole company, not just in engineering and product management but also support, product marketing, and (most importantly) sales.

So why should the impact on all these other groups make it harder to adopt agile development processes? Well, let’s look at some of the top level statements of the Agile Manifesto:

  • Individuals and interactions over processes and tools: If your software development process depends on ongoing communication with the key members, what about organizations like sales who aren’t part of the ongoing conversation?
  • Responding to change over following a plan: Often in agile, this translates into much less complete planning artifacts. What happens when sales starts to fill in the blanks in the plans themselves—say, when talking to a customer?

The reality, of course, is that going Agile doesn’t lessen the requirement to communicate frequently with sales and other external stakeholders. If anything, it increases the importance of doing so. If the point of Agile is to deliver frequent software releases that add real value to the customer, then including the customer and the parts of the organization who talk with current and potential customers every day is absolutely critical to success.

In fact, Agile as a philosophy shares a lot with another manifesto of similar vintage, the Cluetrain Manifesto, which states that markets are conversations too. See a theme? There is a definite evolution in both Agile and Cluetrain away from central planning and delivery of work products (internal deliverables or actual products) as fiats, made more palatable with heavy doses of promotion and/or process, and toward ongoing conversation, collaboration, and cooperation with the other stakeholders in the process of creating value.

So at some level these two types of conversations—developers with product managers, marketers with the market—really need to become one. And that has profound implications on organizational structures, marketing plans, and nearly everything else that companies do. Is it any wonder that Agile took so long to take off?

I’ll be writing a little more about Agile from time to time, as I reflect on the lessons I learned from adopting an agile development process at iET Solutions and those that I learn at my new gig, Veracode.

Found: my grandfather’s mill

My grandfather worked at an old fashioned water-powered mill, making flour and animal feed for the county, during the first years of his post-college life and of his marriage. The family has always known where the mill was—right around the corner from the Brackbill farm—but not what has become of it in its post-mill existence.

This weekend I learned that the mill now is the home of an antiquarian bookseller.

(Yes, I think God has a sense of humor. What better way to ensure I make a pilgrimage to uncover part of my Pop-pop’s history than to make sure it’s filled with books?)

The other ironic part: the mill is practically just around the corner from the family farm where I’ve attended reunions my whole life. Why ironic? Because I’ve been reading daily complaints in my grandfather’s diary about how he couldn’t get to work on time. It surely wasn’t because of traffic that he had problems getting there…

Rested and ready

A few days off from the blog were really necessary this week for me to recharge. My silence here belies the work that I was doing elsewhere, though I’m not quite ready to take that work public yet.

It’s been pretty quiet all around, though, and I’m definitely ready to start a new challenge tomorrow in my new position as director of product management at Veracode. What’s Veracode? Well, it’s a fairly unique company—it provides an application security service that identifies vulnerabilities in software binaries. By providing a service that does not require access to application source code, the company can do some fairly interesting things—one-time scans on behalf of a company that is purchasing software, for instance, or single-shot audits for software vendors. I’m pretty excited about the opportunity to work with the team there and to address some of the challenges there in taking their services to the next level.

For a little more flavor of the type of world that Veracode operates in, check out the company blog, Zero in a Bit. Very interesting posts about security, application development, and the disclosure process.

Planted

There are three texts that have been in my mind since my grandfather’s funeral service today. One, the morbidly funny Laurie Anderson line from “Gravity’s Angel”:

And at his funeral all his friends stood around looking said. But they were really thinking of all the ham and cheese sandwiches in the next room. And everybody used to hang around him. And I know why. They said: There but for the grace of the angels go I.

Because you know what: after a sleepless night, and the morning viewing, and the service, and walking out to the cemetery in the rain, and placing a flower on the casket, and walking back, I found myself frightfully hungry. So I got two ham salad sandwiches and listened to the guests reminisce about my Pop-Pop, and drank coffee. And I said: So. This is life reminding me that I’m still in it.

Quotation number 2: Also from Laurie Anderson, “World Without End”:

When my father died we put him in the ground
When my father died it was like a whole library
Had burned down. World without end remember me.

Because all day long I wanted to turn to him and ask a question about this relative, or that one, or about his life in Kinzers, or something about the house. And someone had taken all the books away.

The final quotation running through my head is a part of one of the verses that was read at the funeral. This version is from the NRSV (I Corinthians 15:35-57):

But someone will ask, “How are the dead raised? With what kind of body do they come?” Fool! What you sow does not come to life unless it dies. And as for what you sow, you do not sow the body that is to be, but a bare seed, perhaps of wheat or of some other grain. But God gives it a body as he has chosen…

So it is with the resurrection of the dead. What is sown is perishable, what is raised is imperishable. It is sown in dishonour, it is raised in glory. It is sown in weakness, it is raised in power. It is sown a physical body, it is raised a spiritual body. If there is a physical body, there is also a spiritual body. Thus it is written, “The first man, Adam, became a living being”; the last Adam became a life-giving spirit. But it is not the spiritual that is first, but the physical, and then the spiritual. The first man was from the earth, a man of dust; the second man is from heaven. As was the man of dust, so are those who are of the dust; and as is the man of heaven, so are those who are of heaven. Just as we have borne the image of the man of dust, we will also bear the image of the man of heaven.

What I am saying, brothers and sisters, is this: flesh and blood cannot inherit the kingdom of God, nor does the perishable inherit the imperishable. Listen, I will tell you a mystery! We will not all die, but we will all be changed, in a moment, in the twinkling of an eye, at the last trumpet. For the trumpet will sound, and the dead will be raised imperishable, and we will be changed. For this perishable body must put on imperishability, and this mortal body must put on immortality. When this perishable body puts on imperishability, and this mortal body puts on immortality, then the saying that is written will be fulfilled:

“Death has been swallowed up in victory.”
“Where, O death, is your victory?
Where, O death, is your sting?”

And really, if I didn’t learn anything at all from my grandfather, I learned to listen to the preacher, and the Bible, and chew over the theology, and argue about it, sometimes vehemently, and then to come back to it over and over again. But this much I know: we have planted my grandfather, but he continues to grow in us.

Moving on

Career news: I am leaving iET Solutions to pursue other opportunities. It’s been a great ride, and I’ve learned a lot about the enterprise software business, from working with analysts to managing cross-market requirements and building roadmaps for complex suites of technology.

My favorite project is the one that we just shipped: we took the old, C++/MFC Windows client for our application suite and rewrote it from the ground up in .NET technologies, specifically the Windows Presentation Foundation and the Windows Communication Foundation. It’s a beautiful app now, as you would expect from a program with a XAML UI, and even better, it’s more usable because we took the opportunity to do a lot of redesign of basic features in the process. My favorite metric: going from five toolbars to one. And it was an important rewrite, because it gave us a ton more flexibility to add new features as well as giving us a better face to the market.

The team at iET Solutions is really talented, and I’m grateful they gave me a chance to shine. I look forward to continuing to see good analyst coverage on them and hearing good things about them in the future.

I’m taking a little break from the working world now, just a week off. I’ll be back with more updates about where I land once I start in a week. I will probably post a few things over the next week from the funeral and about my family’s history in Pennsylvania.

Documenting a vanishing landscape

Appomattox court house tavern building

Only natural, I suppose, that my thoughts are drawn to the past this week. A new online image collection at the University of Virginia Library, the Frances Benjamin Johnston Photograph Collection is helping to foster that nostalgia with a series of photos of vernacular Virginia buildings taken between 1929 and 1935. The buildings, ranging from the Tuckahoe mansion to a debtor’s prison, have much of the quiet, slightly shabby grace that still lingered in parts of the Tidewater when I grew up (though increasingly you had to go out to Gloucester or south to Chesapeake to find it—it vanished from the Peninsula a long time ago).

I looked through the list but was only able to find a few buildings that I am directly familiar with. But the names are an evocative litany of the Tidewater and the Piedmont: Abingdon. Apperson Farm. Bowman’s Folly. Bruton Parish. Cabell House. The Glebe. The Hugh Mercer Apothecary Shop. Kempsville. Kenmore. Kittiewan. Landsdowne. Mangohick. Pohick. Mantua. Midlothian Pike. Monticola. Powhatan. Poplar Grove. Rich Neck. Sweet Hall. Warwick. Yancey’s Mill. Yeocomico Church.