2014/10/26

The legality and morality of IT solutions

I’m often found ranting and raving about the legality or morality; or rather the illegality and immorality, of some solution or other – more often than I care to admit. This post should hopefully clarify what I mean when I say it’s “illegal” or “immoral”. I should point out that I'm using these terms as an analogy in context of some IT solution and of course the legality of a solution in technical terms is an entirely different question. Morality never was very well defined.

For further clarification I should state this post is in regard of IT solutions and not the behavioural rules and norms of society in general. That some of those IT solutions I’ve worked on may conflict with what society would expect is a separate issue…

Legality - TFD defines legality as “A requirement enjoined by law”. The key word here from a solution perspective is “requirement”. If we assume that all requirements are mandatory (of course they’re not) then when I say some solution or part of a solution is “illegal” I am simply (pompously) stating that it does not satisfy some requirement or other. This may be acceptable depending on the clients view of the requirement as some rules can be, err, bent.

Unfortunately, I often find that it’s the non-functionals that get eroded first. E.g.:

  • “It’s acceptable that such-and-such a function doesn’t work with IE7 because it looks great on other browsers and isn’t worth the cost to fix it” – breaking a compatibility requirement.

  • “It’s acceptable that performance on some pages suck – it’s good enough generally!” – stretching performance requirements.


Or perhaps the worst (and all too common):

  • “Just dump all the user data to a flat file and e-mail it to the marketing guys – they need it now!” – violating security policy. If found out you could get fired, if leaked you could bring the whole organisation down – low probability but very high risk. It’s interesting that the business focuses on the “probability” whilst the IT dept. focuses on the “risk”…


Morality - TFD defines morality as “The quality of being in accord with standards of right or good conduct”. Oh dear, all very subjective. Who’s to say what’s right and what’s good? The architect of course! (arguments commence)…

Anyway, when I say some solution is immoral, then I’m just saying it doesn’t fit with standards and best practices in the industry. In terms of architecture this could be due to poor division of responsibilities, tight coupling between components and sub-systems, incongruence with organisational structure, inconsistencies in implementations, complex dependencies and so on. None of this is black and white and sometimes compromise is the best solution – so long as you can sleep at night. But there are reasons why this stuff exists – partly because it works, partly it’s old wives tales – you’ll need to figure out which is which.

 

We’re often asked to bend requirements. Sometimes it’s the right thing to do, sometimes it’s just the easy thing to do. In any case, like the law, ignorance is no excuse. Make sure you understand the requirements and if you don’t satisfy them then, well, that’s your call.

When it comes to morality it’s best to follow standards and best practice – most of the time – if only so you can avoid confrontation with the high priest of architecture (aka the Chief Architect). What’s right and what’s good is always worth the debate though – and a pint or two helps to lubricate the argument…

 

No comments:

Post a Comment

Voyaging dwarves riding phantom eagles

It's been said before... the only two difficult things in computing are naming things and cache invalidation... or naming things and som...