Friday, 25 December 2015

Building a Total Quality Software environment, with Continuous Integration, Unit Testing, and Dependency Injection. And Futurama.

Recently at work, I’ve been working with my colleagues to set up a Total Quality software environment. I’ve been learning a lot from my peers about topics such as VMware, RTI and Code-First EF. (I’d previously used Schema-First, but Code First brings its own advantages and challenges). What I brought to the party was some project experience in: 

  • Continuous Integration platforms (specifically in this case, TeamCity.)
  • Unit Testing and Test-Driven Development techniques.
  • Dependency Injection to support writing testable code.
  • NAnt scripting.
  • Futurama.

We’ll get to that last one in a minute. Let’s go through the others in order first.

Continuous Integration (CI)

Everygeek who’s anynerd is using it these days. But lots of development teams and companies still avoid it, imagining it to be too difficult, too time-consuming, or just not worth the hassle. (For that matter, those same fallacious criticisms can be levelled at every other item in the list above too. Except Futurama.) A decade ago people used to say the same things about Source Control; thankfully there aren’t too many teams I encounter these days that haven’t got their head around how important that is.

Some teams aren’t even sure what CI is, what it does, or what advantages it brings. They’ve always worked by developers just producing software on their own PCs. And they just deal with any time-consuming fallout when it comes to making that software work in the real world as part of the cost of doing business.

OK, so here’s the unique selling point if you’re trying to make the case for introducing this where you work. Are you ready? What CI adds to your team’s game is simply this: repeatable, verifiable deployment. 

Unit Testing and Test-Driven Development techniques 

Unit Testing has been around for a Very Long Time. I know a lot of people who are otherwise very good developers but who “don’t see the point” of unit testing. And I have been such a developer myself in the murky past. 

The misconception that unit testing is pointless generally comes down to a few fallacies:

  • They believe that their own code always works.
  • The wider team and stakeholders place more value on quantity of new features than upon quality of existing features.
  • They believe that they will always personally be around to ensure that their code doesn’t get broken in the future.

Like most good fallacies, there’s just enough truth in most of these to preserve the illusion that unit testing doesn’t provide enough advantages to the person that has to implement it. Not when compared to the opportunity costs of them learning how to do it, or the kudos of pushing out new features (that don’t work as intended.)

Part of the reason more developers don’t give it a go, is that you have to change the way you write code. Most code I’ve seen in the wild is tightly-coupled. This is a phrase that many developers are familiar with, but in my experience vanishingly few know what it means. Basically, it means that if you are writing Class A, and your class depends upon Class B to do its job, your class will instantiatiate a new instance of Class B itself. This means that if Class B stops working, all you (and Users) know is that your class “doesn’t work.” They won't care if your code is perfect, and it's just that damn Class B that let you down.

So, when doing test-driven development, developers need to add another couple of skills to their arsenal. Which brings us to… 

Dependency Injection (DI)

One type of Tight Coupling is defined above. Code is also tightly coupled when it is too closely tied to one UI. So, if you’re a developer that puts all their business logic in code-behind files or controller actions, your code won’t be testable. Because your code needs the UI to do its job, before it will be able to be verified.

Fortunately, there are frameworks and coding styles out there that help developers implement loose coupling, to make their code independently testable. 

The basic idea behind all of these is that instead of your Class A consuming Class B directly to perform some function, it consumes Interface B instead. That is, some object that Class A doesn’t instantiate itself, satisfies some interface that represents the job Class B was doing for Class A. Typically this is achieved by making the constructor of Class A look like this :

 The above pattern is known as Constructor Injection. What it gives you is the ability to swap out whatever is implementing Interface B when it comes to unit testing Class A. So, instead of the object that really does implement Interface B in live use, you can use what is called a mock instance of Interface B. That is typically some object that always gives you anticipated responses. So you can concentrate on testing Class A. That way, any errors you see can be wholly attributed to Class A.

When you write your classes using the Constructor Injection pattern demonstrated above, DI frameworks provide concrete implementations of objects that implement interfaces at runtime. So, you 'magically' find a usable implementation or Interface B available in Class A's constructor. As the developer of Class A, you don't care particularly about where that implementation of Interface B comes from; that is the responsibility and concern of the developer of Interface B and your chosen DI framework.

This is just one of the techniques that developers moving from code that "just works" need to learn if they want their code to be verifiable. It is difficult to embrace. Because frankly writing code that "just works" is hard enough. And because using these techniques opens up the possibility of developers having to recognise errors in their own code. But unit testing also brings with it a huge number of advantages: The ability to prove that a given piece of code works, not just at the time of writing but every single time you build. And it protects your work from being modified in adverse ways by subsequent developers. 

Unit testing and Dependency Injection are whole topics on their own, so I won't say more about them here. (I'll perhaps save that for future blogs.) With regard to understanding tight and loose coupling, though, I'll leave you with an analogy. If a traveller wants to get to some destination, they don’t need to know what the bus driver’s name will be, the vehicle registration, what type of fuel the bus uses, etc. They just need to know what bus stop to be at, what time, and what is the correct bus number to get on. Similarly, Class A doesn’t need to know everything about Class B or where it comes from. It just needs to know that when it requires an object to do some job, one will be available at an agreed time. Class A instantiating Class B itself is analogous to a traveller trying to build their own bus.

Last time I checked, there were something like 22 DI frameworks that you can use with .Net. The one I implemented at work recently is called Castle Windsor, which I’ve been using for a few years. In benchmark tests it’s not the fastest. It’s not the simplest. And it’s not the most customisable/powerful. But it is the one that for my money strikes the right balance between those competing factors. And it integrates particularly well with ASP.Net MVC and Entity Framework. 

NAnt Scripting 

Continuous Integration platforms on their own give you a powerful way of automating builds and deployments. However, there are advantages to be gained to farming out some of that work to a more specialised tool. NAnt is one such tool.

For any system that gets developed, there are typically 10-25 individual “jobs” that are involved in setting up a copy of the system that Testers and ultimately Users can access. e.g, for a web app you might need to:

  • Create some Virtual Directories in IIS.
  • Copy the files that the website is made of into the folders those VDs point at.
  • Customise a web config that tells the site how to access the underlying database.
  • Create the underlying database in SQL Server.
  • Populate the database with data.
  • Create an App Pool in IIS under which the site will run.
  • Grant the relevant App Pool access to the database

You’d also be well-advised to have steps that involve:

  • Running unit tests, so you don’t deploy broken code.
  • Updating Assembly Information so that each build has an identifying number. That way, bugs can be reported against specific builds.
  • Backing up any prior version so that you can rollback any of the above steps if the deployment fails.

If you put these in a script that lives in your project instead of in build steps on your CI server, you can more easily mirror steps between different branches in your builds. 


One of the things that motivates me is getting to have a bit of fun whilst I work. In the team I joined a few months ago, there has been one common theme tying all of the above threads together: Futurama.

Myself and my colleagues have set up about 10 Windows Server 2012 machines that perform various jobs. e.g., One of them is a Domain Controller. Another is our CI server. Several more act as paired web and sql servers that can be temporarily allocated to testing, by internal testers or by end users. Or they can be used by developers to test the deployment process.

Each of our VMs is named after a Futurama character and has its own distinct colour scheme. (NB: They have a fully-qualified name too, like DVL-SQLALPHA, that describes their actual role.) This helps developers stay oriented when RDP-ing around what would otherwise be nearly-identical machines. It’s also fun.  

You saw how TeamCity / Professor Farnsworth looked above. This is how one of our Web Servers, characterised after Zapp Brannigan, looks. As you can see, it's easy to tell which VM you're on, even from a distance:


There are Futurama-themed Easter Eggs hidden in other parts of our build process too. e.g., each CI build produces a log file. At the end of which, a build gets reported as “Successful” or “Failed” for some detailed reason. A recent evening in my own time, I wanted to test implementing custom NAnt functions. (NAnt is written in C#, and you can write functions in C# to augment what it does.) In order to test this with something non-critical, I augmented that custom “Success” or “Failure” method thus:

The exact piece of ASCII art that gets rendered reflects whether the build was successful or not, and is semi-random. So, you might get Hermes with a brain slug saying something dumb if the build is broken. Or you might get Professor Farnsworth announcing “Good news, everyone!” if all went as planned.

These 'features' are of course whimsical. But at worst they give developers a smile during some of the tougher moments of the job. And at best they give you a chance to test out new techniques on non-critical features. As well as giving your brain a rest between more intensive tasks.

The best teams  I’ve worked with all knew their onions on a technical level, but also knew when to have fun too. I'm glad to be working in such a team at present. e.g., I recently implemented the following function:

My colleague Ian made me chuckle when I discovered this in our code repository a few weeks later:

Saturday, 10 October 2015

Product Review - Wrappz Laptop Decals and Custom Phone Skins

Like many developers, I get my money's worth out of the laptops I buy. Sometimes it seems I use them every minute of the day. And, over the years, I've accumulated quite a collection of physical machines in addition to the various VMs I have carrying out miscellaneous tasks around the house.

I secretly love the obviously-marketed-at-women ones that have cases made of pink brushed aluminium and the like. But, also being a professional developer, I have to say that almost always that fancy case comes accompanied by last year's technology (or older.) It simply isn't a good business decision to buy them when you review the spec.

As a wise philosopher once said, I'm a Barbie Girl in a Barbie World.

So, I often end up buying machines that have phenomenally-fast dual/quad processors with acres of RAM capable of running lots of memory-intensive applications concurrently. And I switch out the standard platter drive for a 1 TB SSD. (I usually also swap out the optical drive for a second 1TB SSD. And 2TB SSDs that I've not yet had a chance to get my hands on have also now become available, so my next dev machine will have 4TB total, but that's really a different review.)

Anyway, for some reason the most performant laptops always seem to come in boring black boxes. When you acquire a few of these over the years, it becomes difficult to tell them apart. So for a few years now I've been putting decals on the back and naming the machine according to which decal adorns it. I also make the login screen and desktop background of these machines match the decal. This all helps keep you oriented when you're navigating around, RDP-ing from one machine to another.

TaylorHe Decals

Up to now, my go-to decal manufacturer has been TaylorHe. They do some very nice pre-made patterns that suit almost every taste. With my new work laptop, however, I fancied doing something a bit more bespoke. I'm a huge Breaking Bad fan, so I wanted a machine that had a theme related to that. 

Since the device that I usually take pictures with is in this photo, my friend Ian O'Friel
kindly helped me take this. Which made it a much better photo than it would otherwise have
been as he has a real eye for photography. (You can see more of Ian's fab photos here. I
particularly like the one of the old rusty gate and the South Side At Night.)
Looking around, I found a company called Wrappz that provides exactly this type of product. Not only do they produce decals with custom designs, but they also print them on a custom-sized sheet. So you don't have to trim them to fit your machine. This may seem like a small advantage, but it was nice just to be able to use them out of the box like that rather than messing around with a scalpel or scissors.

Like TaylorHe, Wrappz also do custom phone cases. So I got one of those to match the decal. (Not that I actually own a phone, incidentally - I'm one of the few people I know that doesn't use one, and doesn't miss it. I have a Samsung Galaxy S2 'phone', but it acts as a personal organiser rather than as a communication device. I only put a temporary SIM in it when I have a reason to, which is almost never.)

If you want to order some of these decals / phone cases for yourself, here are some discount codes you can use to get them more cheaply. NB: I've got no commercial relationship with Wrappz, and I haven't benefitted in any way from this review. Also, I won't know whether anyone has used these codes:
Wrappz discount codes

More Wrappz discount codes

Last small tip for those who, like me, have multiple laptops in their network to access. You can place the name of each machine in the Task Bar by creating a new Toolbar, and calling it "\\%computername%", as described here. It makes it amazingly easy to see which machine you're on, even if you have a full-screen program running, and even if you're accessing it from another physical device.

Computer Name on Task Bar

Saturday, 5 September 2015

Peninsula Business Services - Glasgow Office, Glassdoor review

I recently worked for a short while at Peninsula Business Services' new Glasgow office. I attempted to submit a review on my experience at  However, it was deleted several times without explanation. This behaviour does make me wonder how credible Glassdoor reviews actually are. It seems I'm not alone in having doubts about Glassdoor's credibilty. Several other review contributors have reported having negative reviews removed without explanation upon companies paying fees to sanitise their ratings. And several companies' HR departments have reported being approached by Glassdoor salespeople with offers to clean up their reputation for a fee.

Whilst my review was overall negative, it was also balanced, accurate, and written in professional language. It didn't identify anyone by name, and the original version referred to only one person by job title (the Head of IT). All of this falls within Glassdoor's purported guidelines.

I've submitted yet another review today. In the absence of any information about what may have been "wrong" with previous reviews, I've removed a lot of detail. If it doesn't get published, I will publish it here instead.



Shiny new office, replete with brand new desks. PCs still with the plastic on, and Niels Diffrient chairs (not a spelling mistake, btw - that's the chair designer's actual name.)

Most people are fairly pleasant.

Salary reasonable for a developer working in Glasgow (£45k).

They make a very healthy profit.


Peninsula drags employees from Scotland half way across the country on a 7-hour round trip to Manchester on their first day. Just to attend an “induction” course. As well as being a waste of time, this course was frankly a little patronising. Topics covered included how to sit in a chair, and how to find the first aid kit. The most galling thing about this was that when I did get a minor cut threading PC cables through a sharp corner of my new desk back in Glasgow, I discovered there was no first aid kit. Management rationalised that the reason for this was to avoid them getting sued by having out of date supplies in it. Instead of just admitting they’d made a mistake in failing to buy one. This is a company that claims to specialise in giving Health & Safety / Legal advice to other companies. Perhaps they ought to get their own house in order first?

I was lied to during recruitment and contractual negotiations. I spotted that the users were located in Manchester whilst the development team is based in Glasgow, and asked the Head of IT how he proposed to address this limitation? I was told we'd be using “teleconferencing” and that intermediaries like Business Analysts and a Product Owner would be available to communicate requirements between the development team based in Glasgow and users based in Manchester. The truth was that there were no Business Analysts or Product Owner fulfilling this role on this project. Consequently, developers were expected to travel to Manchester in their own free time very frequently. And often for reasons that didn't make a lot of sense. Such as attending that induction course to learn how to sit in a chair and about first aid kits that don’t exist. Or for purely political reasons such as “to get your face seen.” Not to mention that there was no “team”. I was the sole and only developer in Glasgow.

The fact that regular travel to Manchester was expected should have been stated on the actual job spec. And when I was switched on enough to ask about the geographic concerns of having users in one place but developers in another, the recruitment team and management should have been honest about the frequent need for travel at that juncture. Instead, a clause about "occasional travel" was squeezed into the small print of the written contract. When I asked about this and stated clearly that I wasn't looking for a role that involved travel, I was given reassurance that I'd only need to spend one day in Manchester for that induction course (my original joining instructions had referred to an "induction week".) However, after attending that one day, literally my first day in the Glasgow office I was asked to travel to Manchester again. That was twice in my first two days. My manager, who started the week before me, had travelled 8 times by that point, and has done so again 2 further times in the two weeks I worked there. I do not consider this "occasional".

Developers in Manchester do not have phones on their desk. Apparently as a matter of policy. This perplexed them as much as it did me. It made communicating knowledge about existing projects far more difficult than should have been the case. When you have development teams spread out across the country, put phones on the desks of the people who need to collaborate. This is a no brainer. It shouldn’t need to be explained or debated. But apparently some elements of management have strange ideas about putting their direct reports in silos and only allowing indirect communication. This is the exact opposite of how Agile is meant to work. A project like the one I was assigned to should take 3-4 months max to complete. Owing to issues like this, it will take Peninsula far longer, if it gets completed at all.

You need to raise every issue, however minor, via a helpdesk ticket. Even if it is only a simple request for collaboration with someone in the same team. Often I found this red tape was just an excuse to rationalise and ignore the issues reported or information requested. I found tickets about damaged equipment were closed for spurious reasons, or simply deleted without explanation. I guess someone’s stats and performance evaluation depended upon how many tickets they closed/suppressed rather than on how many actual problems got fixed. I’m a developer. I shouldn’t have to raise a helpdesk ticket to find out a simple technical detail or obtain a database backup. These things should be sorted out with one phone call in an environment that claims to be Agile. And if new equipment arrives damaged, it should be returned to the manufacturer for a free replacement or repair. Not just accepted as is, and the ticket deleted. That wastes company money, and it reduces the equipment available to front line staff.

Peninsula claims to aim to be an “employer of choice”. However, they seemed to fail to realise that this necessarily means they will be dealing with employees that *do* have choices. It's therefore inadvisable to paint one picture of the role during recruitment, then expect us to put up with a radically different reality on the actual job. Companies who behave that way tend to lose new employees very quickly. There are literally thousands of other companies in Glasgow and the Central Belt competing for the same hard-to-find IT skills as Peninsula is seeking. And most of them have more reasonable demands than Peninsula. (Most particularly, they don’t expect you to endure that horrendous 7 hour round trip commute to Manchester in your own free time on a regular basis. Especially for the spurious or political reasons mentioned.) I turned down two other jobs to take this one, by choice. When it became clear the role had been mis-sold, I had another job offer within 48 hours, starting the day after I finish at Peninsula. I know many of the other good .Net developers in the Glasgow area, and most of them already have jobs. I know how difficult it is to recruit them from having been on the other side of the hiring table in other roles. It’s easy to get your employer brand damaged by having unreasonable expectations, making nonsensical management decisions, and misrepresenting the role. Word gets around very quickly indeed. And even if you do manage to fool someone with less options into coming on board, and begrudgingly sticking around for a few months, tolerating that horrendous commute to Manchester. You’ll only have someone that will become de-motivated owing to the nonsensical management policies I mentioned like that issue with the phones, or burned out very quickly owing to the poor work/life balance that unreasonable commute entails.

The Glasgow office is at present a building site next to another building site (see the pictures of construction workers in the building I posted, and the construction site next door.) And there is no air conditioning, despite us having had to sit and listen to a talk on how to use air conditioning during that awful induction course. This means the windows are open on the side with the external construction site all day. The IT department is in an open-plan office, sandwiched between salespeople making cold calls all day and advisors also taking phone calls. All this therefore makes for a very noisy and distracting environment. It is not at all conducive to a concentration-intensive task like software development.

Much of the recruitment literature describes the ‘Glasgow’ office, which is located in the Finnieston area, as being “in Central Glasgow” and “within walking distance of the city centre”. This is utter nonsense. Peninsula are deluding themselves if they believe this to be true. Or worse still, are foolish enough to try to delude local people who know the area well. Finnieston is close to Glasgow city centre only on Google Maps. It is two train stops away from Glasgow Central station. It is about as close to Glasgow city centre as Salford is to Manchester city centre. And with many of the same attendant social problems. e.g., the one time I had my car broken into in Glasgow, it was in the PC World car park across the road from Peninsula’s Glasgow office. Nobody ever walks from Glasgow city centre to the Finnieston office. Because to do so you’d need to spend 20-25 minutes walking through several known drug areas and the red light district. It is to be avoided, especially at night. One of my previous roles was in the Glasgow police, so I know which areas of the city are high in crime and which aren’t. Don’t be lulled into a false sense of safety by the fact that there’s a Police Station a couple of doors down. The reason it’s there is because the area has a high crime problem. And the reason there’s plenty of short-stay parking meter spaces in front of the office side streets is that locals know better than to leave their car on the street in that part of town. Ironically, there is plenty of secure parking available in the Skypark complex that the Peninsula office is part of. But since employees aren’t allowed to use any of it that’s a moot point.

Several previous attempts at submitting this review have been deleted by Glassdoor with no explanation given. This makes me wonder about how many other negative reviews have been suppressed. I’m submitting this last attempt, which I have kept as close to Glassdoor’s guidelines as I can. If it gets through, it gets through. If it doesn’t, I’ll post it on LinkedIn and my blog instead. Suppressing negative opinion is extremely foolish, and leads only to The Streisand Effect.

I have a feeling that, if this review even gets published, someone from Peninsula’s Directors' Office will be along to trot out the party line that Peninsula isn't for everyone, and only superstars make it there, etc, etc. I noticed that canned response on some of the other negative reviews herein whilst I was being recruited. That was one of the first things that led me to have some initial doubts. Not just that issues were being raised by front line staff, but that they were treated dismissively. Other factors included my contacting former developer employees of Peninsula via LinkedIn, and asking them confidentially why they left. There aren’t many developers with more than 18 months tenure at Peninsula. I think I now know why.

Advice to Management

Be more honest with yourself and with recruits during interviews and pre-employment negotiations. There's no point in saying you'll be using teleconferencing, if you what you really mean is "We'll be dragging you to Manchester at least a couple of times a month, probably much more frequently. Often for political reasons or just to attend a pointless box-ticking induction course that bears no relation to reality rather than because of any real, pressing business need." A good place to do this would on the initial job description itself, and not in the small print of the contract you only see once made an offer.

Don't just sweep issues that staff raise under the carpet. You can only improve if you acknowledge what's gone wrong and learn from mistakes. Whether it's a missing First Aid box, a helpdesk request, or something more business-critical, it's all the same ethos. You either learn and improve, or you don't and stagnate.

Particularly with regard to hiring software developers, realise that good developers always have other options. It's simply unrealistic to expect us to commute to Manchester when we can easily work in almost any other company that uses IT and doesn't have that nightmare commute. If you need developers in Glasgow, hire them in Glasgow. If you need them in Manchester, hire them in Manchester. But don't hire them in one place and expect them to constantly commute to the other. As Warren Buffett says, you can put on a ballet or you can put on a heavy metal concert. But don't advertise a heavy metal concert then put on a ballet, or vice versa. It's moving the goalposts that's the problem, not having goalposts.

Peninsula's Glasgow office is still basically a
building site. Most of the floors are still being
fitted out for use as office space at some point
in the future. This photo shows two construction
workers in the main lobby.
Desks are new, and have expensive Niels Diffrient
chairs. About 50% of the desks are empty at present.

Small chairs around a small table. An
informal meeting space near the open-plan kitchen
As mentioned, there is still a lot of construction work
going on in the building. This protective covering on the floors
in the main lobby is to protect the floor tiles from damage
by heavy masonry trolleys. One of these trolleys broke the lift during
my first week. It was one of many things I found broken that week.

View from the office. There are windows on one
side only - the side facing SECC and The Hydro. The shine
from The Hydro roof can be very distracting, and lasts all
day since the roof is curved. The blinds can be closed to make
it bearable.

The garage next door is being built at present. As there
is no air conditioning in the Glasgow office, the office windows
overlooking this site need to stay open all day for ventilation.
Combined with the cold-calling sales team and
customer advisors taking incoming calls either side of
the IT 'department', this made for a very distracting and noisy
environment that was not conducive to quality software development.
When I was there, the IT department consisted of me and
one manager. It is now only one 'manager'.

Close up of a typical desk. You have three monitors (two external
and the laptop main screen), and a laptop that should be capable of
utilising all three at once. Unfortunately, owing to a faulty graphics card, the
laptop I was issued could only support the main laptop screen
and one external monitor. (An identical model used
by my manager successfully had all three working concurrently.)
My 'help' desk ticket about this was 'resolved' by stating that I
should just use the one external monitor that did work. When I re-opened
the ticket, and suggested that sending the brand new faulty graphics
card back for a free RMA repair would be a more appropriate solution,
my ticket was deleted without further explanation or attempt at
resolution. The next developer in will therefore experience the same problem.
I wondered if one of the monitors had arrived smashed whether "use the two that
aren't smashed" would have been considered an appropriate
resolution to that problem? Why was it any different when the problem was
a faulty internal component that should have been easily replaceable?


Obligatory disclaimer: The views expressed are my own and don't reflect the views of my employer.



Update 17 September 2015:

You couldn't make this up. Peninsula has now responded to my review thus:

"Dear Sirs,

Having considered the content of this post, we would be grateful if someone could please review it with a view to it being removed. Our reason for flagging this post to you is that the review contains a number of inaccurate comments which we categorically dispute, including that the former employee was “lied to during recruitment and contractual negotiations” and that “a clause about “occasional travel” was squeezed into the small print of the written contract”.

For clarity, we do not have “small print” within our contracts all text is in the same size and typeface. Moreover, we did not lie about the fact occasional travel would be required either during recruitment or within contractual negotiations. As the poster accepts, her initial joining instructions referred to an “induction week” that was due to take place at our Head Office in Manchester. As it was, this particular employee was only requested to attend a one day induction in Manchester but then refused to travel to Manchester again when requested to do so within her first week of employment. She provided no explanation for her refusal and if a reason had been forthcoming, this would have potentially allowed us to resolve any issues that she had and/or reached an amicable, alternative way forward.

In addition, there was no expectation that she would be required to travel within her own “free time” as she asserts as she was permitted to travel and return home within her normal working hours. She was employed for one week only we find it astounding that she is able to cast false aspersions about us an employer which potentially affect our reputation to anyone reading the review.

Our Glasgow office is in its infancy and this particular review gives a very misleading impression of our offices and the premises. We absolutely welcome constructive feedback from our employees and we fully accept that there might be some teething problems associated with new office premises but the location and its surroundings are all issues which are abundantly clear to a candidate when he/she attends an interview.

Given the above, we would be grateful if you could please review the post as it seems to us to be a malicious attempt to damage our reputation. As an employer, we recognise the benefit which Glassdoor provides us and our potential employees with in respect of feedback (positive and negative) which we constantly keep under review in order to make improvements where necessary. That having been said, we cannot accept the type of inaccurate information presented in this post by an employee who worked for us for less than a week.

If you require any further information or evidence to counter the comments made within the post, we would be more than happy to provide this"

Apparently, despite my alluding to it
previously, Peninsula still hasn't heard
of the Streisand Effect

So, apparently photographs of the actual office and its surroundings give a "misleading impression" of what it's really like. And despite the fact my review has already attracted 3 "helpful" votes from other Glassdoor users (who are presumably Peninsula employees themselves) in the short time since it was published, apparently its facts are in dispute. One of those "disputed" facts is that I was apparently allowed to make that awful commute to Manchester during "normal working hours". Well, just for clarity, I stayed over on the Sunday evening prior to my start date for that induction course. And I wasn't able to travel back until after work on the Monday evening (I got home at 9pm and was at work by 8:10am the next day.) I still have the cattle class train tickets if anyone from Glassdoor would like to see them. I would further note that if as claimed I were to travel to Manchester during "normal working hours", that would mean I'd have spent 7 hours travelling and only 1 hour on-site, since they work a standard 8 hour day there. In actuality, I was on site all working day on that Monday because I was required to travel in my own time, exactly as I claimed. 

As for my not giving a reason for my decision not to make that 7 hour trip in my own free time for the second time in two days - Peninsula weren't entitled to any further explanation or debate beyond it not being something I'm prepared to do. I stated this clearly during contractual negotiations; I still have the emails I sent to the recruitment team to prove this. It would seem Peninsula simply proceeded in the hope that once I'd come on board I'd have no option but to put up with unreasonable travel in my own time, regardless of the limitations on my willingness to travel that I'd made clear in writing during negotiations.

Furthermore, when it became abundantly obvious on that first day back in the Glasgow office (my 2nd day in the job) that Peninsula had radically different ideas about the role's need for regular travel to Manchester, my exact words to my manager were, "If we're going to fail, it's best to fail fast. If you do need someone that's prepared to travel to Manchester on a regular basis, I can't accommodate that, and I doubt you'll find anyone with the right skills that will. I feel I was crystal clear about that before accepting the job. But, if that's what you really want, let's just be adults and call this quits right now. So I can go and see if there's still any interest from the roles I had to turn down to take this job, and you can go and recruit the type of resource you apparently really need." My manager at Peninsula's response to this offer was, "No, we've done the hard part of getting you on board now, and we don't want to lose you. There's no need to leave." Despite this, a week later he came back and stated that Peninsula was terminating my contract for exactly the reason discussed - i.e., that they really wanted someone prepared to travel from Glasgow to Manchester on a frequent basis. My manager claimed that he disagreed with this decision, but that he had been over-ruled on the matter. I felt this indecisiveness bordering on duplicity merely wasted more of both of our time and represented further bad faith on Peninsula's part. Fortunately, when I did belatedly go back to the roles I'd had to turn down, there was still interest, and I was made another job offer within 48 hours. Otherwise I'd have considered suing Peninsula for negligent misrepresentation of their position that had cost me another opportunity. As it is, I consider that I've ended up in a very much better role, that pays a little more, gives me an extra hour in bed, where I can park my car safely outside my place of work, and most of all affords me the opportunity to work with some great new colleagues that, unlike Peninsula, do not resemble the cast of The Office.

Anyway, whether or not Glassdoor does decide to remove my entirely factual review, it will remain published here and on LinkedIn. Watch this space to see just how much Glassdoor's claims are worth that employers can't get reviews they disagree with suppressed. If you're a Peninsula employee yourself, and you agree with the valid concerns I raised, I'd ask you to take a few moments to mark my review as Helpful. Perhaps if enough people do this management will stop hiding their head in the sand long enough to wake up and improve matters at the Glasgow office for those unfortunate enough still to work there.

I would note that, as of this time, Peninsula have been so disorganised that I haven't even been paid for August, let alone the part of September that I worked. (I worked from 24th Aug to 9th September inclusive, and not "a week" as claimed in Peninsula's response.) Nor have I received written confirmation of their decision to terminate my contract. Suffice to say, Peninsula's management couldn't run a bath between them. Any developer worth their salt would need to be mad or desperate to take a job with them in their Glasgow office. They are an utterly clueless employer, with only a death march project and inept, Jekyll & Hyde management to offer the next unlucky incumbent.


Update 08 Sep: OK, I've given it a week now and my review on Glassdoor has been deleted several times. Positive reviews have meanwhile been published.  I can't help concluding that Glassdoor's review system is a sham that serves neither employees' nor employers' interests, but only the interests of Glassdoor. The fact that employers can pay to suppress negative reviews (even though Glassdoor denies this is the case), makes it no more than a blackmail scheme. Anyway, here is how my review should have looked. Decide for yourself whether there were any legitimate reasons to suppress it.

Update 09 Sep: I see the photos I submitted (posted at the bottom of the review above), which show the real working conditions at the Glasgow office and that were approved for a couple of days have been deleted now as well. Glassdoor really is a disgrace, and an insult to candidates' and employees' intelligence.

Update 10 Sep: Mysteriously, my review and photos have been placed back on Glassdoor. Guess they finally worked out that you can't suppress the whole internet. A Google Search for "Glassdoor Peninsula Business Services Glasgow" shows this blog fairly near the top, alongside the Glassdoor site. Rather than it being embedded amongst other reviews. My review will remain published here (formatted into paragraphs - the Glassdoor version is a Wall Of Text) in case they change their minds once again.

Update 23 Sep: Quelle suprise, my review on Glassdoor has been removed without consultation. Clearly all an employer has to do to whitewash their reputation on that site is ask and possibly pay for the privilege. Peninsula actually has a member of staff, Dan Grayson, dedicated to this sort of whitewashing. To quote from his own LinkedIn description his job is "researching, highlighting, promoting and sustaining Peninsula's brand and reputation online through challenging negative comments or ratings". For most companies, this isn't a problem that is even on their radar. Others, like Peninsula, are clearly so bad that it is someone's full-time job. Remember that when reviewing all those supposedly-positive reviews that remain posted on Glassdoor. Meanwhile, this blog and LinkedIn will continue to show the actual opinion of an actual Peninsula employee far more prominently in Google search results than would have been the case had my review just remained one of many on Glassdoor. Google Analytics suggests that people considering working for Peninsula are finding this information, and not just taking Glassdoor's sham reviews at face value.

Update 24 Sep: I'm approaching the end of my second week in the role I took up after departing Peninsula. It could just be that Peninsula was so bad by contrast, but I can honestly say that my new role is the best place I've ever worked. My new colleagues are fun. The management is competent but friendly. The work is challenging but doable, and the equipment we're using is top of the line. I've worked with some really great teams and some fantastic managers and developers in my 25 years in the software development industry. But this new company is the best of them all. I tried to do the right thing by Peninsula by sticking by my decision to accept their offer, even when the opportunity I'm now enjoying came calling only a few days afterwards and it was my preferred option. I'm very glad that Peninsula decided to end our relationship, freeing me to take up what has turned out to be the best role I've ever had. The Universe has a way of looking after you sometimes, I guess. :)