Management on Bulrush Labs — Richard Tibbetts

Making the Best of Your Time Resting and Vesting

Fri, 30 Jun 2023 21:07:17 +0000

First, go on vacation for a few weeks, to the south of France or something. For a while, you will likely focus on ensuring your team lands nicely and navigating integration processes. You could try climbing the corporate ladder, but you probably won’t if you plan to start another company.

After a few months, you’ll wonder what to do with yourself while you wait for a vesting cliff or finish building your dream home. You can do several valuable things at a large company while resting and vesting.

Identify and Manage the Honey-Badger Developer

Sat, 28 Mar 2015 12:10:00 +0000

A few years back I read Rands’ blog post about the Free Electron developer archetype: “the single most productive developer you’re ever going to meet.” This is a good archetype to understand, identify, recruit, and retain. I would like to discuss another related archetype which can be quite powerful if properly harnessed: The Honey Badger.

“There is no other animal in the kingdom of all animals, as fearless as the crazyass Honey Badger.”

CTO at StreamBase

Tue, 20 Jan 2009 16:43:00 +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.

Steve Vinoski on Extreme Programming at Iona

Fri, 25 Aug 2006 21:06:00 +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

Mon, 23 Jan 2006 11:13:00 +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.