It was Joel Spolsky who once penned the following heresy:
Pick your core business competencies and goals, and do those in house. If you're a software company, writing excellent code is how you're going to succeed. Go ahead and outsource the company cafeteria and the CD-ROM duplication. If you're a pharmaceutical company, write software for drug research, but don't write your own accounting package. If you're a web accounting service, write your own accounting package, but don't try to create your own magazine ads. If you have customers, never outsource customer service.
The new build system for Bricolage is complex. It has to be. Bricolage is complex and frankly, many CPAN modules aren't that easy to install. Now when you throw into the mix our dependencies on Apache, mod_perl, PostgreSQL and a few other things, the build process gets very difficult. This is the major complaint with Bricolage. We're trying to eliminate the complaint for the next version, but trying to write code to manage those dependencies is a nightmare, so the switch to a state machine to track the rules seemed like a good idea.
The we discovered the limited support for state machines in Perl.
If something is a widely used, well-supported module, we'll cheerfully reuse it. It makes our life easier. If something isn't widely used (and state machines fall in the category) but it's well tested, there's still a good chance we'll use it. Heck, if it's not well-tested but it's too simple to fail or would be a quick rewrite, we'll still use it. But when something is complicated, not widely used, poorly documented, central to our business needs and the test suite consists solely of one test that ensures the module loaded, I'm hard-pressed to justify using something from the CPAN.
Because of the problems we were having with state machines from the CPAN, Theory decided to write a rules module to allow us to arbitrarily parse rules. Hopefully it will be on the CPAN soon. It's actually documented and has gobs of tests. There will probably be a few changes before it's ready, but I feel much more comfortable about this code than the alternatives. Too much is riding on it.
Re:how we did it
Ovid on 2004-12-15T21:30:03
Thanks. I'll check that out. It might help.
You are developing a product that must be installed and reinstalled all over the place. That adds GOOBE (good out-of-box experience) to your list of things that should be your core competencies. Whether that means you need someone who knows Ant or Make like the back of their hand, manage brittle shell scripts or you write your own FSM module, that's your call.
Sticking to your core competencies is about, say, not distracting your team of crack numerical methods programmers with a task to write a flight simulator.
