Frustration.. the refrain

Calmed down since that last post. Had a ciggy which was extra specially good, cause I quit last week.

Two points that continue on from that last post:

Firstly all programming is essentially object oriented. You write programs using a set of command. Each command does a descrete task, print to the screen, compare two quantities. These commands are the limited set of objects you have to build with. They are based on even simpler commands; the machine code that runs the computer, tells it to move a bunch of 1's and 0's from one part of the computer to another.

Simple little commands build up to produce larger commands, which are combined to make the programs we use everyday. Molecules make materials, materials make bricks, bricks make houses, houses make cities, cities make countries etc etc etc. On each step up that ladder we set in stone (no pun.. achieved) the functionality of the new object. A house is a house, it's made of bricks, but you can't use a house to make a well (not without tearing the house down). We loose something of the properties of the constituent parts. A house is a better place to live than a pile of bricks, but does not have as much potential.

Point two. A program is a tool to solve a problem. If the tool doesn't fit the problem, the problem doesn't go away.

If the tool doesn't fit the problem we have two solutions:

The problem must change. This happens all the time. I want to sell my books online, but the website can't do that. I want the text on the left, but that's not possible. The problem doesn't get solved, until the tool is changed.

Solution two, some middle man/ware has to make up for the tools shortfall. Some intermediate that fills in between the tool and the problem. Ussualy that's a human. How many people have jobs that involve collating information into a specific format because the system it needs to be fed into can't cope with it any other way. The user has to serve the computer. A great example are automated switchboards, it really isn't easier for the user to have to wade through the comuters list of annoying options. It's a reversal of subject/object - who is the captain and who is the ship.

This human as middle ware issue is very common. It's slightly depressing (so many things are). In the past we did all the brain work. We calculated the accounts, we maintained the Human Resources records. Now computerised tools do lots of the work for us. But we still have work to do. Ussualy it's a task of data entry or mediation between systems. Our skills shift. Who needs brain maths when you have spreadsheet or calculator. Labour saving often includes thought saving. This is a negative path to travel. What I'm implying is that we the human middleware no longer need to perform the clever stuff, just often repeatitive and dull gap filling between the tools we use and the problems that actually exist. That's not rewarding work. It's not even mentally demanding work. It's akin to factory labour.

The more monolithic an application, the worse designed it is, the more unflexible it becomes and the more we are forced into the middleware role.

Hmmmphhh.