lectroid.net

Like most newspapers, the one(s) that I support are trying desperately to control expenses and are looking under every rock for spare pennies. One tactic oft deployed is the “write once; deploy many” approach to software (or more commonly: “buy once; deploy many”).

The problem is every newspaper is unique. Simply put, what works for one doesn’t necessarily work for another.

As an example, the papers I support were recently introduced to a new web content management system. The system isn’t really bad, although there are some latent issues, but every paper got — or will get — the exact same interface.

But every paper has subtle differences in the way they do things and this “standard” interface causes issues. It slows down production, forces workflow changes, and even in some cases forces product changes — all in the name of saving some nominal amount of money.

To avoid such nastiness, those papers lucky enough to have access to journo-geeks have them work up all manner of band-aids and workarounds. Yours Truly is certainly guilty of such hackery. The problem here is that who’s gonna support said band-aids if/when that journo-geek disappears? What if your journo-geek gets hit by the proverbial bus? Furthermore, what will happen when the offending system/application/whatever is updated? Will the band-aid update with it or will it blow apart requiring frantic emergency pages in the middle of the night?

The obvious (to me) solution is to shoot for “one size mostly fits all,” then provide ways for the journo-geeks and their ilk to tweak and modify things as they need. Make that way flexible yet scalable (upgradeable). And for crying out loud, make it documented.

Make it an interface so that programmers can modify your application.

Get it?