Home > Development > Maybe I was a bit hasty …

Maybe I was a bit hasty …

In October 2011, I accepted a job at a company I previosly referred to as ABCD. I had a number of reasons for accepting the job, not least of which was that ABCD were in the business of selling software to “big business”, and as a result had a vast number of three- and four-letter initialisations with the odd acronym thrown in. As a move from a company whose business model and management I had ceased to believe in, it seemed like the ideal opportunity to add a few useful phrases to my otherwise “small business”-focussed CV.

Of course, dreams can sometimes turn into nightmares. Rather than the model of ruthless efficiency that I expected, I was shocked to discover the number of areas in which ABCD could have performed so much better. In my four months at ABCD little changed, and for reasons that will be explained in a later post if change does happen it will not be by my hand. A few typical examples:

Source Control

ABCD use Microsoft TFS, in itself not a minus point. Unfortunately, at the point of initial setup it was misconfigured such that to edit code a developer must branch from the “tested” tree back into “development”, update all the version numbers, change permissions, and then perform their edits. Once fully tested, code is then branched back into “tested” with a new version number and the “development” tree cleared again.

Project Structure

The entire system contains some 50 to 100 individual Visual Studio projects, some of which are merely business classes to support a single UI project. No solution files are used (due to the paths to the projects constantly changing), therefore a developer typically has 3 or 4 instances of Visual Studio running.

Project Management

All work is managed through a central bug database, where a developer is assigned a “bug number” to work on (whether it is for a bug or a new feature). Through daily timesheets, which are emailed to the management team, progress is updated until the work is ready for “unit testing” – a document written by the developers that runs through a few basic tests of functionality that is then uploaded into the bug database to indicate that system testing can commence.

I could easily write a dozen more points, but all of these are issues that are put up with. People faced with situations like this can generally be divided into three separate groups:

  • Those who are aware of the issues, and choose to do nothing;
  • Those who are aware of the issues, and try to change them; and,
  • Those who are unaware of the issues.

I try to be the second of these, however the most I feel I’ve been able to do is turn a few of the “unawares” into “aware but choose to do nothing”.

A company generally gives an employee three months to prove themselves before they are made a permanent member of staff. I’m a firm believer in the converse also being true: an employee should give an employer three months, in order to show that they are a company that the employee wishes to stay with. In my case, ABCD was sadly not a company I wished to stay with, and so in late February 2012 I updated my CV and returned to the agencies, cap in hand, hoping that mistakes such as this are lessons to be learnt from and not repeated.

Categories: Development
  1. No comments yet.
  1. March 22, 2012 at 2:47 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: