Archive for September, 2003
At work, I’ve been investigating what will be involved to keep track of the database changes made by our programming team. So far, we’ve been able to work with a common shared database and mostly avoid stepping on each other’s toes. However, there are many shortcomings with not having the database managed with a source versioning system. The shortcomings are starting to cause pain to our managers, so we’ve been asked to do something about it.
From day one, we’ve kept our Visual Basic code in Visual SourceSafe. For a long time, I’ve wanted to work out a plan for doing this, but haven’t had the authorization to spend the necessary time until now. That hasn’t kept me from gathering bits and pieces of information about this issue. However, our needs are more than just storing the database objects in a SourceSafe database.
Some aspects of the process are very simple. We can easily version the views, stored procedures, user functions, and other basic objects. When you want to deploy these objects, you replace the existing copy with the newer version.
But what about table changes and system data? This is not a big deal when generating new databases, but we we need to deploy data conversions to other developers, QA databases, and to customer databases. Data conversions are not a simple “replace” functionality. They have dependencies. If a table has been changed twice since the version you have, the data conversions will likely need to be run in a particular order. In addition, you don’t want to accidentally run a data conversion a second time, as it may corrupt the data if you haven’t built safeguards into the process.
In my mind, deployment needs to occur from what’s in SourceSafe. It would be nice to have a process that helps support the deployment process as well as the simple process of keeping database objects in SourceSafe.
Finally, we’re doing our editing in Query Analyzer. I’d like to have a process that involves an editor that’s geared toward SQL, but has some of the features that are considered standard in a programmer’s editor (auto-indent, split windows, bookmarks, etc.).
Unfortunately, I’ve found that lots of small shops have this issue, but there aren’t many commercial solutions that fill our need. There are large enterprise solutions that might help, but a small development shop can’t afford a tool that would cost 5000 per developer. We could roll our own, but our team of seven developers is busy enough trying to churn out the new features and squash the bugs (some of which are caused by our informal process). I think we’re going to have to settle for a mix of products that help with some parts of the process and home-grown utilities to help with the other parts of the process.
Some other people on the web are also grappling with some of these issues. Here are some of the links I have found:
I took the same test and came out with the same personality type (out of 16 types) as Chris did. I wonder if this might be a common type among programmers who have blogs?
I got a chuckle out of this fix that is available for SQL Server 2000. If you have a query with 32000 or more OR clauses in it, don’t you have more problems than a bug in SQL Server 2000?
A complex part of programming doesn’t even involve writing code. I am referring to the interaction between computer programs and people. User interaction is a complex subject that has been the subject of many books.
I can relate to what Raymond has to say. My experience from working in a software support position confirms that people will do whatever it takes to get their job done. Here are a couple examples.
We write software for distributors. One of our customers is ISO 9002 certified. With their previous software, which was a text-based system running on the UNIX platform, the software filled in defaults for certain fields, but forced the user to tab through those fields to confirm that they were reviewed. The “required date” field on the order entry screen is an example of one of these fields. The order entry screen actually has about 5 different fields which require this functionality for the customer.
This customer required the same functionality in our software in order to remain certified. We discussed options with their management and they chose to go with a similar functionality. We detect if focus has gone into the field and don’t allow saving of the record until the focus has been placed into all of these fields that require review.
Management likes it. The inside sales people hate it. One of our trainers observed the inside sales people working with this new feature. After the defaults were filled in, the user would hold down the tab key to start repeat mode. The cursor would cycle through all the fields, setting focus on the “review” fields. Then they would save the record, without having really reviewed the data in those fields.
Another “feature” requested by management is “popup” messages for customers and items in order entry. The message might say “This customer won’t pay for overnight delivery. Check with the sales manager before sending anything by overnight delivery.”
What happens when the inside sales rep takes an order from this customer? They enter the customer on the order, dismiss the “popup” message without reading it, then take the order. The person on the other end, who has nothing to do with paying for the product that he buys, tells the inside sales person that he has to have it overnight. The order is entered that way, the product is shipped by FedEx, and then the customer’s accounts payable manager won’t pay the freight charges on the bill.
Who is at fault in this scenario? The blame could be placed in lots of places, and probably everybody shares in it a little bit. However, it often comes back to the people who provide the software. If this scenario occurs frequently enough, the user comes back to the software developers and insists that something is wrong because we allow this scenario. Solutions are offered, but the user may not be willing to pay for these solutions.
I know from reading Microsoft-based blogs that there is consideration to have “forced” updates in the upcoming operating systems. You won’t have a choice about whether to install a security fix. It will just be done.
For the average user, I think this is a good idea. However, many corporate and power users are not going to like it. Either they will have a problem with the “principle” of Microsoft automatically updating their software, or they will have logistical problems. Trying to provide a solution that balances everyone’s needs will probably be impossible, and we’ll continue to have people using insecure software when secure updates are available.