Tag Archives: software

Sep 11 2013

Performance

English: An example of the newly-designed Guin...

English: An example of the newly-designed Guinness glass, put into use in April 2010. It was designed to gradually replace the older tulip-shaped glasses. (Photo credit: Wikipedia)

An excited member of my team once came up to me and told me he’d sped up a subsystem by a factor of 700 times. Once he ran some full system tests, we found that the optimisation had absolutely zero performance impact on any observable aspect of the system. The online requests still took the same amount of time. There was an overnight batch that took almost exactly the same time as before we applied the optimisation. The guy was crestfallen.

How many times have you been on the phone to your bank and the operator says something like “Sorry for the delay Sir, the computer’s really slow today”? Performance problems are an annoyance. Unless things are really bad, you can typically use the system, but it’s slow. We human beings are an impatient lot, so the annoyance level of a system taking 5 seconds to respond instead of 1 is higher than you might expect.

There is some mystique about the performance of a system. With good reason. To really understand performance, you need to understand a hell of a lot about the 1s and 0s that are flying around at the lower level. You need an understanding of what’s happening at the hardware level to make sure there are no bottlenecks there. Sometimes it might be the operating system running out of resources or perhaps the database. It might even be the application code itself. A good performance expert will have many years of experience and an intuitive grasp of what’s going on at every level.

It usually boils down to three different types of problem. Either the tasks in the system are taking too long, or there are too many tasks going on or there is contention.

Suppose you have a bar. Suppose that each time the barman serves a customer, he has to go next door and buy a glass. Each customer interaction is going to take a long time. Adding more barmen is the wrong approach. To fix the performance problem, you need to have a shelf full of glasses that the barman can use whenever a customer places an order. You also need to make sure the shelf gets restocked.

Suppose 20 thirsty people turn up. Now, there is contention for the barman. Cutting the amount of time the barman takes to serve each customer will help, but adding more barmen would probably help more.

Suppose 14 coach loads of thirsty Irishmen turn up on the way back from a rugby match. Now you’ve got a real problem. Not only have you got too many customers to serve, and you have contention on the bar staff, the chances are that a good proportion of them are going to order Guinness (the drink that takes the longest time to serve). To add insult to injury, they’ve probably spent all their money at the match so many of them will also be paying by credit card.

In this example, you’ve got multiple examples of all 3 types of problem at once, which is typically how it goes when you are looking at a complex application. So the next time you’re on the phone to the call centre and the system’s slow, cut them some slack. And spare a thought for the poor sod in the back room who’s trying to work out why.

Related articles
Mar 30 2013

I love it when a plan comes together…

The main cast of The A-Team. Clockwise from to...

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!

Related articles
Dec 2 2012

Read the small print

Read the fine print!

Read the fine print! (Photo credit: snacktime2007)

Would you ever sign anything if you hadn’t read the small print? Would you ever click a button to indicate your agreement with something if you hadn’t read the small print? What about if there were reams and reams of small print? What if you started reading it, but after a couple of paragraphs, you couldn’t make head nor tail of it – would you still go on to sign in blood?

Pretty much every time you install a new piece of software, there will invariably be a huge agreement in unintelligible legalese. In order to go ahead and reap the benefits of whichever piece of software you are installing, you will be faced with a choice. Here’s a ton of legal gobbledegook, click here to go ahead and agree or hard cheese, you can’t have your software.

I’m no lawyer, but if you actually take the time to read some of this small print, it will typically indemnify the software publisher against pretty much anything. They won’t guarantee that the software is fit for purpose – which seems bizarre to me. They’re not so candid in their marketing. Come and buy our latest office software – it can do anything you want* (small print: we’re not guaranteeing it will do anything at all).

Typically, the small print will indemnify the publisher against any kind of defect. Having worked in software all my life, I do understand why this is in place. I doubt that there is any software in existence today that doesn’t have a bug in it somewhere, but to abandon all responsibility for the quality of your product seems outrageous.

There will also be something in there that limits the company’s liability. If there is a remedy, which is by no means guaranteed, it will usually be restricted to the purchase price of the software. Forget any consequential losses – worth bearing in mind next time you use a piece of software to produce your invoices or calculate your tax return.

Would any other vendor get away with it? You don’t get all that small print when you buy a car. How would you feel if at purchase time you get presented with a big contract with statements like; this car may not do everything you expect. We don’t offer any warranty and if, because the brakes fail, you run into something or someone expensive, the best you can expect is a refund.

How do they get away with it?

Related articles
Sep 30 2012

Updates needed

raw data snapshot

raw data snapshot (Photo credit: MelvinSchlubman)

Do you think CT scanners in hospitals pop up messages in the middle of a brain scan telling the operator that there is a software update available? When was the last time your car stopped and flashed up a message saying software update needed? What about your TV? Or your satellite receiver? Probably never.

What about your computer? It seems like I get a message several times a week telling me that something needs an update. If it’s not the operating system, it’s the office software or the virus checking software or maybe a plug-in for my browser. It drives me nuts!

I have a laptop at home and a machine at work. Between them, I probably update some piece of software every day. On one day last week, my laptop needed an update as did the office software running on it and the flash player in the browser oh, and Adobe Acrobat Reader. Not only that, but my iPhone joined in the party and decided that what I really needed was an inferior maps application, so along came iOS6.

It’s a mess. All the time you spend updating all these software components compromises your productivity. Not only that, but all this change is risky. Software vendors seem to have improved at testing their updates, but even so, you always feel like you are taking a gamble when applying all these updates. At the end of the process – will you end up with a working machine or a nice looking brick.

And why does the software update process have to be so damned invasive? OK – so Acrobat may need an update – but do you think that I really want to know about it when I’ve just opened a document? Some update mechanisms allow you to specify options such as how often to check for updates and how to apply them – which is an improvement, but why do I have to do it separately for every application on the system.

I like the update system for apps on the iPhone and iPad. No painful pop up messages when you are trying to do something, just a little number hovering over the corner of the app store. If you are curious, you can go and see what the updates are and what they do. You can choose when to apply them – like when you plug your phone in for the night to charge. All in all, a very elegant system.

When can we have it in OSX and Windows? A single central source of software updates for the entire machine. No piece of software would be allowed to apply software updates any other way. Simple, elegant and non-invasive. Perfect.

Related articles
Jun 21 2012

The mobile supercomputer

Automobile crossing rope bridge

Automobile crossing rope bridge (Photo credit: The Field Museum Library)

Maybe it’s my fading memory, but I seem to remember that winters were much colder during my school years. It could be that I spent a lot more time standing around in the snow waiting for buses, but the cold used to seep up through my shoes and into my bones. You didn’t need to look out of the window to see whether it was a cold and frosty morning. The starter motors of the reluctant cars made a characteristic whining noise in a gradually slowing rhythm as the last dying remnants of the battery was eaten away.

In the early 1980s, the ignition systems in cars were mechanical in nature. This meant they had the annoying habit of wearing out at the most inconvenient moments. Not only that, but there wasn’t much adjustment available. It didn’t matter whether it was 30 degrees and sunny or -20 degrees with inches of snow on the ground, the components in the ignition system worked (or rather didn’t) in exactly the same way.

The only tool available to the driver was a little knob called a choke which pulled out of the dashboard and controlled the strength of the fuel mixture. On a cold and frosty morning a richer mixture was required. As the engine heated up, the choke could be pushed gradually back in returning the mixture to normal.

Ford assembly line, 1913.

Ford assembly line, 1913. (Photo credit: Wikipedia)

Electronics were not the only reason cars were unreliable. The assembly lines on which they were produced had not advanced significantly since Henry Ford came up with the idea. Although many parts were pressed out of steel using a massive die, almost everything was assembled by hand which meant that fit and finish were inconsistent. Some cars were more reliable than others and there was a suspicion that quality of assembly went significantly downhill towards the end of the working week. If you were unlucky enough to have bought an unreliable car, people would refer to it as a “Friday afternoon car”. The metals used in car construction were nowhere near the quality of those used today. In addition, galvanisation had yet to take off and few car manufacturers used sufficient rust protection. Even if your pride and joy was in fine fettle, the dreaded tinworm could have nibbled its way through crucial parts of your car’s anatomy.

Construction techniques have advanced and cars have undoubtedly made massive leaps forward in terms of comfort, reliability, efficiency and safety but the basic form factor has remained the same for about a hundred years. The biggest leap forward has been in terms of the sophistication of the electronic control systems watching over the engine, brakes and suspension. It is not uncommon for a premium car to have 20 – 30 micro controllers and 100 million lines of code buried under the considerable bonnet (or hood if you’re American).

Just to put those numbers in perspective,  according to the Mythical Man Month (required reading for anyone in software) it is estimated that developers on average produce 10 lines of code per working day. I’m assuming that car manufacturers must find more productive programmers otherwise writing the software for a car would take approximately 50,000 man years. Of course not everything is written from scratch and the same code must get reused between different components and different cars. Still, it’s an incredible amount of software and not only that, the quality seems very high which is a comfort when you stamp your feet on the brake pedal in the rain.

I’m just glad I don’t have to listen to that infernal racket on a cold and frosty morning.

Related articles
May 20 2012

Beam me up Scotty!

 

Abstract icon of Enterprise NX-01 of Star Trek...

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!

Related articles