Creating a feature toggle library, part 1

What do you do when a customer requests a change or a new feature in your product that only applies to that one customer? Broadly speaking, you have two options: a feature branch or a feature toggle. 

A feature branch means you create a copy of your app/source with that customer change. You now have two versions of your code to maintain. The advantage is that you don't have to worry about breaking code for your other customers; the disadvantage, and it's a big one, is that you now need to maintain two different development and possibly build environments. If you have one change like that it's not so bad; if you have multiple changes and multiple copies of your code things can get messy in a hurry. 

A feature toggle means you keep one copy of your app/source and you put in a code switch that turns on the feature for just that customer. The disadvantage is that you have to be more careful about isolating the new c ode from the existing code; the advantage is you maintain a single copy of your app/source, and a single build environment. 

There are some situations where a feature branch is the way to go, although this is easier to manage in a pure source environment given the support for feature branching in mainstream source control systems. Almost all Clarion shops rely on APP files, so if you're going to do feature branching with Clarion you should give some serious consideration to using APV files along with UpperPark Solutions' Version Control Interface. But that's a subject for another article.

Thinking about design

When all you want to do is switch on a bit of code, a feature toggle seems like a simple thing. Get a value from an INI file, use the result in an If/Else statement, and you're off to the races. But there are a lot of other possibilities you should consider:

• Is this a toggle that should be set at program startup, or should it be switchable while the program is running?
• Does this toggle apply to all users of any given installation of the program, or just some users?
• If this is a web server, could the toggle be applied based on information in the request (e.g. which browser the user is running, the IP address, etc)?
• Could a set of features be collected into one feature so that switching the master feature switches all of the sub features? 
• How can feature toggles support automated testing?
• Will there need to be a user interface?
• Where will the configuration data be stored?

The wrong place to start

If you're like most Clarion developers, the first place you turn when embarking on a coding adventure is the dictionary editor. 

Don't do that. 

Maybe I didn't make myself clear.

Put Down The Dictionary Editor!!!

The dictionary editor is a terrific tool, in its place. But as developers we've become way too dependent on it. We've always been told to get our dictionary right, generate the procedures we need, and go from there. 

For much of the development we do, this is just wrong. The dictionary editor is great for supporting CRUD (e.g. browse/form) development. But think about it - how much of the code you write is really CRUD code? The stuff that really takes up your time is business logic. And when it comes to business logic (or in this case the code that will support the business logic), the first thing you need to do is model the behavior in code, which often means writing classes.

It's only after you get the behavior roughed in that you'll know enough to decide what your data storage should look like. 

Next time

There are a number of ways to approach the code needed to model feature toggles. Most of the time I turn to test-driven development with ClarionTest, and that's a great fit for this project. Stay tuned....