William (Bill) Vaughn's Musings

Posted by William Vaughn at 11:28 AM | Permalink | Comments (1)

February 17, 2006 • Vol.28 Issue 7
Page(s) 23 in print issue

I was lurking on one of the newsgroups recently where one of the longer threads raised a number of interesting issues. The gist of the thread focused on several incidents reported by a number of independent consultants—one of whom was hired to extricate a major corporation from a serious SQL Server performance problem. We’ll call him “Fred.”

It soon became clear that the performance problem was caused by inept and poorly executed design. The database was multitiered but with so many convoluted tiers that it brought tears to the consultant’s eyes. Fred submitted a comprehensive review of the system and included a number of suggestions to get the DBMS (database management system) back on track.

It seems that Fred’s advice was already doomed—the company had decided to switch from SQL Server to Oracle. Apparently, some decision-maker had been told Oracle was far faster than SQL Server and would easily solve all of the company’s performance problems. Before Fred could take another breath, he was informed that the Oracle consultant who made these claims didn’t know how to write T SQL (SQL Server’s unique SQL language), and the company wanted Fred to teach it to him.

Roll the clock forward several years. What would you expect to be the current state of this megacompany’s DBMS? Personally, I would expect it might actually be better. Of course, this assumes that the Oracle consultant (who didn’t know T SQL) was eventually replaced with one that had more skill and that this new consultant took a careful look at the design, figured out what was wrong, and spent the next six months fixing it using SQL Server or the next two years redesigning the DBMS to match Oracle’s strengths. On the other hand, the DBMS performance and stability would more likely be worse, or at least no better, given the way management had been able to fathom Fred’s advice.

Porting a poorly designed DBMS from one vendor to another rarely (if ever) improves the design and even more rarely improves performance.

Who Should Take The Blame?

But who is to blame here for the poor performance? I think there is plenty of blame to go around. First, the original design (and thus the original DBMS architect) might (only might) be to blame. Multitiered designs can scale better, but they don’t necessarily perform better.

However, if the concept and design were brilliant but the implementation of this design was flawed or clumsy, then a portion (only a portion) of the blame can be shared with the development team and the development team’s management. Management can’t just lay down timelines, hire a staff, and let staff members do their thing without staying involved with the day-to-day details in how the design is being implemented. Consider that the person writing the code usually is doing the best she can. Developers might be in over their head and fail to recognize how other, more efficient approaches can be implemented. This isn’t stupidity; it’s ignorance—a common malady when the architectures, tools, and infrastructure change every few years.

Blame ADO Or The Database?

Getting back to the original newsgroup thread, another consultant whom I respect said the most common factor in performance problems was poorly written data access (ADO) code. That is, he saw too many developers making very common mistakes: fetching entire tables, accessing tables instead of stored procedures, overloading deployed client applications with schema-dependent code, and using other sloppy coding techniques that many of us have been railing against for decades.

Another consultant in the thread, whom I also respect, disagreed. She said that the most common performance bottleneck was poor index design, poor query design, and other database-centric issues.

Personally, I think they’re both 100% right. In a good design review, ADO-skilled developers see data access issues and DBMS-skill developers (and DBAs [database administrators]) see DBMS issues. Unfortunately, there are precious few consultants that are highly skilled in both disciplines, and we can hardly afford to hire those who are. Your performance problems might be the cause of several implementation teams who fail to work together as a team.

How do you protect yourself when, years down the road, you discover that the DBMS you chose is not any better than the current choice (perhaps the one chosen by the IT manager’s son-in-law)? IMHO, it makes sense for decision makers and managers to listen openly to more than one point of view, hire a team you can trust and really knows your business issues, and bring in trainers (a good consultant is really a trainer) that can help your team implement the design as specified.

Of course, this assumes your architect is disciplined and skilled enough to write a comprehensive specification before a line of code is written. It also assumes that management and the decision makers up and down the line are not open for output only; they listen to the advice they’re paying for.

Posted by William Vaughn at 07:23 PM | Permalink | Comments (0)

Posted by William Vaughn at 03:40 PM | Permalink | Comments (0)

Posted by William Vaughn at 10:51 AM | Permalink | Comments (0)

Posted by William Vaughn at 10:51 AM | Permalink | Comments (0)

Posted by William Vaughn at 10:50 AM | Permalink | Comments (0)

February 3, 2006 • Vol.28 Issue 5
Page(s) 25 in print issue

Application developers are a proud bunch. Like proud parents, they’re convinced that their latest creation is the solution to the world’s problems—or at least deserves as much attention.

Perhaps this is why their applications are so intrusive. Like a noisy kid in the booth next to you at the family restaurant, these applications often announce themselves with 12 bars of music or a trumpeting that would make Gabriel take notice.

Take Microsoft Money, for example: When it starts, it announces to everyone in the county that it’s arrived. You would have thought the president had just stepped to the podium at the nominating convention. If you try to figure out how to disable that six bars of trumpeting and enter “disable sound” or just “sound” in the Money help index, it has no suggestions on how to muffle this exuberance. Yes, eventually I found a Program Settings option that let me disable the sounds, but it was an all-or-nothing deal, so I had to dig into the Control Panel list of registered sounds and find the startup noise (or something like that) and set it to None. What a pain.

Announcing Non-Events

The issue here? I’m of the opinion that application sounds should be far less intrusive if enabled by default. This means very low in volume and a second or less in duration. It’s surprising how attuned we are to tiny sounds; it does not take much to get a user’s attention. Although sound reinforcements can help productivity, they do not need to be blurted out for “non-events” such as application launch or tear-down.

I can (almost) understand the Windows Startup sound as a way to verify that the sound system is working, but there is no excuse for the shutdown sound—it’s just intrusive and adds to the time it takes to shut down my laptop. If the application wants my attention for something serious that it can’t deal with on its own, then fine, play an appropriate tone or better yet, something specific to the issue. If it’s important enough to disturb my work, then it should be a special (short) tone. Anything gratuitous is just arrogant.

It’s Not Just Sound Arrogance

Ah, and what’s with the applications that have to regularly update themselves but have to tell you they’re doing their job? Sure, some utilities have to download new virus and adware signatures and software patches to correct some weakness or another. That I understand. What I don’t understand is why they have to expose a dialog to tell me that they are doing their job, a job I’m paying them to do.

Norton Antivirus is a prime example. Ever since I installed it, I’ve been rudely interrupted with one dialog after another asking me if I want to block this or that. How ordinary people know what to accept or block is beyond me, but what makes me want to uninstall it (and I’m about to) is the intrusive dialog that’s displayed as it’s doing its periodic updates. If I hire someone to do something, I want him to do it quickly, quietly, and efficiently—not report every few minutes on the progress or how well he did it. To make matters worse, when Norton finishes its Live Update, it forces me to immediately reboot. Any attempt to disarm this shutdown sequence has resulted in lost work. Now that’s arrogant.

Windows Update sometimes needs an update, but it lets me finish what I’m doing before reminding me that I still need to reboot. It does keep putting up that irritating dialog (and stealing the focus) to remind me over, and over, and over . . . but I do have a choice and a chance to clean up the system, so it can restart.

Applications—Member Of A Team

Applications need to be written as if they were simply a member of a team that has to work together for the user and not the one and only application running on the system. Most of us multitask and have many applications working in parallel. It’s arrogant for applications to assume that they can display dialogs, pop them to the top of the Z-order, and grab focus when the issue is not of critical importance. This irritates the heck out of users, as it should.

Suppose you’re right in the middle of an important customer call and some junior assistant bursts into the room; interrupts your concentration; grabs the phone, mouse, and keyboard; and glues a 5 x 7 memo on your computer screen and doesn’t leave the room until you’ve acknowledged it. How long would that person be working for you? If it’s your spouse’s cousin, you might overlook the issue, but if it’s a utility application, your next call might be to IT support to have it removed. Having the programmer at fault report to your desk front and center might be in order, just so you could explain his or her role in the organization.

Posted by William Vaughn at 07:25 PM | Permalink | Comments (0)