Hyperextended Metaphor » Management

CTO at StreamBase

tibbetts — Tue, 20 Jan 2009 20:43:41 +0000

Welcome Mass High Tech readers and others. As many new visitors to my blog know, I’ve recently taken on the position of CTO at StreamBase, the company which came out of my graduate research at MIT and where I have until recently been Chief Architect. Old visitors to my blog surprised by this post can read the official StreamBase Press release, or the Mass High Tech article linked above.

StreamBase is a top vendor for Complex Event Processing (CEP) software in Capital Markets, Defense, and other sectors. Customers use our software to implement business applications which can identify, transform, archive, and respond to events, with sub-millisecond latency, at hundreds of thousands of events per second. Doing all that requires a combination of programming language design, compiler technology, database technology, networking, performance, and developer tools. I’m lucky, because this matches my own interests precisely. In my new role, I’ll continue to be hands on with all these areas of technology, and expand my work with StreamBase customers and industry organizations.

Nothing to See Here is my low traffic personal blog, on which I comment about a fair number of things, but basically never talk about complex event processing. It keeps life simpler. If you would like to see me blogging in an official capacity about CEP, keep an eye on the StreamBase Event Processing Blog.

Steve Vinoski on Extreme Programming at Iona

tibbetts — Sat, 26 Aug 2006 01:06:08 +0000

Thursday at StreamBase we had a lunch talk by Steve Vinoski, Chief Engineer at Iona Software. Our CEO (Barry Morris) is former CEO of Iona, and he asked Steve to talk to use about Extreme Programming (XP). Iona switched to the extreme programming model nearly 10 years ago, and was the first large product company to change over. Their experiences were documented in a paper by Jim Watson.
At StreamBase we use several agile development techniques, but are not faithful to any one methodology. I expected the talk to be about how being faithful to XP was a great thing for Iona. From my reading, I understood that XP demanded total fidelity in order to succeed. Every one of their twelve points is supposed to be critically interdependent and synergistic.
What I learned from Vinoski was that drinking the koolaid is not required. Iona worked directly with Kent Beck, originator of XP. Apparently in person he is a lot more laid back than in his writing. For example, Iona didn’t find pair programming particularly worthwhile, and ended up giving their engineers back their private spaces. They never implemented a 40 hour work week. They do test first programming, but not religiously. They try to fit development into 2 week iterations, but again are not strictly attatched to it. For example, documentation work generally lags behind development, and frequently their iterations don’t actually result in customer-visible functionality.
The other thing I found interesting was that Iona was another example of a pattern I see in extreme programming success stories. At Iona, engineering was a mess before they switched to XP. They didn’t have nightly builds, good testing, or a consistent view of the source tree. Releases were made in an ad-hoc manner, and there was little or no visibilty or feedback in the engineering process. With the introduction of XP they were able to get many of these issues under control. Like many XP stories, things started out really bad. With the introduction of XP they got much better. I can see two plausible explanations for the frequency of this story. It may be that only companies in a lot of pain are able to marshall the resources to change to XP, and so only troubled companies try it. But it may also be that XP is only worth attempting if your organization is on the rocks. Otherwise, moving to a more moderated agile process may be the way to go.
At StreamBase we use many agile techniques. We benefit greatly from automated testing, and have good test coverage. We use a branch driven development model, and keep trunk in a shippable state. We break projects into small milestones (a few weeks, and we keep making them smaller) so that development can be visible. We keep developers as close to customers as possible. And we remain introspective, looking for other opportunities to improve on our process. Many innovations in software engineering come under the banner of agile development today. I think any engineering organization can benefit from learning more about extreme programming and other agile methologies. But I think taking a moderate approach is prudent, unless your organization is in a great deal of pain.

Stop Energy

tibbetts — Mon, 23 Jan 2006 15:13:47 +0000

A friend just used the phrase Stop Energy to describe part of the open software development process. I hadn’t heard the term before, and so I had to look it up. Stop Energy is the ambient energy in an open development process available to stop any forward motion. Stop Energy manifests as technical (and sometimes non-technical) stone throwing directed at anyone proposing any change. An excess of stop energy in a process is crippling. Unfortunately, stop energy seems to increase with the number of participants.

Stop energy isn’t uniformly bad, in my opinion. Sometimes it is necessary to prevent bad changes from happening. But far more often is a free software project (or any other open process) killed by stagnation and a loss of volunteers than by an excess of development and participation.

I’ve personally witness stop energy in several groups. Sometimes stop energy is the result of curmudgeons who don’t want anything to change, or of people who want to retain control of previous design decisions. But quite often Stop Energy and Yak Shaving go together. Yak shaving is a catch-all term for the work you need to do before you can do the work you should do. Often stop energy manifests itself as requirement creep. “You can’t add a new method to the dispatcher until we totally redesign the dispatcher like I’ve been meaning to do for 2 years.” This kind of stop energy can be particularly difficult for new participants in the process to overcome.

Having a term like Stop Energy I hope will help me to identify it in myself and others, and try to overcome it. It is potentially a very destructive force.