View RSS Feed

Development Team Blog

Why donít you just add it to the product?

Rate this Entry
There was a recent forum thread asking about adding an extra feature to one of our standard controls. It was noted that this could be done as evidenced by this feature being part of the Visual Report Writer. This resulted in the following question:
Just curious.

This is not the first time DAW have used classes in the development environment over the years that they have a reluctance to publish to us mere mortals.

Is there any reasoning behind this?
This is a great question and it deserves a thoughtful reply. We've discussed this numerous times. We've approached this from all different angles and no matter what we alway come up with the same answer.

There is no free lunch.

The Mythical Free Lunch

This situation arises all the time but it comes in slight variants. Someone has added a feature or an extension to the product that is useful and works great. Itís complete. All we have to do is add it to the product and everyone wins. That ďsomeoneĒ can be one of our talented customers, one of our consultants, a member of our international development team or even a member of the US development team. Weíve learned the hard way that this rarely works out and no matter how good and complete this feature is, just adding it is not the best way to develop a product.

Letís pick a modest real world example. As part of the development of the 12.0 Studio we created a sub-class of our tree-view class that did all kinds of good things. You could display checkboxes, you could show text in bold, you could display info-tips and the event notification system was more comprehensive. We used this extensively in the Studio and it did exactly what we needed it to do. We were sure our developers would like to have these features as well. We discussed adding this to version 12.0 because, after all, itís available, well written and most importantly all of the hard work was done. You may have noticed, those tree-view improvements did not make it into our classes until version 15.0, a full two years later. Why the delay?

Alas there was no free lunch. As we considered adding the tree-view class we faced with the following issues that we encounter anytime we go through this process.

It was built for a different purpose

Often this kind of new feature is designed to handle a particular task or style of application. In this case, we had particular requirements for the Studio and we built our class to meet only those needs, which is exactly how the class should have been built. This does not mean that this class would meet the needs of our developers who may require a more diverse and flexible solution. Creating that more flexible solution requires extra time and resources.

We still have to run it through a design phase

When we add anything to our product we go through a very careful design and evaluation phase. This is particularly true with our classes because we know that our developers will be building on these for many years. This design and evaluation phase requires the efforts of multiple team members. When someone offers us some great extension we canít suspend this process and just throw it in the next revision. First we need to understand the problem that this purports to solve. Next we must thoroughly understand the design and implementation. Next we must decide if this is the best way to solve this problem. This requires extra time and resources.

We are going to have to make changes

After going through the design and evaluation step we will have to make changes both minor and major. If we donít need to change anything, it means we really didnít evaluate it properly. (This is similar to giving someone your software to test. If you donít hear back with problems and questions, it wasnít tested.) This requires extra time and resources.

We have to test it

We must test the new feature. This is often very different from the testing that the author might have already done. They will write the code and verify it works in the limited way that they use it. They don't test what happens when it is used in unusual ways - nor should they. We have to test for the usual, the unusual and the abusive. This requires extra time and resources.

We have to document it

We must document this new feature. As a general rule these kinds of contributions do not usually come with documentation. I wonder why? This requires extra time and resources.

We have to be ready to support it

Whatever we add, we must be prepared to support for many years. This is a big commitment. This requires continued extra time and resources.

You might see a pattern here with "extra time and resources". In general, the old 90/10 rule applies. If something is 90% done, the remaining 10% will take 90% of the time. Restated, there is no free lunch.

In spite of all this we always have a hard time accepting this. When weíve got something that is done that we know our developers will really like we always try to convince ourselves that this one time, maybe just this one time, that this is the exception. After all, this feature is so great! Canít we just make an exception? Maybe we can work a little harder and sneak it in. Maybe we will have some extra time for this at the end of the project (hah!). Maybe a small delay is worth it. Weíve tried all of those arguments and here is the final step we go through to fight this temptation.

Prioritize it

Any time we plan a release we have a long list of changes we want to make, which we are then forced to reduce down to a much smaller sub-set. When evaluating some great new addition it is very easy to forget about the other great items that did not make it on that short list for release. So we now ask ourselves, if for some reason we actually have some extra time or resources to add something, should it be that extra feature? Would this be at the top of the list? The answer is almost always no.

We go through this exercise all the time. Weíve found it really helps to make this a team decision. We always have one member who wants to make the change (the author or ďauthor advocateĒ) and it becomes the task of the other team members to bring this person to their senses. Itís a wonder we still talk to each other.

In the case of the enhanced tree-view, we considered all of the above issues and decided to not add it to our 12.0 release. Instead we added it to our list for future releases and, finally, it was released in version 15.0. When we added this we found that the existing work was a little too specific to the needs of the Studio. We had to change the way checkboxes worked, we made numerous changes to the interface and, while we were at it, we rewrote the way the event notification code worked. We then had to test it, document it, and provide an example. Because we planned for this, this all went well. If we had attempted to shoehorn this into version 12.0, we would have created an additional delay and probably not have finished the work properly. We made the right decision.

Alternatives to a Free Lunch

While there may be no free lunch, there are alternate ways to get these kinds of ďgoodiesĒ into the hands of developers.

The Forum

Developers share tips and techniques in the Data Access Worldwide Forum. Start by searching the form for the information you need. If you donít find it, ask.


Libraries are a great way to share things. We have a forums for specialized libraries such as the VDF SIG Codejock Library and a general Open Source forum for everything else. There are some great contributions in there. Donít forget the venerable VDF-GUIdance site, which has some significant contributions. We are experimenting with releasing some of our own libraries such as the Visual DataFlex Graphics Library to see if we can reduce the overhead of bringing features to you.

The Development Team Blog

The Development Team Blog, which you reading right now, is a growing repository of tips, techniques and (attempted) wisdom that comes straight from the development team. We are very excited about the having the opportunity to provide this information and we expect that this will become a major resource for all things technical.


  1. Garret Mott's Avatar
    Thanks for that explanation! When spelled out like that, it makes a great deal of sense.

    Of course it shouldn't apply to anything I suggest... ;-)
  2. Mark Powers's Avatar
    Thanks John! All very good points, especially regarding documentation. I've attempt to document our system and realize it is not easy. You can spend nearly as much time documenting as you do the original implemetation of the feature.
  3. Chris Spencer's Avatar
    Thanks for the explanation John, I knew what the explanation was going to be in advance (doesn't mean I like it) but I understand

    Now that libraries are in use though this is an option with caveats to release new stuff to those who like to tinker.
    or as an open Source project

    BTW a suggestion for a BLOG. I have continual problem getting transparency working correctly with bitmaps (/t/3d etc). A BLOG to explain this once and for all would be greatly appreciated.
    Updated 31-Aug-2009 at 04:20 PM by Chris Spencer
  4. Hendrik van Niekerk's Avatar
    We do appreciate that there is no "free Lunch", just one question begs an answer, what exactly does our annual subscription buy us? And what will it buy in the future, now that we have reached a maturing or matured product?
  5. Chris Spencer's Avatar
    Fair question from Hendrik.
  6. Martin's Avatar
    For DAW Development Team to be not at Risk; I would like to see a DAW-VDF Prototype Library, this would allow (us) the developers’ time to review and take the risk of including new feature and components, and I think the Tree View is good example where some of us could have had it two years or so ago. Maybe we wouldn’t have gone off and developed are own, better still we would have the opportunity feedback constructed ideas for improvement thus saving DAW some testing time.
    We fully understand the risks of would seems a good idea at the time, too user/customer feedback! So Libraries it is!