Facial Hair and Funky Job Titles – A Personal History of the Internet Age

I had a rare technical issue with my blog recently. My e-mailed cry for help was answered and my problem resolved. The helpful soul at WordPress who aided me in my time of need was Jackie, who rejoices in the title of Hapiness Engineer.

I’d imagine that WordPress must have a novel and somewhat refreshing approach to Job titles.
We could apply this to Deb, for example. As a Health Professional working with the under fives, she could be a Small Human Maintenance Consultant.

There are some similarities between Deb’s job and my own. Whilst I have on occasion dealt with people whose job titles include words like ‘Chief’ and ‘Officer’, I also occasionally have to deal with the aftermath of toys being violently ejected from prams.

At the moment however, I find myself leading a team, all of whom are rather younger than me. This presents a number of challenges.

The realisation that I have children that are older than some of my colleagues is particularly acute when we discuss technological issues.
In computing terms, I grew up before the Internet was the all-pervasive presence it is now.
I learned to touch-type many years ago, in order to reduce the number of typos I made whilst writing code.
This is beginning to feel somewhat quaint with the proliferation of declarative development environments and technologies.

I suppose the point of this post is to wander back through the technologies that influenced my career as a programmer and explain why they are so important in shaping the technological landscape we now operate in.
Continue reading

HTML 5 and Google Maps for the Milton Keynes Tourist Board

As well as being culturally diverse ( the Welsh enclave is currently painting her toenails upstairs in the bedroom) Milton Keynes does have one or two places of interest.
Yes, there are quite a lot of roundabouts. There are also connections with Formula 1 ( Red Bull Racing has it’s factory here), the birth of modern computing (Bletchley Park), and a crude but effective measure against the risk of disease in livestock (i.e. by making them out of concrete).
Wouldn’t it be handy if I could knock up a web-page with map locations of these and other sites of interest, ready for visitors to our fair city.
I stumbled across something that fits this particular bill when browsing through the HTML5 new features on the W3 Schools site.

One of the really good things about this particular site is that they’ll give you source code to play with and to observe the result of any changes.
The code, shamelessly plagiarised here, is to demonstrate the capabilities of HTML5 in terms of Geolocation – i.e. it works out the current position of your computer and displays the result in the form of a Google Map.
Whilst playing around with this, it occurred to me that you could pass in any co-ordinates of longitude and latitude and produce the desired map.

Currently, I don’t believe that Milton Keynes has a Tourist Board. If they do decide to get one, they might find the following useful… Continue reading

Setting the Windows Path Variable for Cygwin…when you’re not allowed to

Several years ago, whilst working in an organisation that thought that organising functions into silos was an outstanding idea, I needed to have a UTL_FILE_DIR added to the init.ora ( this was back on Oracle 8i, since you ask).
Not having sufficient access to be able to implement this change myself I had to request it from the DBA group….based in Madrid.
The request was to enable us to write to a directory on the same server as the Database. Not being involved in the physical configuration of the database, I left it to the DBAs to pick which directory to use.
This change, which would’ve taken me 2 minutes, disappeared into the system. The DBAs had to refer it to the Linux Admins( Poland), who had to then discuss the matter with the Storage Team (Switzerland).
End result : six weeks later I get an automated mail saying that the call has been resolved…and I end up with a unix environment variable called $UTL_FILE_DIR. Oh, how we laughed. Continue reading

Axiom – a framework for sanity in Software Development

After many years of suffering from the slavish insistence on adherence to whatever development methodology was prescribed ( or in fashion) at the time, I’ve come up with a framework to apply to these methodologies.

The idea behind this is to :-

  • avoid cutting down any more rainforest for use in utterly pointless documentation
  • avoid fatally compromising application design due to the constraints imposed by the methodology
  • state the blindingly obvious for the obviously blind

Software development is a fundamentally simple process, perhaps most succinctly described by Dan Gookin in C for Dummies which, paraphrased, is something like

  • Come up with an idea for a program
  • Write the program
  • Curse the compiler for it’s cryptic errors
  • fix (repeat previous step)
  • Finish program
  • Go to the pub.

OK, the last step is mine, but you get the idea.

Incidentally, his tips on passing as a C programmer included being able to quote spontaneously from Monty Python’s Holy Grail. This proved to be uncannily accurate ( although on this side of the Atlantic, The Life of Brian seemed to be rather more prevalent).

On the remote chance he’s reading this, I’d just like to say to him – “Nice one Centurion !”

Anyway – here it is – Axiom – 8 golden rules to apply to whatever bloated or crazy methodolgy you’re tied to :-

RULE 1 – Do what works

Pragmatism is the watchword here.

If the program spec is part of the deliverables and is required for ongoing support ( a bit of a joke, but some methodologies insist this is so) it could make more sense to write it after you’ve written the code. That way, at least it’ll describe what the code actually does.

Of course, you still need something to code to. In my experience a quick and dirty “fag-packet” spec ( i.e. written on the back of a fag-packet) can suffice for this purpose and be tossed once you’re done.

If you don’t need a full-blown technical spec before you start coding, then don’t do one.

RULE 2 – Before starting – be clear on the user requirements and Project Deliverables

It’s pretty important to have a clear picture of the business process(es) the application is required to support.

It’s an outstandingly good idea to know what the requirements are and to have them signed off in blood ( preferably someone else’s).

I’ve lost count of the number of times that projects have gone over time and over budget due to last-minute changes to requirements, usually as the result of not waiting for requirements to be finalised before starting to code.

The argument for doing this is that the requirements sign-off process is usually rather laborious – so many signatures are required that the requirements document spends an inordinate length of time being reviewed and re-issued with – generally – minor changes. Then suddenly, someone will come up with something fairly fundamental and you have to unpick large chunks of what you’ve done to that point.

At this point, I’m sure that any members of the Church of Agile will be smiling smugly to themselves. However, I have worked on at least one Agile project that suffered this affliction shortly before development was due to complete and suffered significantly as a result.

RULE 3 – Before starting – be clear on the context in which the application will be used

It’s a good idea to know what the usage volumes are likely to be and what existing processes/applications are you going to need to interface to.

What’s the hardware/software architecture ? Are you likely to beef it up to handle the new application/functionality/ load ?

RULE 4 – Pick the right technology for the job

Just because all the cool kids are using it, doesn’t necessarily mean that it’s here to stay, or that it’ll do what you need it to do.

Equally, just because it’s what you use now and have done for the last 10 years doesn’t make it the right choice.

You also need to give careful consideration to issues such as :-

  • vendor tie-in
  • recoverability of the entire application architecture
  • whether the swish new tool your using will continue to be supported against the next RDBMS/Application Server/Java version that you’ll need for another architecture component.

This is especially important if you’re working in an environment where the phrase “Best of Breed” gets used a lot.

From my limited understanding, the etymology of this phrase seems to have it’s root in the world of animal shows – Crufts in particular.

It is therefore, not entirely surprising, that this approach  so often results in a dog’s breakfast.

RULE 5 – Agree and enforce coding AND commenting standards

Whatever technology you’re using, standards are there for the protection of the poor souls who’ll have to maintain the application once the development team have done their worst and the Application is in production. In many places, the development team will – at least partly – be required to perform this role. Therefore, it’s probably worth noting that, as a developer, standards are there for YOUR future protection and happiness.

RULE 6 – Test for functionality AND performance

Another one of those dreaded phrases that occasionally surfaces is “Live Proving” .

Roughly translated, this means “let’s just throw it into production and see what happens”.

The results are often hilarious…from a distance.

More common is that the need to test functionality is recognised, but tightening time scales result in the time allocated for testing being squeezed. The end result is usually that, whilst most of the functionality is tested, at least to an extent, the more tricky/expensive/time-consuming issue of performance and load testing tends to fall by the wayside.

Once again, we’re back to the Live Proving stage ( more accurately known as “suck it and see”), with the risk that your application is going to keel over slowly but inexorably like the statue of a deposed dictator.

RULE 7 – Ensure that the application is sufficiently documented

Users need to know how to use it

Support need to know how it all hangs together, and what you meant it to do.

Post rollout maintainability is considerably enhanced if code is adequately commented.

Taking a packaged procedure for example. Header comments describing the values required for each parameter ( possibly including where they come from); the functionality being implemented by the procedure, and – if relevant – where it is usually called from, provides a context for the poor put-upon Support Team before they have to start looking through any of the actual code.

RULE 8 – There are exceptions to EVERY rule

I’m tempted to say here that you should never trust an argument that starts with the word “always” or the word “never” – but that would just make me look silly :-)

On a more serious note, the number of times I’ve seen projects fall victim to technological fundamentalism – “you can’t use an implicit cursor/trigger/Javascript because it’s evil” or, notably “you can’t write a spec for that bit of the system because that’s not Agile” would tend to re-enforce RULE 1.

As you can probably gather reading this, I could go on. Indeed, I probably already have.

Comments/arguments/fatwas welcome.