Is it OK to Extend DesignBais?

It’s started – people are getting more comfortable with DesignBais, learning the strengths and how to deal with the weaknesses. When the first release of a new application UI is in production and developers look back to see what they can do better (and respond to the end-user enhancement requests), they’re starting to get creative, get more out of the software, make it do things that isn’t in the documentation. And now the question has come up in the DesignBais forum – "should" we be coding into the internals of DesignBais? Here are my thoughts.

Many of us realize that DesignBais is a powerful tool but there are things that we would "like" to do which the product does not yet support and probably will not support as a documented feature. Rather than feel like we cannot do what we want I think it’s better for people to make the product do what they want until a time when maybe DesignBais will support it.

As an example, I have a client with a couple hundred files in their application. I’ve written code to create the DBIFILES and DBIPROP items from dictionaries. When working in the DesignBais environment it’s difficult to find the file or property we need when we pull down a list of a couple hundred alphabetized selections. So I added a Category option to the form where we maintain Files, and made other tweaks to the standard DesignBais forms so that we could first select a Category and then get a limited set of files when maintaining forms and other aspects of the environment. David McLean saw this, said "yeah, that’s a good idea" and sure enough he built into the upcoming v4.2 release. Whether or not I’ll be able to use any of my mods we won’t know until v4.2 comes out, but it is important to me that we have the ability to do this sort of thing if we wish, and we should take the initiative to do what we feel is necessary to make our end-users and developers most productive.

Whether they intended it like this or not, DesignBais is natively what is called an "extensible" product. This is a feature which is enjoyed and required by most products in the IT industry, but most tools in the MV market do not support it. In short, people want the ability to extend the products they use with add-ons. Products like Microsoft Office, Adobe Photoshop, web forums, blogs, browsers, and all open source projects are extensible because people want the ability to get more than the basic features. The world is full of third-party for-fee plugins and freebie extensions, and this "community" built around products helps to give them longevity. I’ve been trying to do the same with this DesignBais market precisely because DesignBais uniquely has the wonderful ability to allow us to do so. The reason why DesignBais can do this is because to a great extent DesignBais is written in DesignBais. This confusing concept of recursiveness allows a developer to create a product which he can then use to extend the product itself – it’s the ultimate in code re-use. And if DesignBais International can use DesignBais to deliver new features to us, there’s no reason why we can’t think outside of the application box and do the same for ourselves.

People will wonder if the extensions they write today will be invalid tomorrow. If you "code into" the DesignBais internal variables, you will find out in the next release if your code breaks because you’re going to test your code before you deploy it – right? Changes to the underlying structures aren’t going to occur so suddenly that your users will find out about them before you do. When a change occurs you can decide to not upgrade for a while, change your code, or to negotiate a change with DBI which allows them to provide backward compatibility for you while providing new features to their other users. This issue of retro-fitting extensions is faced by every developer who makes changes to open source code, and anyone who makes significant use of third-party components which are in active development. In any case, so far the sort of coding that we’re talking about doing here is fairly benign, and I’m sure that we as a community can figure out ways to ensure continued functionality of DesignBais extensions in harmony with each new release that DesignBais International provides to us.

For those of you who wonder how DBI feels about people getting into their product, at the DesignBais conference in Las Vegas David McLean did specifically announce that he had a change of heart regarding "creative" use of the product, and that he intended to create a website which specifically helped developers to offer plugins like this for free or for fee. As long as we approach this carefully and professionally – not blaming DBI when our extensions break – then DBI seems eager to welcome new plugin offerings. Ultimately this is good for them as it allows their client base to make best use of their software without consuming their resources or impacting their deadlines. It’s tough for a company to discourage that sort of win-win benefit. On top of that, while the word "hack" still makes them cringe, I know they get a little tickled when people do new and interesting things with their software. As without our children, it’s an interesting and bittersweet moment when our software starts to have life of its own.

I’ve discussed this topic to some extent in other blog entries. Here are a couple links for further reading:

Introduction to scripting in DB and the DBI position.
Introduces the concept of coding reversible hacks.
Serious plugin to create functionality that DB doesn’t have and probably will not.