Alan Lewis

2 Year Release Cycle? How About 2 Week Release Cycle

I thought it was funny/interesting how Microsoft is promising a two year release cycle for SQL Server, not because I think they can't do it, but because in my experience a two year release cycle is forever from the perspective of those developing a product.

The place where I work right now is on a two week release cycle. Two weeks! New code is rolled out to the eBay US site every two weeks (releases are called "trains" in eBay parlance, and a whole gaggle of train-related metaphors proliferates throughout the company because of this). In the off weeks, code that rolled out to the main site two trains ago is rolled out to all the international sites -- the delay allows time for the pages to be translated into all the other languages. Upon hearing about this crazy release cycle, many developers are aghast, and some run away in fear, never to be heard from again. But now that I've been around at eBay for a while, it feels like the right thing to do given the business and technical situations. Of course for any given feature there is a longer release cycle to provide enough time for requirements gathering, coding, testing, documentation, etc..., and the time allocated to develop a feature is almost completely decoupled from the release cycle. There is a process in place to figure out how much time is needed, and then when the feature is ready to be released, you know that you can release it almost immediately and everyone can move on to the next thing.

At my last company, I experienced both the good and the bad of release cycles in a more traditional software development environment. The Blaze Advisor development cycle was modeled around a quarterly release cycle. The company management at the time when Blaze Software was an independent, public company thought it important to have a release at least once a quarter to boost quarterly earnings and keep investors excited about the prospects for the product. The way this was done (in theory, at least) was to dedicate the "Engine/Server" team to one release while the "IDE/Development Tools" team worked on the subsequent release. In actuality, there turned out to be contributions from both teams in most releases, but it did enforce the idea that we should always be working on multiple releases at the same time. The point at which this really didn't work was with "the big release" which was first called version 4.0, then version 4.5, then 5.0, then finally 6.0. This release didn't fit the usual model because it required a rewrite of the underlying repository structure - a piece that affected every part of the product. The way that this release was managed was that some of the developers started working on the underlying code four years before the eventual release. Bits and pieces made their way into the product in the intervening releases, while other parts were kept in a separate branch that couldn't yet be merged into the main product. Some features that were initially designed to be part of the big release were pulled in to respond to market pressures, and to lighten the feature set of the big release itself. There were more than half a dozen significant releases of the product while work was being done on 6.0. If the decision had been made to stop work on the product and get 6.0 out the door as soon as possible, the product would have either been eaten alive by the competition, or, more likely, it would not have survived the internal product politics that occurred with the two mergers that happened in the meantime.

So, what have I learned from all of this? Picking the best software release cycle matters. Props to Microsoft on committing to change -- hope it works out for your developers and your users.

Blaze Advisor 6.0 Released

Fair Isaac has released Blaze Advisor 6.0. What the press release doesn’t get across is that this is the most significant release ever of the business rules product.

I worked on Blaze Advisor for four years until I left Fair Isaac in April, 2004, and for most of the time I was there, work was being done on what would turn into the 6.0 release. I’m glad to see it finally be released, because now I can tell everyone how cool it is.

Version 6.0 does away with the two different modes in the IDE (one mode for rule editing, one mode for template development) which was the most irritating thing about previous versions. The new “management properties” feature allows you to add typed metadata to entities in the repository. The new queries feature is fully extensible, and it allows you to write queries off of the metadata or off of the semantic structure of the rules themselves. The coolest thing about the query system is how underneath the easy to use GUI, the queries themselves are written in the Blaze SRL language. You can use the powerful Blaze template system to create complex query templates.

Version 6.0 also changes the repository structure so that it is much easier to share object models, rules, or other entities across multiple projects. There are also many minor enhancements to the IDE that improve the ease of use, such as streamlined editors and the ability to hide the console windows. Even in the early build I tested the small improvements added up to a much more enjoyable experience.

This release is a huge accomplishment, and the entire Blaze development team should be proud. In my opinion it makes competing products look like toys in comparison. Here is an Easter egg in the product that lets you see who did all the hard work: Click Help > About Blaze Advisor, and on the splash screen do a Ctrl + Shift + Click.

Update: I didn't see a link to it in the press release, but on the Fair Isaac website I did find this overview of what's new in Blaze Advisor 6.0. In typically FI fashion this document doesn't dig into the technical details, but it does mention a few features I didn't talk about, like WSIWYG rule maintenance editors and release management.

New Version of Falcon Fraud Manager Embeds Blaze Advisor

My former employer, Fair Isaac, has announced the release of Falcon Fraud Manager 5.1. Falcon is the premier credit card fraud detection software, and it is in use by most of the credit card companies in the United States, and by many others internationally. Chances are that if you have ever had a credit card transaction denied for a reason other than that you were over your limit, it was because Falcon flagged the transaction as potentially fraudulent. This article has more information about Falcon and fraud detection software.

The history behind this release of Falcon goes pretty far back. In 2000, Blaze Software was acquired by Brokat, a German software company (I had joined Blaze just as they were being acquired). Brokat's management was, in my opinion, incompetent, and a couple quarters after the acquisition they were in desperate financial shape. In the summer of 2001, Brokat sold off the Blaze business unit to HNC, who were looking for an rule engine to integrate into Falcon, and were able to purchase Blaze at a fire-sale bargain price. Brokat went bankrupt soon after (good riddance). Less than a year after that, HNC was purchased by Fair Isaac, who picked up Falcon and Blaze Advisor in the process.

About two years ago, a Blaze product manager and I worked on this project by helping the development team in San Diego learn about Blaze Advisor and figure out how best to integrate it in the product. The development team was great to work with, although while working on the project I learned first hand how difficult it is to work with a group of people that aren't readily accessible face-to-face. From what I saw of the product before I left the company almost a year ago, it was looking very cool, and I'm sure it is even more polished now. Congratulations to the Falcon development team!

Is BEA Developing a Standalone Rules Engine?

CNet has an article about an upcoming product line from BEA. There are not many concrete details, although the information is said to come from BEA executives, including the CEO, Albert Chuang. According to CNet, BEA is developing new applications targeted at business users "such as a purchasing director or a business analyst, who don't have technical training but understand how new software should work." Before I even finished the article I thought "BEA is going to release a rules engine!" Supporting this idea is the following statement in the article:

Several specialized software companies as well as larger companies already have similar offerings, which are usually referred to as business process management software....Other companies, such as PegaSystems, sell so-called rules engines that let businesspeople modify company policies, such as changing the limit on a customer's credit card.

Business rules engine vendors such as Fair Isaac and ILOG talk about empowering "business analysts", so the fact that the article mentioned that target market tipped me off to the possibility that BEA might be thinking of entering this space. This would not be much of a stretch, because BEA has for some time included a rule engine in some of its products, such as WebLogic Portal.

A large vendor like BEA, Microsoft, or IBM has some chance for success in the business rules market. They obviously have large development resources at their disposal. There is also potential for them to offer a more complete software stack that includes business rules than any of the dedicated rules engine vendors can. But having an integrated stack can also work against them, because the more business rules are embedded or integrated in a single stack, the harder it is to develop a rules product that insulates business users from the complexity of the other parts of the stack.

Judging from what is in the article, I think it is most likely that the new BEA product line includes both a business process management product and a business rule engine product. If I'm right, it remains to be seen whether this is something actually new and interesting, or if it is yet another half-baked entry in the business process and business rules markets.

Daniel Selman on Business Rule Language Standardization

Daniel Selman of ILOG has written in favor of creating a business rule language standard. He understands that not in order to create a useful standard not only must the language be specified, but the execution semantics must be specified as well:

Underlying the request for a standard business rule language lurks the more difficult issue of semantic interoperability between rule engines. It is clearly not enough to have a standard XML Schema for business rules, and then have the rules execute differently on two rule engines!

Read the article and my reply on javarules.org.