One From The Vaults: Testing

Looking for Rhino (real ones, not mocks)

Whilst I was looking for something else I found an explanation I wrote years ago to try to explain to senior management how testing had changed and become critical in the Agile environment. It’s not the easiest thing to try to get across: the business wants features that it can sell. I don’t think I did a bad job, so here it is.

Having now spent a few months with this project I’m very conscious that, at the moment, we don’t have much of a testing strategy. It looks as if we’re trying to offload all responsibility for testing onto the testing department.
This rather implies that our primary testing strategy is manual system testing.
Failed system tests are expensive – and if they impact promised delivery dates they can be a major problem. It would be better if we could have a good idea before we entered a system test whether or not it’s going to pass and that is a software quality management problem.

(Technical) testing should start in the software design. The questions the developers should be asking are;

  1. How am I going to achieve this task?
  2. How am I going to test it?

As an example, user interfaces are notoriously difficult to test, but if one of the MVC style design patterns is used it means that the view (the actual UI) can be separated from the rest of the code. This means you can write a program to test the logic behind the UI without having to try to actually click buttons programmatically.

There are any number of places within the design of software where adding a little thought to how it can be (easily or preferably automatically) tested is of significant advantage.
The more automated testing we can get in the better. If we can get to a position where a substantial portion of the code is automatically built and tested every night that would be great. It means that we, as developers, get continuous feedback about the state of the software.
We can then go into a system testing phase with a much higher level of confidence that it will pass.

This does mean however that we need to start investing in testing, which can be a difficult message to get across. If we don’t however then as the software and the functionality grows and the code-base becomes more difficult to maintain we will be taking ever increasing risks with the future of the product.

It’s a good idea to get this baked in now.

I would suggest that a feature is not finished unless the issue of how it is going to be tested is solved – and that means the automated tests and / or the manual tests written. If there’s no automated testing there needs to be an explanation of why.

The more bodges, work-arounds and spaghetti code there is, the harder it becomes to maintain and the longer it takes to develop each new feature. A product which leads the market can very quickly fall behind because every time someone tries to do something they have to try to unravel all the spaghetti, they then inevitably end up piling on more spaghetti just to make it work and making it worse for the next edit. Technical debt snowballs.

As with all things there’s a balance, I’m conscious we need to get features to market fast, but as the product matures the importance of testing will increase. Automated unit testing ensures that each building block of the project actually does what we think it should do. It’s not a silver bullet for solving all technical debt, but it’s a good starting point. Making code testable enforces certain good behaviours that will increase the longevity of the product.

I do not believe that the current development strategy is sustainable. I am therefore intending to phase in a plan that will, in time, see all new development covered by automated testing and will start to retrofit automated testing into the existing code-base. Inevitably this will slow down the speed we can get features to market, by a known and controllable overhead. Our business model is based on repeat business. If we fail to get a grip of technical debt the competition will overtake us in the mid term and it will invalidate that model.

Stop! Thief!

“That image looks awfully familiar” I found myself thinking when reading an article on vinyl record run-out groove etchings. Then it clicked, it was one of my images, reproduced in someone else’s article without my permission and with no recognition that it was my image.

Image of Vinyl Factory 29 Dec 2017

I’m not a professional photographer, it’s true I do know which end of a camera is the sharp one, but trying to make money out of photos is just more hassle than it would be worth to me. Consequently I’m quite happy for my images to be reused for non-commercial purposes provided that I’m given due credit.

What I do mind however is when my images get re-used on commercial, for profit sites without even so much as an acknowledgement. Even on commercial sites it’s really not worth me pursuing them for revenue (although I reserve the right to do so), what I mind is the fact that it’s downright rude not to credit the original artist.

There’s really no excuse for this – even if someone found the image on a different site a Google reverse image search will very quickly identify its origin. Consequently I have no hesitation in naming and shaming places where I’ve found my images used without my permission and without any recognition.

Original Article Rip Off
A Porky Prime Cut Vinyl Factory
And Twitter
A Porky Prime Cut Two Good Ears
A Porky Prime Cut jack.canalplus.fr
IP Webcam MSN / Auntie Acid
(image and factual content)
IP Webcam Auntie Acid
(image and factual content)
IP Webcam estisuperba.ro

And again (different article)

IP Webcam smalljoys.tv
Goodwood Cobra (racing) conboy.us
Goodwood Cobra (crash) conboy.us
Goodwood Cobra (crash) armeniabirding.info
Goodwood Jaguar D Type (racing) 165.227.181.117
Goodwood Jaguar D Type (rear) 165.227.181.117
Grand Rosela Hotel, adelynndesign.us

Entity Framework Double PK Overwrite Gotcha

I was writing some unit tests: largely out of completeness I wanted to test that you couldn’t insert two records with the same primary key. The code is simple enough.

    var car = db.Cars.OrderBy(g => Guid.NewGuid()).First();
    var pool1 = db.Pools.OrderBy(g => Guid.NewGuid()).First();
    var driverName1 = Guid.NewGuid().ToString().Trim('{', '}');
    var created1 = PoolAllocatedCar.Create(car, pool1, driverName1);
    db.PoolAllocatedCars.Add(created1);

    var pool2 = db.Pools.OrderBy(g => Guid.NewGuid()).First();
    var driverName2 = Guid.NewGuid().ToString().Trim('{', '}');
    var created2 = PoolAllocatedCar.Create(car, pool2, driverName2);
    db.PoolAllocatedCars.Add(created2);

    Assert.Catch<Exception>(()=> db.SaveChanges());

Car Id is the sole primary key of the PoolAllocatedCars table.

Being bit lazy I guessed it was quicker for me to run the code and find out what exception SaveChanges() it threw rather than trawl through the docs and work out what it should be.

The problem: it didn’t throw an exception. So I added some debug to find out what happened, the result is disappointing to say the least.

---===*** FAILED TO NOTICE PK CLASH ***===---

In Memory:
    Car Id [24] Pool Id [49] Driver [bda1d05c-8dae-4648-ab42-736eb8c44b71]
    Car Id [24] Pool Id [08] Driver [9dae73a0-5b8d-45bc-9d0a-f8b73141aa2c]

In Database:
    Car Id [24] Pool Id [08] Driver [9dae73a0-5b8d-45bc-9d0a-f8b73141aa2c]

It would appear that Entity Framework simply overwrote the first record with the second without giving any indication that there was ever a primary key clash.

Now I’m sure that somewhere in the documentation there’s a warning or a note about this but I haven’t found it yet…

Update: It Gets Worse

I was taken aback by the above, that it could be deemed acceptable to treat the explicit addition of a second object with the same primary key as an implicit update with no warning to the user.

I guess then I shouldn’t have been surprised that it even does this after an explicit call to SaveChanges()

The following test gives exactly the same result as the first. This is a massive gotcha.

    var car = db.Cars.OrderBy(g => Guid.NewGuid()).First();
    var pool1 = db.Pools.OrderBy(g => Guid.NewGuid()).First();
    var driverName1 = Guid.NewGuid().ToString().Trim('{', '}');
    var created1 = PoolAllocatedCar.Create(car, pool1, driverName1);
    db.PoolAllocatedCars.Add(created1);

    db.SaveChanges();

    var pool2 = db.Pools.OrderBy(g => Guid.NewGuid()).First();
    var driverName2 = Guid.NewGuid().ToString().Trim('{', '}');
    var created2 = PoolAllocatedCar.Create(car, pool2, driverName2);
    db.PoolAllocatedCars.Add(created2);

    Assert.Catch<Exception>(()=> db.SaveChanges());

The good news is that if you use a different DbContext it throws an exception :- in fact on the Add, not the SaveChanges.

I’m having trouble getting my head around this: I can’t see the logic. If you thought there was a chance that you’d want to update an object after you’d added it to the table then you should keep your own reference to it. If that’s a problem because of scope then your design is probably wrong.

The Jet Set

I really genuinely hate air travel. I will do pretty much anything I can to avoid it. I’ve taken a 16 hour train journey from Suffolk to Barcelona to avoid a 3 hour flight. It’s not that I’m afraid of flying, there’s just something about the whole experience that I find fundamentally unpleasant.

South Africa however is a bit of a trek. Personally I’m completely up for a McGregor/Boorman type epic, but there are certain logistical problems. Mainly not having anything like the spare cash that Ewan McGregor has. Or time. He does seem to have a lot of spare time.

Consequently I’m currently sat on a plane and I’ve been here a while…

There’s never anything on the entertainment system that I want to watch. I have no idea why. It could have my favourite show on there and I still wouldn’t want to watch it. I’ve gone through it all, pawed the duty free catalogue, scanned the in flight magazine and read the safety instructions twice. It’s half past midnight and I am still quite unreasonably awake. It’s at times like this when I conclude that it’s a good idea to listen to Pink Floyd’s Atom Heart Mother.

I’m almost coming to terms with “Alan’s Psychedelic Breakfast” when I suddenly become aware of something plasticky in front of me. I’m just about to “put it over my mouth and breathe normally” when my nose informs me that it’s curry. I conclude that I could in fact eat, not because I’m hungry but because I’m bored and I’m hoping that redirecting some of the blood supply from brain to stomach might help me at least doze.

To this end I order wine too, “Cabernet Sauvingon?”, I enquire. “No, but we’ve got Sauvingon Blanc”, comes the reply. “No thanks,” I interject, “Cabernet Sauvignon is a red” but it’s too late and an open mini bottle of white wine lands on my tray table. I note that is a Marlborough and decide that it’s better the devil you know.

Nevertheless my plan works and half an hour later I’m in the land of nod.

I awake to the rather uncomfortable realisation that I ordered Asian Vegetarian food on this flight. I usually do because it seems more difficult for airlines to murder curry then it does any other type of food. Unfortunately breakfasts can get interesting as I’m about to find out when I’m served bland, generic cheese, coleslaw and sort of bread that tastes like dehydrated semolina pudding.

On the bright side I conclude that breakfast service must mean that I got a good few hours sleep and that there can’t be that much time left on the clock. I don’t dare look however.

I fire up my music player and decide to give the Amaranthe album I curiously downloaded on Spotify a listen. The first track is good, but I very quickly conclude that although Euphoric Dance / Death Metal crossover might sound like an interesting and challenging concept, right here, right now it’s just very, very annoying.

Thankfully the entertainment system has some Chopin and my eyelids are starting to feel heavy again.

There’s an eerie silence when I wake and another strong smell of curry. Chopin has finished and my noise cancelling headphones are busy cancelling out the drone of 4 enormous GP7000 series jet engines.

I lift the lid on the tray in front of me: the airline chefs have surpassed themselves this time and reached a whole new level of achievement. Somehow they have managed to screw up a paneer curry.

Fortunately there are enough other dishes to make a meal. There’s even some spare cheese, just in case cheese in lightly spiced cream sauce wasn’t enough dairy for one meal.

By the time I’ve obtained a cup of tea I’m feeling brave. I’ve had two good sleeps and three bad meals. We must be nearly there, right?

3 hours to go. There’s nothing out the window but cloud. The aircraft cameras are showing nothing but cloud.

Now all we need is some… whoa! Where’s the floor gone? Is that kind of jolt within the tolerances this plane was designed for? “A bit bumpy”, why yes Captain I think we’ve all noticed that. There was a small hint in that if I hadn’t been wearing my seatbelt I’d be sitting in the overhead locker right now.
I then spend the next few moments marvelling at how, firstly, relatively minor atmospheric conditions can hurl a 500 tonne plane about like a piece of confetti and secondly what a superb piece of engineering it is that a 500 tonne plane can be hurled around like a piece of confetti without the wings falling off.
Now however the baby is screaming and the bloke next to me is pale as a ghost and clinging on to the arm rest for grim death.

I try to think of some words that might be of comfort to him, but everything I can think of either makes me sound like a smug git or contains the word “plummet”. I do however make a note to stop jokingly referring to our destination – a well known London airport – as “Splatwick”.

Still more than 2 hours to go but on the positive side, I’m starting to wonder if there’s some mileage in trying to write a blog article about why I hate flying so much…

A Tender Subject

I’d barely got into the corridor before I found myself being bundled into the wall by a rotund sales guy. “What the fuck do you think you’re doing?” he barked in my face, “If you ever pull a stunt like that again I’ll making fucking sure we put you out of business. Consider this a warning.” he stuttered a little and I could see the fear in his eyes: he was not just angry, but terrified. “And I don’t give second warnings. Understand?” he eventually added and with that marched angrily away.

I’d got maybe 15 metres further before another salesperson came up beside me and sniped, “If that’s how you’re going to behave you can forget ever partnering with us.” before he too shuffled off.

What had I done to deserve such attention? Insulted their mothers? Murdered a puppy? No, just give a sales presentation.

One of the way the UK government keeps track of technology is through seminars, they take various forms but this was essentially a day-long event where vendors of a particular type of technology were invited to present their products to a bunch of interested parties within government.

Somehow – despite being a tiny little firm – we’d managed to blag our way onto the list. I’d been to these events before, as the “tech guy” that answers the difficult questions so I knew the format. What I hadn’t done before was actually sit through a whole day of them.

They were dismal. The scripts were poorly thought out, badly structured, omitted important details and contained much that was irrelevant. The presenters were worse. Monotonous at best, incoherent and rambling at worst. By the second or third presentation I was genuinely ashamed that this is supposedly the best of what my industry can offer.

By the second session after lunch half the audience were asleep and I was reasonably convinced that the other half were dead.

When we eventually took to the stage my opening words after introducing myself were “I’m sure you’ll be delighted to hear that this is the only Powerpoint slide I’m going to use.” I then talked for a few minutes about who we are and what the product was whilst my colleague set up a fully working system. We put it up on the projector, handed our various devices to the audience and spent the rest of our time role playing live scenarios that demonstrated the product features.

It was a bold move and quite a risk, there were some very senior civil servants in the room who could have taken umbrage, but they didn’t, they did the exact opposite. At the insistence of one of them our slot was extended to allow for an additional 5 minutes of questions. My colleague and I both ran out of business cards in seconds and took to writing our details on the backs of other peoples. From a sales point of view it could not have gone better for us.

That’s all I’d done. I’d hadn’t bad-mouthed the competition, said anything that was untrue or in any way behaved unprofessionally. We turned up, we told jokes and tried to be as engaging as we could whilst demonstrating a live system that could be set up in less than 5 minutes.

That is the kind of behaviour that the competitors needed to stop. For 30 years they’ve been telling government that software systems are big, complex and expensive. That they take years to develop, months to install and configure and that they require huge, expensive racks of equipment.

Then two guys turn up with a laptop and a bag of kit and prove that none of this is true.

The issue is more complex than one of straight deception, though. These organisations were formed at a time when these things were all true. The organisations themselves have grown to provide a heavyweight framework. They have little momentum and colossal inertia.

They also have huge problems with legacy code-bases. The requirements of government tend to evolve slowly, hence re-writes are rare. Instead old code lumbers on and on and velocity nosedives as technical debt increases [more on that in a minute] and new development techniques, tools, frameworks and languages accelerate the pace that can be achieved within the industry in general.

These factors have reciprocated a framework within government that has grown to expect and indeed facilitate it. The tendering process results in excessively detailed documents that emphasise the minutia and neglect the actual business requirement for the system. These are often produced by committees and are stitched together from requirements drawn from multiple sources – or in other words they’re actually just wish-lists and can at times can be incoherent.

This is a thoroughly unhealthy relationship, it’s not just wasteful, it’s actively counterproductive. It stifles technical innovation and guarantees mediocrity.

More than that though it damages the engineering quality of the products as developers rush to strap on extra features and to modify existing ones in order to meet the letter of the requirement where in reality the product was designed to solve the overall business need and does so perfectly adequately.

This is often a panic scenario too. In order to gain a higher score on the tender a business will commit to what is it at the absolute limit of what it can achieve – often a little more than. The result is the in order to meet the delivery, development have to cut every corner possible. Inevitably this piles on the technical debt.

As the development team crashes from tender to tender its velocity plummets, the business throws more developers at the problem and you end up where we are today. The products are bloated, resource hungry, hideous to configure, often still include archaic technologies that (now) require special environments and are generally impossible to demonstrate anywhere but a dedicated, static suite specifically for the purpose.

That is why 2 people turning up to a sales seminar with a laptop and a bunch of hand-held devices and doing a fully interactive live demonstration caused such a furore. Yes I do believe that everyone else there on that day was at least one of: incompetent, phoning it in or just plain burnt out. None of them however could have done a live demonstration even if they’d wanted to.
To the competitors watching it must have seemed like we’d taken the bar for a sales presentation, which was set barely higher than the crash-mat, and smashed it through the roof. There was no way they could compete.

The reality however is that we weren’t a real threat to them. If we wanted to win tenders then we had to tick boxes. We could undercut them only a handful of times before the same thing happened to us as happened to them 30 years ago. Thankfully we recognised that and stopped responding to additional tenders.

I have to admit that I don’t know what the answer is. As a business or an individual one can make purchasing decisions however we like. If we see something that doesn’t meet what we thought our requirements were, but if we thought about the problem in a different way is actually a far better solution, we can buy that and change the way we work.

Government is different, a democracy must always be accountable to the people. The government must be able to justify why it chose supplier X over supplier Y. A qualitative response is always going to be open to challenges. It is far more robust from a point of view of the accountability of government to take a quantitative approach: supplier X was able to meet more of the requirements than supplier Y. It is also more legally robust, many of the suppliers are large companies that are not afraid of litigation if they believe it might give them a competitive advantage.

One could perhaps say that this adds weight to the argument that the government is trying to do too much and that many of these key areas should be privatised, where a more effective purchasing strategy could be implemented. This however has its own problems: ultimately it’s still public money and all this is doing is to move the point of accountability higher up. The same end could be achieved by just increasing the threshold at which a tendering process is required.
I’m also not particularly keen to live in a country that has a private Police Force and I rather suspect I’m not alone.

The counter-argument is that all such systems should be developed in-house by the government itself. In an ideal world this would be the answer. Unfortunately the world isn’t ideal and the list of reasons why this is a terrible idea is really rather long.

However we spin the model and try to look at it a different way, it’s difficult to get away from the idea of a tendering system that’s essentially scored quantitatively. There have been schemes to try to improve the situation such as to get people from the software industry in ahead of the tenders being written, however their influence has to be carefully managed in case of any allegations of impropriety and they are inevitably associated with the very organisations that will be responding to the tender. Thus this is has not proved and effective means for improving the situation.

I rather dislike finishing an article without at least suggesting something that I think might improve the situation, but I have to admit that I’m struggling with this one.

—=== END ===—


I’ve had a number of comments since writing this article. I can split them largely into 3 categories.

The saddest is the number if people who’ve also reported being directly threatened by larger firms within the industry.

I hadn’t realised how much technical jargon I’d used. Basically “velocity” is the speed at which you can make changes to a product and “technical debt” is what happens when you keep making changes without the proper procedures:
eventually you end up with a big bird’s nest and it gets harder and harder to make changes and it all gets more and more out of control.

A few people within the industry have commented that I’ve made some generalisations and simplifications. This is true, it’s a trade-off between writing a fastidiously accurate article and writing one that makes the point sufficiently well but is engaging enough to appeal to a wider audience.


Tom Fosdick is a Software Architect specialising in Control Room systems for the Emergency Services. His current engagement is with Motorola Solutions, although this article refers to an engagement with another organisation.

Tanya And Tom Do Racing

I have been known to point a camera at a thing – quite often that thing is a racing car. I do it as my own personal challenge but other people seem to like the results, which is one of the reasons behind the TanyaAndTomDoRacing Instagram account.

I do find however that I get asked two questions quite a lot and as Instagram isn’t really the place for a FAQ…

You Must Have Some Really Good Kit?

The direct answer is no, I don’t. In fact this is a pet peeve of mine, not just in photography but in many hobbies.

If you have a good eye, enough knowledge, skill and technique then any entry level major brand Digital SLR camera and many bridge cameras are perfectly capable of taking very good photos – in many cases professional quality photos.

The key about a Digital SLR camera is that it puts control of the optics and the sensor into the hands of the operator, allowing the photographer to make artistic decisions about how the light is captured.

This is one of my favourite (but not technically best) photos, taken at Goodwood Revival in 2015.

It was taken with a Nikon D3000 and a Nikkor AF-S 55-300 F4.5-5.6 D G VR DX lens: entry level kit. What makes the photo is the framing, the choice of subject, the angle to get the reflected sun, the 1/25 shutter speed and a big chunk of luck with the panning.

You can’t compensate for deficiencies in any of those things by throwing more money at it.

Yes, I would have liked a higher resolution sensor and in an ideal world I would probably have used a lower ISO value and larger aperture but I could easily pay 10 times as much for kit to get a photo that is only marginally better.

Digital SLRs are not supposed to be smart, they’re not about image processing and fancy modes to try to make something out of nothing, they’re all about controlling how the light falls on the sensor. There’s only so much that clever electronics and software can help and the best of that is often found not in SLRs – where it might actually degrade the photographic quality – but in compact cameras.

Here’s a case in point:

I like this photo, but it’s not one of my favourites. Taking the standard sharp foreground, blurred background photo is like shooting fish with a Digital SLR.

This photo wasn’t taken with a Digital SLR though, it was taken with a Sony DSC-HX50, a £200 compact camera.

It’s possibly my favourite ever camera, simply because of the amount of power it puts in a genuinely pocket sized piece of equipment.

It does have modes to put optical control in the hands of the user (as seen above), but what you can do is limited – mostly by the physical size of the device. To compensate for the fact that there simply isn’t room for better optics it’s stuffed full of electronics and software.

This shot, for instance, was taken hand-held at a beach cafe somewhere in Indonesia using all the electronic aides available (and needing them).

In an ideal world I would have had a Digital SLR mounted on a tripod and I could have taken a slightly better picture. In an ideal world the person in the picture would be a model who wouldn’t have moved.

The problem is that the person in the picture isn’t a model, she was one of the tour group and I couldn’t really ask her to hang about whilst I set a tripod up or stay still whilst I took the photo. The moment was there, I was able to capture it specifically because I had a compact camera with a night mode that I could select in a second.

The bottom line is this: you can take really good pictures with a sub-£100 camera. The problem is that the capabilities of that camera will be limited, which will limit where, when and the type of picture you can take.

If you spend a bit more, around the £200-£300 bracket you can get cameras that are far more capable and put a good amount of control in the hands of the photographer.

Above that you hit the wall of diminishing returns pretty hard. Between £100 and £200 there’s a huge jump in capability and quality. Between £200 and £300 less so. When you get above that then you can find yourself paying an awful lot of money for very little improvement and you have to ask yourself whether it’s really worth the money.

If you’re thinking of turning professional or if you spend every waking, non-working moment dreaming about photography then fine, maybe it is. For most of us it’s not.

But You Should Sell Your Photos / Turn Professional!

I’m flattered, sincerely and genuinely that some people think my photos are good enough to make money out of, but the reality is that they aren’t.

OK, some of them are and course if people want to pay me to use / print them then we can talk about that… the point is that it’s not worth me actively pursuing trying to sell them.

As I said above, taking the standard “sharp foreground, blurred background” racing car photo is shooting fish in a barrel with a Digital SLR – anyone with any understanding of the principles of photography can do it.

It used to be difficult because with (wet) film you had no idea how good the photo was until you developed it. You can’t do that at the track-side. That means you needed a lot of experience to know exactly what settings and techniques were required because you were shooting blind.

With a Digital SLR you can press the shutter and have the image on a HD tablet within a couple of seconds. You can closely analyse the picture, work out what needs changing and then go again with an improved set up within a few seconds.

At any Formula 1 Grand Prix there must be at least a thousand people doing pretty much that and a good portion of them will be producing shots as good as mine or better. There are only a handful of places you could sell the pictures to and they’re all looking for something that is not just technically good, but has something extra that makes it stand out.

Perhaps something like the first picture in this article, but with a little more sharpness on the helmet and without the smear in the bottom left caused by the head of some bloke who wandered into shot.

I have thousands of photos in and around race tracks and other motorsport events. I have only a handful of photos that I genuinely believe anyone would pay money for.

If you want some idea of the differences then look at the Instagram streams of the professionals:

James Moy @f1photographer
Lollipop Magazine
(Joshua Paul)
@lollipopmagazine (my favourite)
Peter J Fox @peterjfoxy
Sutton Images @suttonimages
Darren Heath @darrenheathphotographer
McLaren @mclaren
Ferrari @scuderiaferrari
Williams @williamsmartiniracing
Red Bull @redbullracing
Toro Rosso @officialtororosso
Force India @forceindiaf1
Renault @renaultsportf1
Sauber @sauberf1team
Haas @haasf1team
Mercedes @mercedesamgf1
Prema @prema_team
Racing Engineering @racingengineering
Russian Time @teamrussiantime
ART @artgp_official
DAMS @damsracing
Campos @camposracing
Trident @trident_team
Rapax @rapaxteam
Arden @ardenmotorsport

 

 

My Favourite Little Friend

Lily Asleep in the garden

[originally written February 9th 2017]

You know before you step out the door. You’re going to the rescue centre, there will be something small and cute there and you will fall in love. You might tell yourself that you’re just going to look, but you’re not. You’re going there because you want to fall in love, you want to share your life.

You also know that one day it will end. The dog that jumps up to greet you after a hard day’s work that somehow makes it all better. The cat that sits and curls up on your lap and just purrs gently when everything seems lost. One day they will die. You know this, but when you’re stood in the rescue centre trying to work out a way of leaving without promising to take all of the animals you don’t accept it. You’re choosing a new life companion and in your head that companionship will last forever.

You know however as time passes that the day it must end is coming closer. When my cat Lily was about 14 I saw her laying motionless on my lawn. I found myself thinking that if she’d passed away I wouldn’t be so upset. 14 is a good age, she’d led a good life and right up until that day she’d been scampering round like a kitten. Yes, this was a good way to die, to find a sunny spot on the lawn on that warm spring day, to curl up and drift off into the big sleep just as she’d drifted off into any other sleep.

I crept closer to see if I could spot any sign of life. As my shadow fell over her I heard the faintest “mip” and she rearranged her paws. She was fine, just far more deeply asleep than usual.

I smiled and carried on walking, but that image stayed in my mind. If that’s how it happened, if one day I just found her curled up having just gone to sleep never to wake up, that would be OK.

Barring a miracle, that is not how it’s going to happen.

Looking back she wasn’t quite right this summer. We used to lose her in the summer, she  rarely came into the house. She’d be out prowling or sleeping either in the garden or in the nearby fields. She’d get sun-bleached, by late August she’d not be a black and white cat, more of a sort of brown stripy cat, not that we really had a cat you understand – she was nature’s child, wild and free.

This summer she spent a lot more time with us. We just put it down to old age and maybe not being as sprightly as she once was. As Autumn became winter however we noticed that she was losing weight fast. We tried a few different foods but none of them seemed to make a difference so we took her to the vet.

Initially all seemed fairly bright, there can be any number of reasons for older cats losing weight and many of them are treatable. As time progressed however there were more test results and we noticed more symptoms and the field of diagnosis narrowed. Sadly it was the benign things that were being eliminated. We’re now in a world where all probability points to her being terminally ill. We’re still not quite sure what the root cause is, but the weight of evidence points in that direction.

I hope that she isn’t in too much pain. Right now she doesn’t seem like she’s in too much pain so I still have that dream, that I walk out into the garden on a warm spring day to find her curled up in the sun, having shuffled off this mortal coil in the gentlest of sun and lightest of breeze.

The reality however is far more brutal. At some point she will be in pain. At some point the pain will be too much. At some point it will be better for my Lily, my dearest companion of the past 16 years if she were no longer here.

And I’m sat here now with tears streaming down my face as she walks all over the keyboard and rubs her cheek against mine.

At some point I will have to kill her.

I am terrified.


I wrote this post a few months ago and I didn’t publish it because at that time I thought it was – well – just too sad. It felt like I was writing her obituary long before she had died.

A few days ago Lily came to see me whilst I was asleep, she curled up and went to sleep next to me. For the first time I can remember when I woke she was still there. I dearly hoped that’s what I’d be able to tell you, that she’d died whilst peacefully asleep next to me. Sadly, as I predicted, that’s not how it was.

She had a brief spell where she seemed to recover a bit, but it soon became clear that it was temporary. She continued to become evermore frail. Over the past 2 weeks however it started to become noticeable that she wasn’t moving or even standing in the same way she used to. Her life seemed to consist of long periods of sitting on her favourite rug staring into space, going to the food bowl, going to the litter tray and coming to us for affection and comfort.

Reluctantly we concluded that by continuing to feed and care for her we were extending her life beyond its natural limit. As it was now clear that she was in pain we decided that to continue to care for her without there being a dramatic medical intervention was unethical.

We visited the vets last Friday and we were not able to come up with any medical solution that would have any reasonable prospect of giving her any further valuable life. We therefore took the decision to end her life in the most peaceful way possible.

We buried her in the garden on Saturday, in one of her favourite spots – almost exactly where the above photo was taken. Currently the spot is marked by a white lily plant. We say hello to her every time we go to work. She’s still with us, still part of our story, still part of who we are.

Rest in peace Lily, 17/04/2001 – 21/04/2017

[original artwork by Emma Green]

Never Work With Scientists or Engineers

Forget never working with children or animals. Never work with Scientists or Engineers.

Picture the scene, dear reader; the air is being turned blue with the kind of language usually reserved for the rugby scrum. Things are being thrown.

A calming voice comes from a distant room enquiring what the problem might be. I respond using “language” that mounting the picture in the frame has not gone as well as I had anticipated, it’s not quite central. I may have used the word “disaster”. I can’t recall what the other words were but I seem to recall them being quite short and decidedly pointy.

“But you can fix it,” comes that calming voice again, “you can fix anything.” I take a deep breath, think for a bit and conclude that yes, I can fix it.

There then follows a few minutes of calm and concentration before once again the demons are unleashed, the air turns blue again and more everyday household objects find themselves travelling at unnatural speeds towards various hard surfaces.

“Problems?” enquires the calming voice.

“Yes, ” I reply. You will understand of course that my actual reply was somewhat longer than this but there are international treatise preventing me from disclosing the full transcript. I then continue to explain the cause of my frustration, “have you ever tried to cut 1/4 of a millimetre off the side of a piece of A4 card? It’s impossible!”

It was at that point it hit me, I had a steel ruler on top of a piece of card, both clamped to a cutting mat and I was using a razor blade to trim off a tiny amount to correct an error that only I was ever going to know was there. It was pointless, I should have just put the card in the frame and forgotten about the tiny mistake.

That 1/4mm level of passion, that level of attention to detail is entirely the sort of thing that’s required if you’re an engineer that is, say, responsible for ensuring that 999 (911 ,112)  calls get dealt with correctly (which I am). When mounting a picture however it’s more like an anti-skill, a trait that does more harm than good.

On Suddenly Discovering I’m a Motorolan

Something happened yesterday that rather took me by surprise. It wasn’t the Mercedes that drove into the back of an Audi about 100 metres in front of me, you expect that on the M25. It was something entirely different.

My industry – I mean the supply of software to the emergency services – is dominated by major companies. There are however some smaller firms in there and I’ve spent most of my career working for them, being the underdog but also being the guy at the back of the room who’s in charge of a twin outboard rib not a cargo ship.

We’ve been able to be far more dynamic, responsive, far more agile because we have a smaller user-base, a smaller and generally newer code-base and virtually no red tape. We don’t have the power of the big players, but we can put pressure on them and win business by responding and even leading in ways they can’t.

In December however we were bought by Motorola.

It wasn’t until yesterday that it really hit me though. I was in a suppliers’ forum meeting with lots of the other firms and I found myself evading a question that I’d usually answer enthusiastically. The implications for my team hadn’t changed, I had however suddenly become aware that I was wearing a Motorola ID badge and that – regardless of any caveats I may add – if I open my mouth it’s not Cyfas speaking, it’s Motorola speaking. I wasn’t quite ready for that.

I’ll get used to it in no time of course, but right now I’m still just feeling my way into what is a surprisingly different role in this market.

Hello Moto!

I’m excited: it was announced today that Motorola Solutions has bought the ICCS business from Cyfas Ltd. For a little over a year I and a small team of very dedicated, talented people have been beavering away on a little industrial estate in Bedfordshire trying to produce something new, something genuinely groundbreaking in the world of the Emergency Service Control Room.

The significance of the project has been widely recognised within the industry and over the past few weeks we’ve been in negotiation with Motorola Solutions about becoming part of the Motorola family. Yesterday the transaction was completed.

This opens up a new world of possibilities for us, it allows us to go places and do things that we never could have achieved as a small company working on its own.

I’m hugely proud of what we’ve achieved at Cyfas and I’m genuinely excited about being able to take it to the next stage with investment from Motorola. 


All of which means absolutely nothing if you’re not familiar with the world of the emergency services control room, so here’s a quick précis.

There are two critical computer systems in any emergency service control room – the Computer Aided Dispatch (CAD, sometimes called “Command and Control”) and the Integration Communications Control System (ICCS).

Computer Aided Dispatch

The CAD system is in charge of incident management. When an emergency call is taken an incident is created and logged on the CAD system. Resources: ambulances, fire trucks, police cars etc. are then assigned to the incident, they deal with it and the incident is eventually closed. Today’s CAD systems have gone far beyond being simple log entry and recording systems, they have grown to include algorithms for suggesting the best resources to use based on where they are, where the crews are, what the type of incident is, what equipment is on the vehicle and what skills are available. They can prioritise incidents and even batch them up for crews to tackle one after the other. They are also able to communicate directly with stations, vehicles and people so that control room operators can quickly dispatch appropriate resources to deal with the incident and don’t have to keep checking up on them.
When I was at Seed Software I led the development of a CAD system, Brigid Command and Control (also here).

Integrated Communications Control System

The ICCS can be described very simply: it’s the system that manages the audio in the control room.
When an emergency call is made it first goes to the national operator – in the UK that’s BT. When you say which service you require the call then comes through to a local operator in one of the services’ control rooms.
Control room operators however don’t just sit around waiting for emergency calls, they can actually be dealing with all sorts of non-emergency matters. So they need to be told that there’s an incoming emergency that takes priority. These days that’s not done with a bat-phone, how the operator talks to the world is done via a computer system – the ICCS.
The operator can then – with a single click – answer the emergency call. That however is just the beginning – for instance the call may need to be transferred to another operator with specialist knowledge. An alternative might be to put the call in a conference so that both operators are on the call, or simply to have another operator listen in one the call. All of this needs to be carefully managed to ensure that every operator knows that it’s an emergency call and that there’s no possibility of the call being dropped.
The ICCS does a lot more than just operate telephone services however, it also operates the radio systems so that control room operators can speak to crews who are out and about. Sometimes this means operating several different types of radio and routing calls between the two so that people using one type of radio system can talk to people using a completely different one.
A lot of ICCS systems also have additional functions such as CCTV viewing and being able to operate building security systems.

Cyfas

In late 2014 I’d had my head in Computer Aided Dispatch for 6 years and I was starting to think that perhaps my time at Seed had run its natural course and that it was time to move on. About that time Hugh Evans (aka Moose) – then the manager of the then national DAB station Team Rock Radio – happened to mention on air that “Google had put a broadcast quality codec in the Chrome browser”. In his case that led to the famous edition of the breakfast show that they broadcast travelling across London using the free WiFi on the tube – an event that I recorded as important for home workers.
Other wheels were turning in my mind however – if they could use Chrome to broadcast a live radio show then audio handling within browsers must have reached the kind of standard where it would be possible to build at least a basic ICCS in a web browser. I wondered how difficult it would be to produce an open source web based ICCS but after playing around with a few designs I came to the conclusion that it wasn’t the sort of thing that should be attempted as a spare time project.

I was not however the only one thinking along these lines. The Emergency Services systems world is perhaps surprisingly small and when I put the word out that I was thinking of leaving Seed one of the approaches I got was from Cyfas, who had just started to implement a design for a web-based ICCS.

This might seem like a crazy idea but it really isn’t. The days when the operator would have physical telephone lines and radios at the control room desk are passing quickly. Since the 1980s telephone trunks have used digital technology, cordless phones and mobile / cell phones have been digital since the 1990s so it will be no surprise that emergency calls are in fact delivered into the control room using digital technology and not actual wires.
Radios are going the same way, increasingly the services are provided by large infrastructure systems such as Airwave TETRA or its replacement ESN.

Thus the ICCS is changing from a system that directly processed analogue audio and tied together physical pieces of hardware into a digital controller that simply communicates with other computer systems to provide the voice services. There is no longer any need for this system to sit on the operator’s desk – there is only a need for it to have an interface on the operator’s desk.
What better way to do this than via a web browser? It opens up a whole new world of possibilities.

At its simplest, consider what happens if there’s a hardware fault with the system on the operator’s desk. With a traditional ICCS this has to be decommissioned whilst the ICT department replace it and wire in the new system. Often the configuration of the ICCS is so complex that the ICCS supplier has to come in to commission the replacement terminal.
If it’s just a web browser then any reasonable quality PC can be used – even a laptop. An ICCS terminal can be replaced in seconds, not days.

Consider also how you upgrade an ICCS – with a traditional ICCS the supplier needs to come in and individually upgrade each terminal. With a web based ICCS a new deployment can be loaded onto the web server and the entire control room switched over to the new version in the press of a button.

Another advantage is the fact that new terminals can be added at a stroke. In “spate” conditions where the control room is overloaded with calls an extra operator position can be added at a moment’s notice. What’s more it’s possible that operators from another control room can easily start taking overflow calls. This is important because spate conditions are usually localised and there may be spare capacity to take calls elsewhere in the country.

This also has implications in the case of a building emergency. It’s not unknown for control rooms themselves to suffer emergencies and have to be evacuated. The ability to simply transfer the control room function at the flick of a switch to elsewhere is highly desirable. On top of this there is the ability to turn any office – in fact any space that sufficient network bandwidth, into a control room in minutes. Even a Portacabin or the back of a truck.

There is a further advantage in the using web technology aligns nicely with the current direction of the software development industry. The web has become critical to the functioning of our society. Consequently there has been an awful lot of time and effort invested in making sure that web sites don’t go down. That same technology can be brought to the world of the ICCS to ensure that service is never lost.

A logical extension to this is the concept of ICCS as a service, where the service itself doesn’t actually manage any hardware themselves, instead they simply pay a subscription to a cloud provider (such as Motorola) to provide them with the service.
Whilst this might initially seem quite frightening there are in fact a number of possible configurations of this which can reduce the risks associated with potential losses of network service.

With the backing of Motorola we’ll be able to provide all of the above, something that it’s unlikely Cyfas would have been able to do on their own. I’m genuinely excited about it, about the journey in the future and about where it could take us.