Left-field assignments

So, what makes a job or task suitable for our 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, I can use regular expressions, 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 I have been able to substantially reduce the time to completion, but that has often meant dropping the idea of the original diagram the client was wanting. 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.

However, that does not mean that diagrams cannot be done, just maybe not in the type envisaged by the client. For example, I had a request for a UML diagram for a client’s object-relational database schema. That would have taken months, but instead, I created a VB utility, 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.

If you have tasks with time constraints, I can help you with them, but you may need to be open to alternatives that meet your needs, while maybe giving you some value-added.

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.

I am opportunistic, in that I will use whatever is at hand at the workplace, and appropriate for the task.

For documentation jobs, I will usually use the VBA in the MS Office product that the output uses. For example, if the output is a Word document, I will 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, I write scripts in the VB or javascript that Windows provides. For web servers, I use PHP.

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. For many tasks, I program using multiple languages simultaneously, according to what is best for each part of the solution.