I started as Software Development Manager about 5 years ago and I’d like to share some of the changes that have occurred since then.  Some of those changes I’ve worked hard to create, some were pushed by others within the business, but collectively I believe we’ve achieved a lot.

So, let’s start with looking at how things used to be in the development team…

We aimed to release a new version of our software every 6 to 12 months.  This involved collecting a big list of requirements and dividing them up amongst the team.  However, what actually happened was that we started with more than we could do.  This was fuelled by a business need to aim high and stretch ourselves.   As the months progressed we picked up more “must do” requirements that we added to the next release and before we knew it our release had taken 18 months to finish!  We often delayed a release whilst we waited to complete something that no-one actually wanted.  The pressure to delay a release while we added something new just got bigger the longer a release was delayed – if the next release was going to be a year away, we couldn’t possibly wait, so it was better to delay the current release a few more weeks whilst we added that item.  A vicious circle of ever delayed releases was created and getting to “done” was extremely difficult.

Not only was this bad for morale, it was bad for our own processes.  As we didn’t have an official release of software we would send out builds done from a developers PC that included the bits a particular customer required.  As you can imagine, trying to keep track of who was running what and supporting our customers was very problematic.  No one had a standard, official release of software so we relied on knowing each customer’s quirky software versions.

This was only made worse by the tools we used.  We used Visual SourceSafe for our version control.  Now it was always pretty reliable for us so I don’t wanted to knock it too much, but it didn’t help us branch and merge our software to handle our various customers and changing requirements.  It was definitely not helping us, but at least we didn’t suffer from some of its well known limitations.  We had outgrown it and needed more if we were to improve.

As I mentioned we often released software direct from a developers PC.  Again our tools did nothing to help with this.  We didn’t have a dedicated build machine (well that’s not quite true, all official releases were done from my machine and that relied on me not doing anything to upset the build).  The build wasn’t automated in any way, so was time consuming and error prone.  We gradually progressed from a checklist I put together so I didn’t forget something from the release, to a home brewed C++ application that did some of the work for us.  However, a build would still take a day to put together and was often unreliable or had missing components.

Another consequence of having such large release cycles was the workload on the test team (all one of them).  They could go months with nothing to test and then we’d apply huge amounts of pressure to get the software tested and released when we were finally ready.  Increasing the size of the test team was not really an option when they were only busy one month in 12, but for that one month we were drastically short of testers.

Our development team had very little structure.  Whilst we had a few Senior members on the team, that generally just meant they got given some of the more difficult developments on the list.  We all sat in a large open plan office, which was great for everyone knowing what everyone else was doing, but terrible for concentration and solving difficult problems.  The other major drawback was that any support issues would take over the whole team.  We just couldn’t focus on delivering the new features as we got too engrossed in solving the interesting problems our customers were experiencing.

Which brings us to the next area; support.  We only employed developers, so they were the ones answering the support enquiries.  They would answer the phone and respond to the emails and the quality of those communications would vary drastically – some would go to great lengths to explain the problem and show how clever they were to have found a resolution, others would expose their grumpier side at the need to explain a trivial issue for the fifteenth time!  Developers could lose whole days or weeks with customers on issues that should have been addressed with better information, training or sales support.  They weren’t writing any software, which for a software developer was unrewarding and for the business was unproductive.

Again, as we only had developers on the team, as well as covering the support side, we were also called upon to do all of the installations and to attend meetings with the sales team and offer pre-sales support.

When we all sat in the office, working on a desktop PC was no problem, in fact they offered good performance for the price, but once we started going out of the office we struggled.  No-one had their own laptop, so we shared an aging Dell laptop.  Somehow this was never quite right, never had the latest source code or tools installed.  Before anyone went on-site they would need to spend a day updating and preparing the laptop for their visit.  As well as sharing a laptop we would share a mobile phone – at least this didn’t require any setup!

It wasn’t just laptops that were lacking in the equipment department.  Developers worked from a single CRT display and still developed using Visual Studio 6.  The test team didn’t have a single representative hardware platform to test on, they just used the 2nd hand developer PCs.  This made any form of compatibility and performance testing very difficult to complete.

The test team, not only lacked representative hardware platforms to test on, they lacked test systems to exercise our product properly, i.e. the sorts of systems our customers were using.  They’d developed test scripts that were very effective at finding bugs in the first few versions of software, but no longer found the issues our customers were experiencing.  In fact several releases of software were sent to customers where even the basic functionality didn’t work!

Another area that we covered as developers was I.T. support.  Perhaps unsurprisingly this area was also lacking.  We ran a central server with limited storage space and an unconvincing backup process.  Our remote access into the office was also unreliable.

I’m pleased to say that the developers I had in my team were all very talented and had a fantastic understanding of the product we worked on, but that wasn’t always the case.  We’d had several colleagues in the past who could talk a good game, but really couldn’t perform.  As we had no defined interview process, we were very much in danger of repeating this mistake (and we should all learn from our mistakes).

The final area to mention was the general state of the office we worked in.  Whilst it was located in a beautiful and picturesque location, inside the space was being wasted, the walls looked shabby and the desks looked very tired.

Next time we’ll look at how these areas have changed from the primitive practices described above to something more modern.  However, before we do, I think it is worth noting that even with these obstacles to success, the team still triumphed.  No matter how good or bad the environment, processes and other practices, it is the people that matters the most.