Development Team Blog

If you are a follower of the Development Team Blog, I hope you agree that it is a great resource that is getting better all the time. Apart from giving you something new to read a couple of times each week, we are trying to create a library of information that can be accessed when needed. These days we expect a Visual DataFlex developer to do their research by first checking the documentation, then searching the Development Team Blog and finally searching our User’s Forum. Let’s explore these three levels of information.

1. Documentation: Information that if formally documented is your most reliable source for problem solving. Our documentation is essentially a contract between a developer and Visual DataFlex. When we document something we expect that it will work as advertised. If it doesn’t, we will attempt to fix the problem wherever it might be (the product or the documentation). We always try to give you the public information you need and to specifically not give you the private information you don’t need.

2. The Development Team Blog: We look at the Development Team Blog as your direct connection to the development team. We use this to talk about all different kinds of topics. We might talk about a specific topic that was under documented (that happens). We often use the blog to answer a forum question that we felt deserved a more permanent answer. We may talk about our own design and development process. Or we may stray and talk about any number of general design, software engineering and industry issues. We might even tell stories from time to time.

3. The User’s Forum: The Data Access forum is your forum and we are (mostly) just participants. You can ask any question you want and you can always count on getting answers. As with any Internet User’s Forum the answers you receive may range from brilliant to bollocks. All in all, I’d say we have a pretty good forum. The participants are supportive and the answers provided tend to be good. Even answers that we provide on this forum have to be carefully evaluated because we may be providing a workaround to solve a problem created by using a technique that we would not recommend to others.

If you can’t find what you are looking for in our documentation, your next move will should be to search the Development Team Blog, followed by a search the of User’s Forum. If searching all the above resources fails, you should post a question to the User’s Forum. Why would you search the Development Team Blog first? Simple. Content in the blog comes "directly from the horses mouth" and is therefore a more reliable source of information. It’s almost like finding the answer in the documentation, but it’s not.

And, that’s why I am writing this article.

As a company we had to make a decision about how conservatively we monitor the contents of our Development Team Blog. It should come as no surprise that our development team does not always agree on every issue. Should this diversity of opinions be exposed in our blogs? Some of the topics we could write about deals with private interfaces that are purposefully not documented. Should we be talking about these topics? Some of the techniques we could write about might fall into the category of tricks. These are the kinds of things that can lead you astray. Should we discuss these? Some of the topics we discuss might deal with bugs and design flaws in the product. Should we really be discussing these at all?

We’ve made the decision that we want to make the Development Team Blog as open as possible. This gets more information into your hands more quickly. Hopefully it makes the information a little more interesting for you and for us. Let’s face it these topics tend to be a little on the dry side. In keeping this blog relaxed we want to make sure that you understand what you are getting. So here are the ground rules:

1. We will try to offer tips, advice and opinions that we feel represents the best way to develop software. Our advice is based on our technical understanding of the product and our knowledge of where we are taking it. While we are quite serious about providing you with top quality information it should be recognized that this information does not go through the same kind of review that we apply to our interfaces and documentation. You need to be a little more careful about how you use this information.

2. If we talk about a technique that is private or we show some trick, we will try point this out in the article so you know that this is a "use at your own risk" technique. Sometimes you will ignore these warnings and sometimes we will forget to issue those warnings. Let us respect each other's shortcomings.

3. While this is a DAW blog, we’ve got a bunch of different authors and we expect to have more (we are twisting the arms of the silent team members). We want each author to have his or her own voice, style and opinions.

4. We are trying to have some fun. If some of our comments appear to be flippant that might be because they are … well… flippant. This is not documentation and this is not product marketing material.

5. Your comments on articles are welcome. You may have noticed that we tend not to reply to our own articles. This is intentional. We don’t want to turn the blogs into forum discussions. If responses are needed, we can always move the conversation to the forums.

In summary, there are some topics where we have to find the right balance between avoiding them (the "I could tell you, but then I'd have to kill you" approach) and providing information that might not be official company recommendations (the "I will answer your question but don’t tell anyone that it came from me" approach - which just doesn’t work with blogs). We are erring on the side of openness. While this kind of openness creates the risk of leading you astray, we figure that you can handle this and that this will be more than offset by the wealth of information provided.

Those are the ground rules, now let the wild rumpus continue.