This is the second of a five part series on system design, relying on my own experiences and knowledge from working both in the public and private sector.

I have broken down my thoughts on system design into five distinct pieces: user requirements; development standards (this article); usability, code-cutting, and testing and go-live.

What sort of standards?

That’s really up to the application development team (and/or their line management) to decide what sort of standards are appropriate to a particular development. This will obviously vary somewhat according to the platform the application is being developed for, and the expected users of the system, but some standards that could be considered are:

• Internal coding standards — is your code readable? Are variable names meaningful? Have you used corporate naming conventions?
• External coding standards — does your HTML validate?
• Usability standards — is your system easy and intuitive to use, or do people have to be given specific instructions to prevent them from making mistakes?
• Accessibility standards — can your system be used by people with disabilities?
• Universality standards — can your system be used by people with a different platform and/or browser?

I’m not going to get into the argument here (again) but I tend to see universality and accessibility as part of the same coin: either are preventing someone from using the site, it’s just a question of why; however I’ve specifically listed them separately here because in this case I want to consider them separately.

Standards Enforcement

In any development team, different developers will by nature have different coding practices, different skill sets, and indeed different attitudes towards work. Yet from here we want to arrive at a position where we can be sure any developed systems not only meet our requirements, but also that in the event of the prolonged absence of one developer, someone else would be able to step into their shoes and continue their work.

In a nutshell, those two things — ensuring you hit any external requirements and that your developers can work interchangeably — are, in a nutshell, what standards are all about.

At the managerial level however, it is important to decide which standards are going to be enforced. Any standards which are not enforced will be seen, at best, as ‘guidelines’ and ignored or adapted by developers to suit themselves on a case by case basis.

For example, any system providing a service to the general public in the UK is bound by the Disability Discrimination Act, meaning that you can’t unreasonably place barriers in front of disabled users, that you can’t refuse to employ disabled employees (which means that even your internal systems may need to be accessible) and so on.

In some cases, it goes further than this. Local Government sites in the UK are expected to comply with the WCAG 1.0 Guidelines to at least the ‘AA’ level. My opinion is that these guidelines are outdated, in some cases make little impact on how usable the site is to someone with disabilities, and prevents you from relying on any scripting technologies even if you’ve tested these with accessible technologies.

That said, if it’s mandatory, you’re still going to be expected to do it, at least until the requirements have been revised. But if you want to actually achieve this, you’ve got to enforce it: test for compliance with this and don’t but sites live if they don’t match up.

The only standards you actually have will be the ones you enforce.

Drawing The Lines: Perfection vs Practicality

Which standards you decide must be enforced will depend on your own external pressures: what are you going to be evaluated against?

In an ideal set of circumstances you don’t need to compromise: when you’re developing applications in-house, you’re in control of them and with a minimum of additional effort can ensure that you comply with all internal standards, that your site is accessible to users with disabilities, and that it is secure and robust.

Unfortunately, the circumstances aren’t always ideal. It’s common to find a situation where some, or all of the live code has already been written, or is outside your control. How do you handle that?

Well not surprisingly, there isn’t a one-size fits all answer. It depends.

Really, it’s up to you, your management, or their management as appropriate, but what you need to consider is:

• What do we need to do to fix this system?
• How long will it take to fix this system?
• How much will it cost to fix this site?
• How likely is it someone will have a problem with this system?
• What are the potential consequences if someone has a problem with this system?

These five questions are key questions to ask yourself about your standards.

Imagine asking these questions with regard to a series of variables not being named according to your naming conventions. Is it that important? Will it have an impact on future developments?

If so, then by all means review it. If not, you might want to reconsider whether you need those standards at all…

Now imagine you’re asking those questions because your site is unusable to someone with Firefox. You’re risking potential embarrassment if someone raises the issue and you don’t get it fixed. You’re also risking losing potential customers or clients.

Now imagine it’s because your site doesn’t work with a screen-reader and blind or partially-sighted people can’t use your site. Now it’s not just embarrassment you’re risking, but a potential lawsuit under the DDA. Under these circumstances, you’d probably have to fix it.

But the question that would tend to be asked is not whether it should be fixed; it’s whether it should be fixed now, or whether you should only put the time and investment into doing that when a user reports to you that they are having a problem with it.

It’s your call. I, personally, would probably want to fix it immediately if that was at all feasible, because of the high risk of public embarrassment as well as potential legal action, but you might see the call differently.

You also need to consider whether internal developments and third party systems need to meet the same standards. This usually depends on the reason for those standards: naming conventions, commented code and internal documentation help when maintaining systems. If the third party is responsible for maintaining their systems, maybe they don’t need to follow your coding conventions…

…but presumably you have the same responsibilities regarding accessibility of services you provide, whether or not these were developed by a third-party or by yourself, so it is just as important to ensure that third party code is accessible as yours is (and again you’ll probably have to decide on a case-by-case basis how to handle it if it isn’t).