What about integration?

... about doing the right thing ...

To make the web and all the computers in the world speak with each other in such a way that communication is not only possible but sensible, there must be laid out a host of standards that most if not all must follow.

Such standards makes sure that we all can work together, and those who breaks standards for proprietary solutions only to make more money I have little or no respect for. Microsoft is notorious for doing this, and there are a lot of "sinners" out there who believe more in immediate and future profit than the purpose of their products, no matter the promises of prosperity in being successful through quality.

Understanding

The most important detail people tend to forget when communications between computers is concerned, is that we don't really need to speak the same language; only understand what is said. Protocols, in other words.

A protocol in itself is not a language; it is a means of moving one piece of information from one entity to another making them both able to understand what data is available. The interpretation of the data comes second, and is - at best - only of further dogmatic value.

In such, we can expound the term 'protocol' further to include a set of standards in an attempt to change the dogma into actual interpretation and implementation.

Go for the throat, or the jugulum?

Too often we find we need to take a pragmatic approach in interpreting dogma into useable basis for understanding. A sentence alone with a certain number of words can mean two completely different things when the words are shuffled around, and this is in itself one of the biggest problems when translating word-by-word from one language to another, and hence is never used seriously. We have the same problems with computers; something said here doesn't guarantee its said there. In fact, there are better guarantees that the latter will happen.

To avoid data-quality deterioration through one-to-one translation we must not only follow standards, but take it one step further; never ever assume we have interpreted correctly, not even the the very same standards.

Sounds simple, doesn't it? Trust me, there are projects out there who apparently do everything right, and still get things wrong. Not to say they fail completely, but more renders them half-useful, which to any serious contender is unusable. You see the problem now, don't you?

Proprietory laboratory

Can we create standards that hold the final answer? In a word; no. The standards will evolve as we do, rendering parts or wholes of them unusable, distinct, bloated and / or too abstract for actual use. The pragmatists of the world will always breach a standard.

And we approach the intent of this small ramble; pragmatic project design that is implemented non-pragmatically. Cute words put together, I'm sure, but this very site is meant to be an approach to such a beast; there is no part of this site which relies on non-evolving standard. Uses them, of course, but can adapt to technological advances as they come. Examples; a switch from HTML 3.2 to HTML 4.0 Transitional; 5 minutes. Implementing and moving of the whole site to a new server; 1 minute. Creating a totally new design (portal); 15 minutes.

Often we find we need to run a POC (Proof Of Concept); small snippets of code, or a full-blown prototype. These are pragmatic approaches to development. But there is a missing link here; what happens when we take the pragmatic, and wants to set it to a production/dogmatic environment? A lot of trouble.

Here is one of the biggest clues I've got; Keep rules in content management to restrict or change content, out-source styles, and keep functions for items that you know might change later; all for the wonderfulness known in the pro grammatical world as MVC modelling. Here, the model is Content Management and deployment, the view is the designs, and the controller is all the functions attached to the user interface and navigation.

Do it right, right away!

Time is any developers enemy. We simply aren't given the full time we need to create standards-compliant, detailed, picky, strict versions straight away.

My trick is simply not to trick; I use a number of tools to help me make sure my end result is done the right way from the get go. I use XML/XSL to parse me structured HTML 4.0+, Python and 4Suite to give me a prototyping engine I've written in XSLT (remember; [standard-xslt] is a template engine, and is the perfect tool for creating lots of the same code), editors with integrated validators/syntax checkers (for both [standard-html] and [standard-css]), external sites for validation ([w3c] and Site Valet), and of course all the FAQs I can use. I avoid too much [js] (or - at least - try not to depend on them), avoid too much tables (bloat and "not the right way"), and generally keep to the golden rule that - if the world applied it, it would be peace and unity wherever we went - "KISS - Keep It Simple, Stupid!"

Things are - as a general rule - made too complex. Or rather, they are designed poorly in the sense that they scale bad, have bad MVC separation, and are lousy at foreseeing what happens 6-12-24-36 months down the road. Don't do this. Do the right thing instead.