Responsibility in Software

The relationship between software vendors and developers is similar but developers are expected to know much more about this technology than they are expected to know about their car. There is an implied expectation between lower-tier software developers and the upper tiers of developers who build upon their works. In some ways the expectations are associated with mutual respect between vendors and users of their products. When a vendor knows that the user/developer has taken the product as far as they can, it’s time for them to step up where change is required or desired. The vendor needs to have some respect for other developers, to know that specific people can be trusted when they say something is wrong or requires change. The level of respect that a developer has for the competence of another developer is directly related to how they collaborate to achieve solutions.

Unfortunately this business of programming is in many ways a creative art and many artists have a strong ego. It’s very common for individuals to regard their users or their software providers with contempt. How often do we hear claims that "those support people are idiots" or "those users don’t know what they’re talking about"? This lack of respect between tiers makes the collaboration process much more difficult. It comes from a lack of understanding, when users don’t understand the products and/or the software providers don’t understand the common needs of their users. There are also many cases when support people are a bit arrogant and don’t understand the products they support. This is dangerous because not only is there "attitude" coming from the provider but the user forms a lack of respect for the competence of the providers. If the vendor/provider is arrogant but competent most users can deal with them to some extent. It’s better if competence leads to productive collaboration, without arrogance getting in the way – eventually people tire of dealing with "attitude" even if the provider is a genious.

In the end, if the user/developer hasn’t fully exploited the capabilities that are already in the product then I don’t think the vendor can be compelled to make changes. It’s this "fully" part that bears some inquiry. If a user/developer does not read documentation that is provided then why should the vendor be obligated to add new features which duplicate or simply re-work what is already in the product? The user/developer must earn the respect of the vendor in some ways, and in part that comes when the vendor is assured that the user/developer has done due diligence, has read all of the information available, and has made a sincere attempt to use the product as defined. When the vendor trusts that this has been done and there are still open issues or tasks that seem insurmountable, then I believe this is where the vendor must step in to provide their value-add.

If documentation isn’t clear or complete then it is the vendor’s responsibility to fix that part. The vendor must give users the fair chance to fully exploit the product as-is before either side considers changes. Incomplete or inaccurate documentation only wastes everyone’s time. It increases the support costs to handle reports of "bugs" or enhancement requests that are actually usability issues prompted by lack of knowledge. It prompts support and engineering personnel to come up with new solutions to problems that have already been solved implicitly with the right combination of existing tools.

Given the above, I think we can narrow down the responsibilities of lower-tier software providers to include the following:

• To give user/developers the basic tools as building blocks that enable them to create additional low-level functionality.
• To ensure that their tier is stable.
• To ensure that tools are available for rapid diagnostics when things do go wrong, that there is access to information about existing problems so that time isn’t wasted in problem discovery, and that access to qualified technical support is available, where problems can be quickly confirmed and scheduled for quick resolution.
• To ensure that their components are competitive in business terms by making sure they are "buzzword compliant", marketed for prospect awareness, and regarded in positive terms by the community.
• To ensure that the components are competitive in technical terms by including features to facilitate development of interfaces with other modern products, protocols, and APIs.
• To facilitate use of the product with documentation, tech notes, samples, tips, in-depth reviews, and other insight and information about what’s in the product and how it’s intended to be used.
• To foster community amongst the user base which allows users to share notes about all of the above, thus assisting the vendor in their quest to provide all of the above.
• To do things that their user/developer base cannot.

I think the above responsibilities apply to all vendors in the MultiValue DBMS arena but don’t think any of them live up to all of these points. Some are poor at marketing, have no community, have inadequate documentation, are not current with modern requirements, have questionable stability – or some combination of all of these issues. It’s important for MVDBMS providers to consider these points, understand where they fall short, and make it a strategic goal to improve in each area of deficiency. It’s also important for them to put aside arrogance caused by lack of understanding or complacency- to ask their user base how well they do in those areas and to ask whether or not their client base believes they need improvement.

Coming back to the first statement in this article, there are those user/developers who believe the vendors should be doing more, questioning how well the vendor lives up to the expectations listed above. Does your DBMS really provide the building blocks you need? Should building blocks included higher-level tools, perhaps aggregations of building blocks to create more sophisticated building blocks? For example D3 has included the @Shell Variable feature for years and yet my recent article has caused people to question whether nested queries should be a part of standard TCL queries. I would maintain that we do have nested queries, we just didn’t recognize it. Others seem to prefer having something that looks more like SQL nested queries, something actually called "Nested Queries" and supported as such. Is it so important to have a name for everything? Is it really required for the DBMS provided to pre-assemble some of these building blocks into higher-order components for us?

Personally:

• I prefer that the DBMS providers focus on that last point "to do things that their user/developer base cannot".
• I prefer that their revenue be re-invested in stability, marketing, and proper documentation and education on the software that exists now.
• I prefer that they spend time learning modern technologies so that we don’t need to spend so much time on related details, and that they create interfaces where they have invested 90% so that we only need to learn 10%.
• I prefer that they invest in their support technicians and management to better understand the products, the user base, and how to communicate and escallate issues without social conflict that gets in the way of technical discussions.
• I prefer that they foster community where all of us can share solutions so that we don’t feel like we need to look at the vendors themselves to add even more to the product.