IT Stereotypes


It’s rare that I go on a rant but…

I was pretty disappointed by what I saw on the ABC (Australia) program The Drum this afternoon.

Former military officer and transgender Cate McGregor was discussing the defence white paper released today and in particular the recruitment of people to fill positions related to cyber security.

When detailing the type of person that they would need to recruit she smirked describing them as:

“Living like a vampire in their Mum’s basement”

“Not on the Meyer-Briggs scale of the natural extroverted born leader, type A personality that military organisations have tried to recruit”

She went on to describe them as “socially isolated”, “eccentric”, “play with computers all day”, “keep funny hours” and “probably wouldn’t pass a military PT test”

As someone who has been on the receiving end of a fair bit of prejudge herself, I’m extremely disappointed that she would fall back to using such hackneyed stereotypes of people in the IT industry.

It should be noted that this was taking place in a discussion about the “difficulty finding the right people to do this type of work”. Good luck recruiting them now. Not only is this demeaning to future recruits, but to serving military personnel working on IT systems (of which I once was).

I really expected better from a former senior officer and someone who has been on the receiving end of a lot of prejudice herself.

The portrayal of these IT stereotypes needs to stop if it is ever going to solve its current diversity issues and make it an attractive career for all. This applies way beyond the military.

App User Guides

The domains for a couple of my old iOS apps are up for renewal and I’ve decided to let them lapse and put there resources here including the user guides if anyone wants or needs them.

Photo Trail

photo-trailThis is an app to allow you to record a trail of GPS points on your phone and use them to geo-tag your photos on Flickr. It’s less relevant now as lots of cameras have a built-in GPS.

You can get it on the app store here and the user guide is here.


Local Tube

This aplocal-tubep is useful to find the your closest London Underground, DLR or Overground station and show its current status. Its most interesting feature (over other tube apps) is that you can set a reminder to automatically get the tube status when you arrive or leave a certain location. For example when you leave home or the office it will send you a notification of any service disruptions. It’s on the app store here and the user guide is here.


More Cohesive iOS code using an Observer

The Problem

When writing an iOS app it’s pretty easy to end up with some rather large view controllers that do a lot of stuff. There are lots of iOS tutorials, templates and code samples out there that demonstrate a particular piece of functionality or API and they tend to put all the code in the one controller class.

That’s cool for a sample or a starting point but in the real world as you add functionality to your app you can end up with an enormous class that does everything except make you a cup of tea in the morning and implements 57 delegates. In short you end up with controllers that have low cohesion.

On top of this the whole delegate idea doesn’t make it that easy to reuse code between controllers. It’s pretty common for two views to display the same data in the same or slightly different ways. So you either live with some duplication in your code or try moving it to a common class, which can be messy.

While this certainly doesn’t apply to all kinds of apps the ones that I’ve written have a certain style. Usually data is being provided from and external source such as a web site, web service, ad server or push notification…etc. and / or internally from the phone such as core data, location services, user defaults, phone settings and the address book. This data is then displayed in the app in various views.

Enter the Observer

The best way I’ve found to get around these problems is to introduce a pattern called the Observer (I’ve also heard it called document/view in the Microsoft world). While patterns can be abused this is one that I’ve used extensively in the past and can be quite useful.

Rather than going into the detail of the pattern I’d rather talk about how to apply it, if you need some more information check out

So now how do we apply the Observer to our iOS app?

So I’ve mentioned that a lot of apps obtain their data from a number of internal and external sources in pattern speak this is the Subject and then as it’s data changes it would notify the views that need to be updated these are the Observers in the pattern.

So we could go ahead and create Subject classes for each data type and hook them up with an Observer delegate that would get called back when the data changes. While that is an improvement in itself but there is a better way.

Add Some Messaging

The Observer patterns major power is being able to handle multiple Observers for a single Subject and while we could write code to allow registering of multiple delegates and then call them all back iOS provides a mechanism for registering and notifying multiple objects at once namely using the Notification Center.

So what does an app look like when following this pattern?

So for each of the data sources regardless of where it comes from we have a Subject class which holds the current data values to be displayed. When a view is displayed it simply displays the values for the subjects that it cares about. The view should also register for notifications for when the Subject data changes so it can update itself.

But what does this notification?

In the GoF pattern the subject updates itself, but I’ve split this functionality out so that the Subject only holds the data we want and it has an associated Updater (for want of a better name), which is responsible for updating the subject with fresh data.

While the Subject and Observer classes for different data sources are very similar the Updater may not be, for example one Updater may call a web service to get sports scores externally and be triggered manually while another may use the location services to get the phones current location and happen automatically.

One note about Updaters, they may take a long time to complete getting a large amount of data from an external source over a slow connection. So typically I don’t do this update on the main thread but create an NSOperation to do this operation and put it on a queue (I may post more about this at some point). This ensures that the UI of you app remains smooth while doing updates and also allows you to handle multiple update requests for the same data

Wiring it all up

While it can depend on the type of app being developed I typically create the Subject and Updater classes when the app is started. Then as views are displayed they will get data from the Subject and display it and register for any updates they need. When the views are no longer displayed all they need to do is remember to unregister.

For example, if you have an app that gets the phone’s location from location services and weather forecasts using a web service from a weather bureau the structure would look like.

In this example there is one view (observer) that displays the location and one that displays the weather and one that displays both. As the location is updated the LocationUpdater class updates the data in the LocationSubject and send notifications via the notification center to the views that need updating. Similarly for the weather but the WeatherUpdater would get data from the external web service (in the background using NSOperation).


Hopefully it is reasonably obvious that the code using this style would be more cohesive as each of the class types have clear responsibilities

  • Subject: holds the data that we wish to display in the app
  • Observer: there can be multiple of these and they display the data (typically view controllers in IOS)
  • Updater: fetches data and updates the subject with new values and notifies the Observers that have registered for updates.

Naturally the view controllers (Observers) should be much smaller now and only do what they should i.e. display data from the subject(s) and then do an update when notified.

Finally as the update of data doesn’t take place on the main thread and the views get updated via notifications the UI should be very smooth when updating data and scrolling unlike some clunky apps out there (I’m looking at you Facebook!). It will even handle refreshing from one view and then switching to another.

Location Services Settings Not Deleted With App

I was working away on my iOS app today and I noticed a bug that only appeared to happen on my phone (the simulator was fine). What was happening was that when a MKMapView stopped tracking the user’s location the GPS was staying on. In fact I had to uninstall the app for it to switch off.

Now I was pretty sure that this had been working in the past but I’d just upgraded to iOS 5.1 so perhaps this was a bug? I quickly slapped together a test app with a map view that toggled tracking a user and the GPS switched off and on when expected.

My next idea was to start commented out big chunks of my apps code to see if this fixed things. It didn’t and I had got to the point where there was little different code left. Still the GPS stayed on…

As this problem only occurred on the phone I started to think that the phone was keeping some location services state around so I tried deleting and reinstalling the app, restarting the phone and various combinations of this and it still didn’t work. To further test my theory that the phone was keeping some location services state I renamed my app (bundle name to be precise) and voilà! it started working.

Now I wasn’t keen to have to rename my app to fix this problem so I did a little searching and found that you can reset all location services data from your phone via:

General -> Reset -> Reset Location Warnings

This fixed the problem, my app’s location services state must’ve got corrupted somehow (I still haven’t worked out how) and deleting/reinstalling the app wasn’t clearing it.

Of course this wipes the location settings for ALL apps so you’ll get a prompt to use location services the next time you open other apps, but it beats re-naming the app.

Fixing AppCode after Xcode Upgrade

Like a lot of people I’ve just updated my iPhone to run iOS 5.1 but it had knock on effect.

Firstly I could no longer run apps on my phone from Xcode without doing an upgrade to version 4.3.1, (fair enough the OS had changed).

However as Xcode is now distributed using the Apple App Store it’s location has changed so when opening AppCode I get an error that Xcode cannot be found.

I tried a few things like adding the VM options in the Info.plist file suggested and running xcode-select with a few different values such as /Applications, /Applications/…no joy.

Search the forums on the JetBrains web-site I found a post related to an earlier Xcode release and the magic command you need to run is:

xcode-select -switch /Applications/

I’m now up and running again, I also had to change the iOS simulator to use when running the app, but this setting is pretty obvious.

Region Monitoring in iOS

(or how turning off Wi-Fi broke my app)

I’m currently in the process of writing an app for iOS that uses the new(ish) region monitoring API introduced in iOS 4.

Initially I wrote a small ‘spike’ app to test the API and ensure that it would do what I wanted and to check how reliable it was I was pleasantly surprised. After I was convinced that it could do what I needed, I started to test its accuracy and how battery life was affected. Here are a few things I found:

Don’t rely on using the simulator when it comes to location and map kit testing there are a few bugs that only appear in the simulator such as, maps not tracking correctly, random location failures and the location icon appearing in the status bar even though the GPS is not running. Going for a walk or getting on a bus is the best way to test.

When monitoring regions the GPS is not switched on it only relies on cell tower and Wi-Fi information to get your location. This is despite the location arrow being displayed in the status bar. I tested this by running the energy diagnostic instrument in Xcode to see when the GPS was enabled in my app and it never was.

This was further confirmed when I was testing my app and suddenly I stopped getting region updates altogether. What had happened was that I had turned off Wi-Fi on my phone which meant that region monitoring fell back to mobile cell towers and because I had never moved outside of a cell area no update ever occurred.

Further testing of location accuracy (using startMonitoringSignificantLocationChanges in CLLocationManager) I found that the accuracy of your location via a cell tower could be up to 1.2 km out which is quite poor.

So my conclusion is that monitoring regions in iOS is not a drain on the device’s battery as the GPS is not used however with Wi-Fi disabled the accuracy of detecting the entering and exiting of regions will be quite poor as it only relies on cell tower data.

Distributed Teams – It’s a Balancing Act

For the past almost 2 years I’ve been working on a distributed development team with members located in both London and Delhi. We have the typical communication, time zone and cultural challenges that all distributed teams face but I’d like to discuss something I’ve noticed about our team which its structure.

The following is a very simplified flow of how a piece of work (a story if you like) moves through the roles in the team.

Typically a business analyst (BA) will talk to the business and gather requirements and write a story. This story is then coded by a developer who when done passes it to a quality assurance person (QA) for testing.

There is nothing special here and naturally there are other roles on the team such as project managers, operations people, DBAs…etc. but in order to keep this discussion simple I’m choosing to focus only on the BA, developer and QA roles.

If you look at these roles across the team as a whole the balance seems about right. We have the right numbers of people in each role and there is a good mix of youth, experience, business and technical knowledge.

However when each region is taken in isolation this is not the case and this can cause problems.

Role Imbalance
The first imbalance we see is the number of people filling each role in each region. This is most evident in the business analyst role as most BAs are located in London.

The reason for this is that the project’s customers are located in London so it made sense to have the majority of BAs close to them. However this means is that the developers in India have less direct access to the business analysts.

As a developer I find that regardless of how well the stories have been written nothing is better than discussing a story directly with the BA. The developers in the team in India have a distinct disadvantage, sure they can contact the BA by phone or instant messenger but they have language and time zone issues to deal with. The result of this is that at times the developers are forced to make a ‘best guess’ at what a requirement in a story means.

Skill and Experience Imbalance
The second imbalance between regions is not related to the number filling each role but the level of experience and skill in each location. This is most noticeable among the developers on the team.

If you look at the number of developers in each location they are about the same, however on average the developers in London are much more experienced than their counterpart in Delhi. This is in both the sheer number of years spent writing code as well as the skills specifically required by the team such as test driven development (TDD), agile practices, general software design and the specific technologies being used.

The effect of this is that the code quality has suffered, technical debt has increased and more bugs have been produced. This is not an attack on the Indian developers but the experience mix of the team. Any junior team working in isolation would have similar issues.

Attempts have been made to resolve this problem by swapping developers between locations for short periods (around two weeks) so that skills can be shared. Also attempts were made to do remote pair programming sessions and code reviews via phone and remote desktop but these failed to have much long tern effect and were discontinued. The developer exchange was the most helpful but it was still not as productive as having all of the developers permanently collocated.

If the team were located together the experience imbalance would be less of an issue, as the junior developers would have the more experienced developers to advise them and ensure that good practises are being maintained.

Activity Imbalance
The final imbalance between the regions relates to testing. Unlike the other roles, the number of QAs in each region and their experience levels they have are very similar. The problem we have is that the testing activities being performed in each region are not the same.

Our team performs two distinct types of testing.

  • Testing that is done when a story is completed by a developer that tests that story’s specific requirements, and
  • End-to-end testing done after the system is deployed to an environment similar to that found in production.

These two types of testing are not shared equally between locations. Story level testing is more frequently done in India while the end-to-end testing is generally done in London.

It is important for the QAs to have easy access to the developer who has just finished a story so they assist them in diagnosing any problems and it also allows the developer to get feedback on what they have just completed. This should preferably take place while the story is fresh in the developers mind and not moved to the next piece of work as continual context switching is demanding.

Often from a London developer’s perspective it feels like story’s are ‘thrown over the wall’ to the QAs in Delhi and there is then not much feedback on its success or failure. This seems to be less of a problem in India where the QAs and developers are close to each other and can work together.

The outcome of this is that the London developers often don’t find out about issues until weeks later (possibly during end-to-end testing) by when they have moved onto other stories.

So what we see is that while the overall structure of the team appears fine the problem is that in each location the team has deficiencies that cause it issues. Redrawing the story flow for each location it probably looks more like this:

In London there is a strong link between BAs and devs due to their easy availability but a weak link to QAs because it is most likely that the tester for their story is located in India.

Conversely in Delhi there is a weak link between BAs and developers as most BAs are located in London but a strong link to QAs as the tester for their story is probably a few desks away.

Also shown is the weak link between the experienced developers in London and their junior counterparts in India.

For a team to be productive communication between BA, developers and QAs is very important and they should be able to take place quickly.

A BA should be able to discuss the story directly with a developer in the same location to ensure the requirements are correctly understood. Similarly a QA should be able to test a story reasonably quickly after it has been coded and talk directly to the developer who worked on it to help diagnose bugs. For distributed teams this type of communication is difficult to achieve.

What we see on my team is that while the team as a whole seems balanced, in each separate location they are not.

The teams in each location need to be able to function independently of each other to complete a story without continually communicating to the remote location.

One suggestion that has been made is to break the team into silos (or function teams) where X is done in London and Y is done in Delhi. This however makes the team inflexible to changing requirements. You could end up with the situation where a certain part of the system becomes more important but it can only be done in Delhi while the London team sits idle. Knowledge of the system and the workload should be shared across all locations.

The vision should be to have two independent teams that are fully functional in their own right but in different locations, working on the same project sharing work evenly. This also reduces the communication problems, as one location is less reliant on the other for a particular piece of work.