Do you think about supportability?


So I wanted to get a read on how people design their web sites.  My thinking is that there isn’t much time spent in planning for supportability.  There are a lot of other concerns that take priority, What is more important – Design or Content.

I believe that supportability isn’t the most important piece of a web site, but it should be A part.   So my questions are:

  1. is supportability a component for your team?
  2. How much do you consider it?
  3. What do you use to fill this piece?
  4. How do you prepare for malicious attacks?  (including making sure you have enough log information to track them down)

I’d like to hear how people prepare their sites for these problems. 

Comments (6)

  1. Francois Ward says:

    This is the part where ASP.NET is king (maybe Java application servers too, I haven’t had to deal with that aspect of it, so I can’t talk) over many other environments for web development.

    You just have -so- much out of the box, or a few web.config entries away, and it is single handedly what keeps me from jumping ship as soon as I see “The Next Best Thing”.

    Designing for support takes a -lot- of thinking, and its almost as much work as filling in the basic requirements. So here it goes:

    -Tracing: Anything I feel may be of interest in the case of an unexpected bug (let say I have a navigation workflow system, like the project I’m currently working on, and the pages don’t flow in the right order). Trace.Write, Trace.Write, Trace.Write. That way we can stick a production server with tracing enabled, go to trace.axd, and something that would take weeks to debug, take 5 minutes.

    -Health monitoring: Case by case basis, but I always have -something- to notify me of unhandled exceptions so I can have the stack trace without having to turn off custom errors and ask my users to reproduce it. That one is -critical-. You may not see the exception again in days, so you need to catch it on first try.

    -Asp.NET has all of the performance counters and built in windows stuff. No need to do much on that end, the default is enough for typical apps (I’m not working on Amazon or Google scale sites, hahaha).

    -Since I started reading your blog and Tess’, I keep all of the debugging tools for production servers around, and I make sure the rest of my team are aware of em. Never needed it so far ::knock on wood::, but the thing **** hits the fan, we’ll be ready.

    -For malicious attacks, thats trickier… For all of the stuff like DoS and whatsnot, thats the support team that is handling it via the network logs and whatsnot. For the application, we take very careful consideration on preventing malicious attacks (the apps are designed with security in mind), but should someone actually attack the app anyway, I’m not too sure what to do. We do have logs on all of the important transactions, using logging librairies to have audits of the requests of stuff like administration logins, deletion of important data, etc, so I suppose we can fall back to analysing those, along with turning tracing on (but that may be too late at that point), so I’d be interested in what more beyond analysing audit trails we could do.

  2. Q1: is supportability a component for your team?

    A1: I must say that it is not part of the initial design. but during the initial project startup this get more and more importance, the funny issue that we just had a meeting today about this issue 🙂

    Q2: How much do you consider it?

    A2: I tend to give it high priority because at the end this is the key factor that will make the end date of a project a real end date and not a start date for support and problem resolution

    Q3: What do you use to fill this piece?

    A3: Internal logging mechanism (Effective and unified for the product), Smart exception handling, Adding relevant (important) information for the exceptions, capture HTTP logs and HTTP err logs (to analyze later), Each log entry contain the end user identity and the session id and at extreme occasions we use fiddler

    Q4: How do you prepare for malicious attacks?  (including making sure you have enough log information to track them down)

    A4: I fail to understand how this relate to supportability, we have full logs IIS and Internal

  3. Greg says:

    Q1) How much will the product/web site cost over a 5+ year lifespan?

    Q2) What are you doing to reduce the post production support costs?

    Q3) What are you doing to reduce the skill level needed to read, understand and maintain the code (e.g., targeting someone with 1.5 years professional experience)

    Q4) What tools are you using, including build, unit test, etc., will they be around in 5 years, will they be supported in 5 years and (most importantly) how many people are knowledgeable enough in those tools?  (heads of the toolkit, framework, etc. collecting done at most shops to prevent the long term collecting of dozens of oddball tools which no-one knows anything about except the developer that brought it in – and has already left the company).

    Q5) What are you doing to ensure that consultant/offshore written code is not ‘semester project’ quality (i.e., consultant gets it to pass QA and leaves, whether or not the code actually works and is maintainable/supportable)?

    Q6) What are the future plans for the second generation of this system?

    As you can see, these are all Developer 101 questions.  This has generally been lost in the last few years given the IT bust, offshoring, and high turnover rate in developer jobs.  

  4. Vin Bhat says:

    We first design & develop an application to meet the positive case scenarios. Then refactor it. Then consider all the possibilities and depending on the project deadlines and after a cycle or two,  supportability & all pieces (hopefully) fall in place.

Skip to main content