Reposting: The Holy Grail - Application Development without Developers

If you've made it this far, I can tell you that the title is tongue-in-cheek. No throwing things at me or unsubscribing (thus cutting my readership in half).

Over the course of my career, I've seen attempts on various projects to eliminate the need for ongoing developer involvement in system maintenance. The argument goes something like this: If we could just build a flexible business rules engine, we wouldn't have to call the developers every time we need to update our FILL IN THE BLANK.

Don't get me wrong... there is definitely a time and a place for application configurability. It's just that business owners (egged on by developers looking for a good challenge) tend to over-extend the concept. For example, they may foster the creation of a new micro-language for defining pricing rules. Something like:

IF ($PRICE$ > 100) $PRICE$ * .90 --> $PRICE$ ELSE $PRICE$

Given that I personally know both people who read my blog, I know you could implement the parser to apply this business rule. And why not? Now my business owners can be in complete control of their pricing rules! We're not just talking a few canned rules... No, I mean autonomous, unbridled, master-of-your-own-universe power!

But there are a few catches. What happens when my business owner misses a closed parentheses? Well, it's back to the drawing board to write a user-friendly syntax checker (a.k.a. compiler). But then, they forget the symbol for manufacturer cost and complain (which is, of course, $MFG_COST$). Well, it's probably time for documentation (language specification) and macro-builder (IDE). The next complaint you get is "My pricing rules are getting really hard to enhance without messing them up." Well, this time (again because I know who my readers are) you realize you'll need to implement a unit testing framework and educate your business owners on Test Driven Development.

By now, however, the gig is up. You don't know how to implement a unit testing framework for your new language, POOP (Pricing Open Operation Protocol). However, you've now spent 20% of your career developing it, its compiler, it's language specification, and its IDE. You're highly invested - it's no time to abandon POOP now!

You forge on... You begin gathering pricing requirements from your business owner (if only you could just program all day), implementing them, and demonstrating them for acceptance. It's just that you're life is harder than it used to be. You used to have a powerful, expressive language (C#), complete documentation (MSDN), whiz-bang development tools (Visual Studio & Resharper), and unit testing framework (NUnit). Now you've just got POOP.