Overview

Engineering

Coding Efficiently

Visual Basic & Excel

"Coding or writing computer programs is not the objective.  It is a means to an end.  It is a way of creating a tool in order to gain more control so that we can all do our jobs more effectively.  Coding is not what we do.  Engineering is."

"Does one adapt the users to suit the tools or does one adapt the tools to suit the users?"
 

Engineering

I was hitching with a friend on route to rugby practice during my last year at school with a friend.  On that particular day an engineer picked us up.  The conversation quickly went to what we were going to study the following year.  I was heading for the Mechanical faculty and my friend for the Electronics department.  He urged us to reconsider... "They are going to screw your minds up... you will never look at anything the way you do now" he said.  Being 18 years old and seniors at school we were arrogant (and ignorant) to the max.  We promptly ignored all he said.

It was not until a good few years after we both had graduated whilst sitting around a fire one evening that our conversation returned to our friendly engineer-chauffeur.  It had become impossible for us to look at everyday objects, the fire we were sitting around, the beer bottles, the wine glasses, the window panes without engineering the object from beginning to end.  We had become exactly what he had predicted we would become... problem solvers without an off button! Sad but true.

Ultimately if one takes all the mathematics and technical engineering know how out of ones 4 year university education and the experience gained thereafter then one is left with an education and experience base solely directed at solving problems... regardless of their nature.

We dwelled on the topic and laughed at ourselves but ultimately came to the sobering conclusion that we were problem solvers with our hands tied behind our backs.  We always had to solve problems based on the constraints imposed on us by our clients.  Whether in a steel mill, on a missile project, or doing general consulting... we were always solving problems based on client constraints.  To be fair, that was also the driving force behind engineering improvements, new techniques and processes.  If what we knew or could do did not fit in with what our clients wanted then we had to go back to the drawing board and come up with a different solution until our clients were happy.  The best solutions were always realised when we could offer a solution where the client had to change his working practices as little as possible.

It is therefore the ability to solve problems within the constraints and working practices of our clients regardless of the tools and techniques that are required that makes for good engineering practices and therefore sound solutions.
 

Coding for Efficiency

Whilst doing my Masters Degree I had to develop software to simulate the airflow around vehicles.  This basically involved creating a grid of small cells or cubes around vehicles and then solving the airflow inside each little cube.  By solving the flow in each cell one ultimately solved the entire flow field.  The smaller the cubes the more accurate the answer.  Considering that one had to go at least 3 car lengths ahead of the vehicle, 5 behind and 3 above one needed a vast number of cells.  The opinion at that time was that one needed 1 million cubes per cubic centimeter to solve the flow properly.

Wishful thinking, as computers simply did not have the umf to get even close.  The computers at my disposal could handle a maximum of about 1 million cells for the entire grid.  This meant that you used as many calls as one could until the computer ran out of memory.  It goes without saying that sloppy coding meant less memory available to run the simulations.  The coding therefore became a game of writing programs as efficiently as possible in order to have as much free memory as possible available for simulation.  Knowing the ins and outs of a computer language ultimately only made up a small fraction of the coding process.  Most of the development time was spent optimising algorithms to ensure efficient coding.

In essence this meant that one had to write code very carefully in order to keep the program's size and memory requirements  down to a minimum.

This approach to coding has been with me ever since.  Throwing code at a problem until the answer eventually pops out is often a very poor solution despite getting the correct answers.  Inefficient coding wastes memory resources which drives the machine requirements upwards which ultimately costs more money.. for no real reason.

My staff work and code on bottom end machines.  What is the point of having a development department running on top end machines when the users are not?  My philosophy is that the developers should sit with the same speed and calculation handicap as the users.  It forces them to code more efficiently.
 

Visual Basic and Excel

Automotive Windtunnel testing involves continuous test "runs" with brief stops for data analysis and model modification.  Data analysis has to be fast and efficient as modifications often depend on the results of previous tests.  With tunnel rental in the region of GBP 2 500 per day, one ideally wishes to test and not sit around and stare at data for hours at a time.

It was during a windtunnel test program in 1998 at the University of London that I was exposed to the latent power of MS Excel for the 1st time.  The windtunnel manager had written a program inside MS Excel using Visual Basic for Applications (VBA) to read and display basic windtunnel data.

Although I eventually wrote a data capturing, analysis and graphing tool for wind tunnels, it was not until I was working as principal engineer on safety systems a few years later that I first had the opportunity of applying VBExcel outside of hard core engineering analysis.

Our Quality guys were by then all using MS Excel to log & capture checks & standards for a new Rover project that we were working on.  They were fighting a loosing battle with all the cutting & pasting that was required to reorder and re-present the same data pending the requirements of the different departments.  I think it took a week to automate their processes using VBExcel.  They were over the moon with a button click replacing a weeks work (literally).  I was even more elated regarding the potential that I had at my fingertips.  I had to wait another 3 years before the potential would become anything more than a variety of ad-hoc stand alone projects...
 

Tourism

I was gathering information for a website whilst on a sabbatical from Engineering in a Tour Operators Office when I saw the familiar sight of Excel cutting, copying & pasting... this time to create an incentive program.  Despite using commercially available Tour Operator software for their FIT and Group department, the owners needed a tad of convincing that an automated administration system for  incentives was indeed possible.  Their agreement to the development of such a system saw the birth of  a once off ad-hoc project which was to be called the Incentive Builder.

Excel was already being used extensively, the data (services) that were being stored numbered somewhere in the 10 000's, the users number in the sub 100's so it was logical to me that automated Excel was what was being asked for.

Basing the Builder on Excel simply gave the users what they chose out of free will.  They chose Excel... so we stuck to Excel.
 

Microsoft product screen shot(s) reprinted with permission from Microsoft Corporation.
The Destination Builder© 2005 source code, working methodology and related documents remains the property of P3Projects.
Unauthorised use and duplication is strictly prohibited in any form.