Dealing with Support costs, Part 1 (posted by Avi)

As I mentioned in my first post, we own a large amount of applications; about 80 at the last count. Some of these are small and we never hear a peep out of. Some are large and give us some type of "trouble" at least once a week.

Now, when I use the term "trouble", what I really mean is that we need to do something to this application. This could be a bug-fix, an email explaining the operation to someone, adding/tweaking entries in the DB, fixing a typo, etc. These could take anything from 5 minutes to a whole day… But multiply 5 minutes by many users and many apps, and you’ll see why even a spelling fix can be termed “trouble”.

As our list of application grows, one of the hardest and most important things we need to do is manage the support costs that go with these. If we can't do that, we end up spending more and more of our time on support, and less on development. Do that long enough, and the team eventually costs more than it produces.

We have a few techniques for reducing the support costs, and I intend to post several entries describing these. Here's the stuff that comes to mind right now, ordered by where it appears in the development cycle:

• Good design up front.
• Design/Code reviews.
• Documentation.
• Exception publishing/management.

Today I'll discuss "good design"… Kinda. This isn't going to be a post about what a good design model is; or even what a good design is/isn't. Firstly, there are hundreds of opinions on the web, and secondly, I don't want to get into a religious war :) Instead, I'll just tell you how you might ensure that your design standards are being met: A simple checklist.

We don't follow a single development model; I'd like to say we follow several, but in truth we sometimes follow none :) It all depends on the scope of the project, the level of understanding we have of the problem, and the nature of the customer relationship. Given that, our checklist can't cover the development model, but what it does ensure is that each of our applications meets a certain set of design guidelines and basic features.

Our checklist is divided into three sections: General app features, stored procedures, and code. I'm going to detail the "general" section as an example. I'll skip the others to keep this to a manageable size; but if you want more, tell me and I'll add it.

 

General app features.

Application should support the "alias=xxxx" querystring param. This is a great debugging feature. Basically, a small subset of users (ie; our team) has permission to add the "alias=username" param to any querystring, and that page will pretend to authenticate us as the user in question. We see what they see, etc.

All pages reflect their status in the querystring. We write lots of pages that generate statistics and reports. Often, these have multiple controls that allow the user to determine exactly what to report on. The problem is that by default, the values of all these controls are stored in the viewstate. The user spends 20 minutes generating their report, and then copies the URL from their browser into Outlook, and sends the link to their boss… Who end ends up seeing the bare report generation page; not the actual report crafted by the original user. For this reason, all reporting pages are supposed to reflect the state of their controls in the querystring. It makes for some large URLs at times, but it means that people can pass around a URL that allows them all to see the same data.

All user actions are logged (username, time, IP, action) . Critical! When you have several thousand users, many with write access [via the UI], you need to know who did what. When someone says "You deleted my critical data!!", it helps to be able to point to the log entry showing that they clicked on the big red button labelled "Please delete my data" :)

All fields have tooltips explaining their meaning. This might seem trivial… But if one field is unclear, you can be guaranteed that amongst 10,000 users, a few will email you about it. Multiply by 80 apps and you've got a problem. I'm sure some of you who write internet facing applications know this problem very well.

Application has a FAQEase doc link. FAQEase is our internal online documentation system. Every app has to link to its docs. Fairly obvious.

All reports contain date/time/user when they are generated. Sometimes rather than sending URLs, people copy data from reports and send it around. This ensures that an email from last week showing old data isn't mistaken for fresh data.

 

So that's the "general" section.

Each of the devs has the checklist (which fits on one page) posted up on their corkboard. As they're coding, they can keep this in their head to make sure they don't miss anything. Then, when the code is being reviewed, the reviewer is responsible for pointing out items in the checklist that aren't being met. It’s always easier to get things right from the start, rather than retro-fit them later (in fact, it’s cheaper by orders of magnitude). The other nice benefit of this is that it serves as a simple document to tell new-hires how we do things.

The key here is not this specific list; the key is to find out what you value in your development process, and make sure that the rules are being followed.

Avi