if it ain’t broken…

some days ago, i got a document from the company that i’m working for, stating a project’s technical guidelines for a client to be signed off. most of the vocabulary was right, but sometimes wrongly used, as technological clichès. this mentioned document serves as a template for most projects, and i imagine that for a while it has not been revised in detail, as it seems to work, seems not to be broken.

it also happens with websites that features are not improved or re-envisioned because they seem to work fine. even companies have the same approach, continuing to do things their way because it seems to work fine, it seems not to be broken.

and if it is not broken, why change it?

first, let’s think that perhaps what does not seem broken might be. we’re quite accustomed to ‘see’ when something’s broken, but what if we canot see it? then we suppose it is ok. but there are new realms of broken that are not as obvious as cracks in the wall.

like with our health, perhaps a preemptive approach might help in those cases where, similarly, we take some doses of vitamin c to prevent a cold, as usually we cannot ‘see’ we’re already infected, days before we can ‘see’ we’re broken.

among the strategies we can follow, we could:

• improve our observation skills/our sight by keeping informed of current standards and advances will make us be aware of new ways for things to be broken, and obsolete ways to deal with them


• studying and researching new and improved ways to do things might help us keep from making the same mistakes


• rewriting/redoing/revisiting stuff now and then, or even on a schedule manner, will help us identify obsolete or improvable items and pieces, and spot cracks on the walls


• changing our point of view, playing the devil’s advocate or even being over-critic about ourselves sometimes can give us interesting insights of what our own processes look like, and might allow us to spot critical, weak or improvable items, places or processes

the one i use to approach my personal (web) projects is, according to me, the simplest and less rigorous, but has assured to me enough success and reliability: i assume that, after a certain time (that varies per issue) it has to be broken, and most of the times it is, whether in language, content, semantics, usability, or just visually.

the web is a living entity, that evolves in time and every second has a new. different face. being part of that world requires the amount of self-maintenance a living organ will need.

check often and you’ll see things will be less prone to break. don’t wait until you revisit the site and get some broken image icons, or worse, the moment when your client tells you something is “not expressed that way anymore.” d’oh!