Responsibility in Software

It’s amazing that in this industry we still don’t have universally recognized tools for backup and restore of accounts, files, and individual items. I would like DBMS providers to all have well documented, standard solutions for all of their available features. As all of the vendors encourage migration I would hope that they would create standardized and well documented migration tools so that it didn’t seem like each migration was the first of its kind. How do we move accounts, files, and items from D3 to jBASE, Unidata to QM, jBASE to Universe, or Universe to Reality? This is the kind of fundamental development that is still required in our industry because it represents a current problem that we discuss frequently. We rarely discuss issues with the query processor because there are many ways to do various tasks, so I don’t believe we should ask the DBMS vendors to assist with this.

That brings up the concept of need. Where do we need changes? Which one of the points deserves the most focus from each DBMS vendor? We need change where we recognize the most confusion, and this is one of the reasons why I spend time in the public forums. I want to understand the common problems, solve them, and sell the solutions. This is almost the definition of my business. In some ways I step in to capitalize by providing solutions that the DBMS vendors don’t – or at least that they may not do well. I write interfaces with Microsoft Office applications because none of the DBMS providers do this. I write interfaces with web services because that is still a black art for most Pick BASIC developers. When everyone is writing web services I will be off on LINQ or Silverlight or PHP or Ruby or Java or whatever is not a part of the "been there done that" consciousness of this community. I do not write backup utilities because the vendors already have, though apparently there is room for improvement in this area too.

The DBMS vendors need to invest wherever there is the most demand by customers who have already paid for their products and by future customers who will be buying new licenses. This is where a great part of the trade off is. If they are truly investing in new sales then I don’t want them spending time on the core DBMS. Part of their responsibility as I have defined it is to make the products acceptable in a competitive market, and that cannot be done it are investing engineering effort in nested queries or backup utilities. They must intelligently balance their priorities so that we have products that we can use in years to come. For this we rely on management. Management needs to make hard decisions about approving or rejecting requests from the user base. I don’t mind sacrificing an enhancement or even a small fix (note responsibility of stability) if I know they’re trying to focus efforts on the bigger picture. If they can get more sales by having more modern features then they’ll be around to provide enhancements later. If they don’t make new sales then they will constantly struggle to provide changes. Unfortunately this is where I see much of our market now, and I think this is a direct result of spending a bit too much time on changes to the core that could have been left out, and not enough investment in stability and developement for a contemporary audience.

Which changes to do they make? Again, I think the forums are a good place to get the pulse of the community in some ways – though one also needs to understand that the forums contain a vocal few rather than the more subdued majority. However, one person in a forum may represent a hundred people in the field (or it could just be one loudmouth) but the voice should be heard and considered as it could possibly be a sign of a more general issue. The best way for any vendor to know what needs to be changed is for them to actively solicit change requests from the user base. I really don’t think any of the DBMS companies do this – at least not seriously beyond a "how are we doing" survey. Forums are a way to find out what people are thinking outside of the surveys. More moderated/professional forums provide a way for the vendors to get professional feedback from their respected clients/users/developers in the field. I think it would help if the DBMS companies partnered with focus groups of their users to get a reality check (no pun intended) for their planned changes. They can ask what takes priority – new backup tools or a new web service interface, a new GUI development tool or a new way to manage files and performance. These tactical initiatives need to be balanced with more strategic changes. Is the company going to reposition outside of the DBMS market entirely? Is the company’s objective to provide embedded database solutions or large-scale datamarts, and does this conflict with popular requests by users?

A vendor may not always make popular decisions about what they are going to change in their product, but it is their responsibility to make these decisions. If they aren’t making small changes then they had better be making big changes – inaction is unacceptable. Sometimes it’s the responsibility of the vendor to make small changes just to keep the user base happy, because if nothing else a happy user base is a good marketing tool and that contributes to the higher goals. It is the user/developer’s responsibility to understand the tools and the market. User/customers must have some respect and appreciation for the bigger considerations of the vendor, to ensure that requests are for the greater good and not to satisfy individual desires if not whims. Developers need to balance their time with that of the vendor – one hour of developer time might yield a more satisfactory solution than weeks of a vendor’s time, which then occupies hundreds of hours of time for others in the field. These numbers must be considered. Priorities of everyone involved must be considered. It is our responsibility to treat the resources of our vendors and our clients as though they were our own resources, and balance how we spend our time with how we ask them to spend their time.