Custom controls on a Visual Basic form. (Photo credit: Wikipedia)
It became the norm’,
to fill up one’s form
With tons of controls
to avoid any holes
Add in some sex
with a VBX
Inside a frame,
controls all the same
The user went click.
The cursor would stick
An hourglass appeases,
as the progress bar wheezes
Although coding was sloppy,
it all fit on a floppy
How I miss thee, VB3,
Simplicity..
English: This is a general-purpose alphanumeric LCD 한국어: 범용 액정 디스플레이 (Photo credit: Wikipedia)
The device itself was rudimentary. Nothing more than a cheap metal casing which housed a small two-line LCD display and a flat ZX81 style keyboard.
“Can you make it look exactly like that?”
The assignment was for a large national breakdown operator and the devices lived in drivers’ cabs. They allowed simple communication between the drivers and the operators in headquarters. The original manufacturers of the units was now bankrupt and the customer wanted to replace them with cheaper modern commodity hardware. Ultimately, they wanted to enhance the units to offer much more functionality, but for phase 1, they didn’t want to scare the horses. After all, training a huge fleet of breakdown truck drivers would take some time.
My colleague studied the unit whilst mentally appraising the effort involved in replicating the look and feel of the user interface.
“As long as you leave one with us.”
So how hard would it be? Seeing as the hardware dictated that the only realistic programming language was Microsoft Visual C++, the answer was very hard indeed. Almost everything in C++ takes a surprising amount of code but if my colleague stood any chance of replicating the finer nuances of the device, he would have to resort to the dreaded owner-draw control. For ordinary controls which come as part of the operating system, Windows does all the hard work of drawing them every time something on the screen changes. For an owner-draw control, you have to write code. Reams and reams of it.
He took ages on those buttons. Firstly he studied the original, taking measurements and looking at everything through a magnifying glass to make sure he had the finer detail. The text on the buttons was not a standard Windows font either so on top of everything, he would have to create a custom font.
More than once I heard an “Aaaaaaaarrrgggh” from over the cubicle partition as he fought with the inner nuances of operating system libraries. After a month or so, he was ready for the first customer demonstration. I checked out his handiwork. It was an impeccable replica of the crude user interface. When the customer came in to see it, his brow wrinkled.
“Is there something wrong?”
“I was hoping you might smarten up the buttons to make them a bit more standard. You know, like the 3D look and feel you get with a Windows button?”
A quick look at my colleague’s face told me he was mentally counting to ten. A few moments clarifying what “exactly like” meant would have saved weeks of effort and considerable angst. Unfortunately, people specify things like this all the time and are usually disappointed with the result for some reason.
So why do they do it? They do it because it’s easy and requires little or no effort. Care and attention spent on requirements is seldom wasted.
example of Python language (Photo credit: Wikipedia)
Programming a computer is unlike most other vocations which are generally considered professions. Writing code is a creative process. OK, the requirements specification lays down the overall dimensions of the playpen. There might even be some coding standards somewhere on a shelf gathering dust. But within these constraints, the coder is generally free to craft the software any way they want. There is no right or wrong answer, and yet, computer programmers can be very critical of their peers’ programming style.
Some craft their code for brevity. To them, a single deviously, crafted line of code that performs umpteen operations is the pinnacle of the art. Others code for readability. They aim for such self-evident clarity that granny should be able to read the code and have a good idea about what’s going on.
Others code for performance, eking every last cycle of performance out of their composition, often at the cost of the former two. Some code from the hip, typing code in as quick as it comes into their heads. The backspace key is the first to wear out on their keyboard. Others take a long time working out exactly how to lay out the code before they ever go near a keyboard. The actual coding takes much less time than the planning.
I used to work within a team where one of my colleagues was a Christian. No problem with that, except he was a Christian with a capital C. When he introduced himself to people for the first time, he would include his religion in his first sentence. He used to update the comments in every routine he touched to include a verse from the bible. Often, they were poignant and very reflective of the code within.
Another colleague was a Black Sabbath fan. He used to replace any such biblical verse with lyrics from his favourite heavy metal tracks. Again, many were appropriate to the code. This silent coding warfare went on for years. Who knows how much mental effort and time went into the cleansing or infestation of the comments in this way.
To the rest of us, it was something to talk about and the contrast between the two sets of comments were often hilarious. But do I think that computer programming could ever be like literature? As much as I would like to believe it could be, I’m afraid I fear the answer is no. I just can’t imagine a book full of code would ever make the bestsellers list.
Having said that, here are some of the funny comments I’ve come across in my career in IT;
Options.batchSize = 300 // madness? THIS IS SPARTA
// I am not responsible for this code
// They made me write it against my will
// Dear future me, please forgive me.
// I cannot even begin to express how sorry I am.
double penetration ; // Ouch!
// I have no idea what this code does - I only changed line 1397
# To understand recursion, see the bottom of this file
...At the bottom of the file
# To understand recursion, see the top of this file
// I'm not sure why this works, but it fixes the problem.
// Somedev1 - 6/7/2002 Added temporary tracking of logic screen
// Somedev2 - 22/5/2007 Temporary my arse!
// You may think you know what the following code does.
// But you don't - trust me
// Fiddle with me, and you'll spend many a sleepless night
// cursing the moment you thought you'd be clever enough
// to optimise the code below.
// Now close this file and go and play with something else.
// Drunk, fix later.
// Magic - don't touch!
// Not to be used in a production environment
The main cast of The A-Team. Clockwise from top: H. M. Murdock, B. A. Baracus, Hannibal Smith and Templeton “Face” Peck. (Photo credit: Wikipedia)
Required viewing for children young and old used to be the A team. It was fairly formulaic. Within an hour, you knew that B. A. Barracus would refuse to get on a plane, only to be tricked or sedated by the others in the team.
Howling Mad Murdoch would get to jump into some kind of plane or helicopter and pilot it with ease. Faceman would use his charisma to acquire whatever the team needed at the time.
My favourite bit was where the team would be trapped somewhere in an old factory or barn with a clapped out vehicle of some sort. The iconic music would burst into life as they welded and bolted unlikely looking accoutrements onto their battle wagon of choice before going out and blitzing the bad guys. Zillions of bullets would fly off in every direction and miraculously, no-one would be killed.
And at the end of it all, Colonel Hannibal Smith would utter those immortal words “I love it when a plan comes together”. The irony of course was that he never, ever seemed to have a plan up front.
The truth is, however, that no endeavour of any substance is likely to succeed without a plan and the bedrock of any plan is formed by the estimates for each task.
I still remember the first programming estimate I ever made. It was for a survey that was to be sent out to loads of people on floppy disk. The recipients would put the disk into their computers and answer questions, saving the answers back onto the disk before returning it. I was young, overconfident and lacking experience. I sucked my breath through my teeth (because that’s what I thought people did when estimating) and came up with my answer; a day. One working day. Utter madness. The design alone would take longer than a day.
Her Majesty’s Royal Artillery know that their entire craft is based on estimation. The forward observer has to estimate where he is on a map. He radios in the grid co-ordinates of where he estimates he wants the barrage of artillery to land. The guy in charge of the battery has to estimate the atmospheric conditions and wind speed before the gun fires an initial sighting round.
If all goes to plan, the forward observer will see where the shot lands and radio back with feedback. Another shot follows and so it continues until the forward observer has seen sighting shots on both sides of the target, at which point he radios a single word; “bracketed”.
The battery fires another shot exactly between the two which is hopefully direct on target, at which point the forward observer radios back “fire for effect!” This innocuous three word command results in all hell being let loose on the poor target.
This protocol is the only way to get a programmer to give a good estimate. Programmers hate giving estimates because it creates an expectation. Understandably so, because the craft of computer programming is complex and you don’t know everything up front. You need a couple of sighting rounds to get on target.
Firstly, ask them if they can think of a similar task that took less than the task in question and how long that took. Then a similar task that took longer. If the guy’s worth his salt, these two extremes won’t be too far apart. Bracketed! The estimate you’re looking for must lie between the two. Once you have these estimates from everyone in the project, fire for effect!
Abstract icon of Enterprise NX-01 of Star Trek Enterprise (Photo credit: Wikipedia)
After the big comfy armchair that was BP, my second employer “Pentyre” was more like a roller coaster. After the comfort of a blue chip company, I was brought down to Earth with a bump when I was summoned in to an all staff meeting the week after I joined. The entire company easily fitted into a small room. I was one of 7 software developers. The MD explained that a customer had reneged on a bill and the company was in real trouble. Some of the directors were going to forego salary for a couple of months and hopefully, everything was going to be OK. Had I made the mistake of my life ?
I very nearly ended up missing out on working at Pentyre altogether. I had already accepted a job with another company, but there was a recruitment consultant who just wouldn’t take no for an answer. He insisted I visit Pentyre to see what they had to offer. So after work one evening, I turned up outside their offices for an interview. First appearances weren’t too promising – a converted factory with a tatty sign outside. I was shown up the stairs into a demonstration suite. There were various devices around the place; pagers, phones, cameras, alarms, flashing lights.
I was interviewed by the MD himself. An unassuming middle aged man called Malcolm, impeccably dressed, short with wispy white hair. He gave me the potted history of the company, which didn’t take long. After a long career in IBM, he had taken his terms and used his severance money to start up the company. He then took me through a demonstration of what their software could do. It was a dazzling display as he made the various devices do their stuff with just a click with his mouse. The inner geek in me was hooked.
He then took me on a tour of the building. At the back of the building was an area that looked a bit like Q’s workshop out of the Bond movies. There were machines everywhere in various states of assembly. On the benches there were oscilloscopes and multimeters. Propped up against one wall was something called a protocol analyser. The last time I had heard of anything like it was during an episode of Star Trek. Dominating the middle of the room was a train set. I looked at Malcolm quizzically and he nonchalantly explained that the reason it was there was to test the train radio system they were developing for the London underground.
I was mesmerised. I simply had to work for this company. As we went back up the stairs to talk turkey, it was obvious I was hooked. Malcolm asked what it would take for me to go and work there. A brief exchange later, the deal was done. I started work there a few days later.
It was an amazing place to work. The nice thing about working as part of a small company is that every single person really makes a difference. Every few months or so, there was a new assignment – usually involving some brand new technology. My first job was all about pagers. Back then, if you had a large site, the only way to keep in touch with your workforce was to give them a pager. I also developed a building management system, some modelling software for a steelworks and CCTV systems for prisons and nuclear reactors.
My time at Pentyre taught me the power of small teams working together without constraints. The productivity was amazing. There was no demarcation; you sold, designed, built, tested, installed and supported every bit of software that went out the door. Not all the technology was all it was cracked up to be. We worked on a project to detect faces in crowds. I couldn’t get the face recognition software to recognise me standing perfectly still at less than two paces. Voice recognition was similarly inaccurate being unable to determine the difference between “Chicken Tikka Massala” and “Land Rover” even when spoken slowly and deliberately.
The technology failure that has tickled me to this day was DCOM. Launched with some fanfare, DCOM (or Distributed Component Object Model) was Microsoft’s attempt at a computing model for distributed computing. In order to test it, we set up two machines. On the first, we coded a simple button with the label “Sausage” which would then send a message to the second machine which would respond with the on screen message “sizzle”. It was the simplest test imaginable and we were used to getting such things working.
Even so, after a whole morning of messing about with various different settings, we simply couldn’t get it to work. Frustrated, we went off to lunch. When we returned – there was the “sizzle” message on the second machine – we obviously hadn’t left it long enough!
basic coding (Photo credit: Terry Freedman)
When I started programming computers in the 1980s, life was really simple. Networking was in its infancy and the Internet was just a twinkle in Tim Berners Lee‘s eye. So you didn’t have to worry about communicating with other machines. There was no windowing concept, so the screen was only two dimensional. Computers tended to just be running your program so you were in complete control. All you had to worry about was lighting up the right bits of the screen and dealing with what the user did to the keyboard.
As time went on and computers became more advanced, the complexity increased. Computers started to talk to each other through something called a database. People will always argue about who invented the idea, but windows arrived along with icons and a mouse. Suddenly, the user could do exactly what they wanted and you had to share everything with other computer programs.
The Internet changed the way we think about computing completely. Suddenly computers talked to each other. No longer could you be prescriptive about what was on the other end of the conversation. Smartphones changed the game yet again. Suddenly, there were a multiplicity of devices all with different operating systems and different limitations.
Having been in IT for a quarter of a century, as you would imagine, I have worked with a large number of different software development technologies and computer languages during my time. My first exposure to programming was at home using BASIC (Beginners All-purpose Symbolic Instruction Code). As the name suggests, it is a great starting point for anyone. The language reads almost like plain English. Contrast that with the other computer language I used at home which was Z80 assembler which is akin to programming in hieroglyphics or runes.
When I first started programming for a living, I used something called ADABAS Natural from Software AG. This was not programming per se, but more like writing down what you wanted to happen and then handing it to your butler who took it away to some real programmers who turned it into a program. You never felt close enough to the machine to really feel like you were programming.
At college, I learned Pascal, which I took to like a duck to water. Pascal is like an extremely fastidious bachelor who lives alone in a penthouse apartment. Everything has a place. Don’t even think about trying to use something before you have told me exactly what it is or where it lives. The nice thing about Pascal was that you ended up with a very nicely structured (albeit wordy) program. It was also nice to use Turbo Pascal from Borland. In their heyday, Borland provided some of the most excellent programming environments around.
Later, I started to use DBASE from Ashton-Tate which was my first exposure to database based programming. As a language, DBASE was powerful but interpreted one instruction at a time, which meant it was tediously slow. It was a natural progression to use Clipper which retained the power, but it was compiled and so comfortably faster.
I never really liked C which was like a simpleton backstreet bruiser with extremely poor hygiene. You had to be really careful what you asked him to do, because he would take it completely literally. It was very easy to machine gun yourself in the foot.
My favourite language was Visual Basic which was like a man with a van – pretty handy for just about anything. You could knock up a program in no time and copy it to another machine using a floppy disk. Because of progress, Visual Basic became more like a man with a fleet of articulated trucks all filled to the brim with specialist tools for just about any task. You could do a lot more – but the simplicity had disappeared.
I would like to teach my nephew and niece about the joys of programming, but the barriers to entry are high. I was delighted when I heard about the Raspberry Pi. This Cambridge based initiative is all about providing a simple computer at an affordable entry point. I registered my interest straight away, but unfortunately I was not alone and stocks are hard to come by.
So I settled on the Cubox instead which is a similar concept, but a bit more expensive and a bit more polished. It includes things like a case and a power supply. Maybe my nephew or niece will grow up to develop the next great leap forward to make programming even more complicated!
I can’t remember exactly how old I was. Probably 12 or 13. Mum had dragged me round to her friend’s house. I hated going to her friend’s house. For one thing, it was the most interminably boring thing in the world sitting there whilst they drank tea and talked about what were, to me, the most mundane subjects in the universe. Not only that, but I wasn’t keen on her friend either. She was nice to us when mum was around, but unpleasant when we were alone. So, as you can imagine, it brought out the worst in me.
On this particular visit though, I learned that they had just bought a computer. I was intrigued. I’d never seen one. I’d heard about them on John Craven’s Newsround – sure, but never had I seen one in the silicone. I asked if I could have a go, and I was left to it in front of a pristine Sinclair ZX Spectrum. It was plugged into an old portable TV and there was a tape machine to one side. I took the only tape they had, “Horizons”, read the insert and followed the instructions. I was completely enthralled. I went through every program on both sides of the tape and played with that machine for hours. For once, it was Mum who wanted to go home and it was me that wanted to stay.
I didn’t think too much more about it and before I knew it, Christmas had arrived. Bleary eyed, myself and my brother headed downstairs at some ungodly early hour to open all our presents. I remember dad had taken up position with a camera to capture our expressions as we came through the front room door. We groaned as he captured us in our unkempt, half awake state and descended upon our presents. I was initially disappointed – was my pile smaller than usual this year? The first present I opened turned out to be a tape machine, which I thought was a great present and I spent a few moments thinking about what I could do with it before moving on the next present.
It wasn’t long before I could make out the box inside the wrapping paper and my heart sang! It was a Sinclair ZX Spectrum – fantastic. I couldn’t wait to get it open, plug it into the TV and explore the possibilities. Again, I spent hours in front of that machine, being physically pulled away for Christmas Dinner.
After the Christmas break, back at school, the playground talk was all around what we had been given for Christmas. Amazingly, my small circle of friends had all been given Spectrums! We were told off more than once on that first day for talking incessantly about computers.
I remember a BBC TV program called “Me and My Micro” where they explored the possibilities of these new microcomputers that were spreading like wildfire. I remember watching the presenters program the computers, showing you the BASIC language and what you could do with it. I decided that I wanted to learn how to do that and fished out the orange book that came with my Spectrum and read it cover to cover whilst trying things out on the machine.
A little later that year, mum was pregnant with my sister. I know they talk about women “blooming” during pregnancy, but that’s not exactly how I would describe mum’s experience. I used to arrive home from school, walk in the door and ask dad how mum was. Invariably, he would say “the same as yesterday”. Deciding that discretion was the better part of valour, I would lock myself away in my room programming my ZX Spectrum. I don’t think the time was wasted – I wrote a number of games, at least one of which was published.
So – it’s no surprise that I ended up in a career in software development. I guess I should have seen it coming.
A topnotch WordPress.com site
A Searchlight Casting For Faults In The Clouds Of Delusion
Reviews of Vintage Science Fiction (1945-1985)
“If you listen carefully, you can hear the world’s song of hope.” – The Priestess, 13th Age
Esss mah Deeee!
RPG Creations and Musings.
Devouring Role Playing Games since 1975
Service Industry Stories and More Since 2012
The world can be amazing when you are slightly … strange!
A Blog About Ewen Cluney's Game Stuff
Life began with water...
support site for the Old School DM family of iPhone and iPad apps
Norwegian roleplaying games in English
Still Trying to Figure Things Out
The UK's Premier RPG Podcast
The Art and Craft of Blogging
This WordPress.com site is the bee's knees
Tabletop RPG Reviews and Articles
blog about life
bluedeckshoe.com 