Left-field approach

So, what makes a job or task suitable for left-field treatment?

Most jobs have a certain level of quality and quantity expected of the output. In the case of documentation, if that cannot be done in the standard 3-5 pages per day in the time allotted, then some level of automation is required.

By its nature, automation needs sources that are mostly regular in structure. Outputs constructed of long tracts of narrative are generally not amenable to automation. For them, significant time can only be saved by reducing the scope of the content they cover. Having said that, regular expressions can be used, or build a parser, to extract meaningful information from large tracts of text. A lot depends upon any, even if loose, structure the information inherently has.

Diagrams are one area where there is opportunity to substantially reduce the time to completion, but that has often meant dropping the idea of the original diagram that may have been wanted. A picture can be worth a thousand words, but can take a lot longer to create than those words. When time is of the essence, a diagram, especially a big complex one, is inefficient to produce and difficult to maintain.

However, that does not mean that diagrams cannot be done, just maybe not in the type envisaged by the client. For example, the request was for a UML diagram for a client’s object-relational database schema. That would have taken months, but instead, a VB utility created in a couple of weeks, that created a fully-linked HTML file with class inheritance and foreign key tree diagrams, on-demand within 10 minutes! They still got their diagram, but in viewable chunks and with useful relevant details.

When faced with having to create a custom solution to producing or managing documentation, the approach has to be simple.

A forward process usually encourages a lot of might need that baggage collection that ends up being dropped.

Formalised jobs tend to use a set methodology, and a set suite of tools, as that is what is prescribed, mainly because the output is not really the final one, but needs ongoing improvement or updates, a process which benefits from such standardisation, as it ensures consistency of skillsets and processes.

However, one-off tasks, even big ones, are usually only concerned with getting to an endpoint, and the means is largely irrelevant. An example is preparing data from one system for input into a new system, or building utilities or scripts that aid that. The means is not reused, because it is not required again. It is scaffolding, and not part of a standard business process, which normal IT development is.

Be opportunistic by using whatever is at hand at the workplace, and appropriate for the task.

For documentation jobs, use the VBA in the MS Office product that the output uses. For example, if the output is a Word document, use Word’s VBA. Office products have the advantage that each comes with its own VB development environment, so no special tools are required, and so they can be updated by anyone with MS Office.

For processing outside documents, such as for files, write scripts in the VB or JavaScript that Windows provides. For web servers, use PHP or Python, though the former comes with many extremely useful extensions already installed.

The basics of programming exist in a programable calculator, providing a grounding in the basics of control structures and program flow. From there, other languages are variations on a theme. Many tasks will require programming using multiple languages simultaneously, according to what is best for each part of the solution.