Welcome to the first in this series of articles relating to development environment setup. What I’m trying to do here is provide an insight to our systems and the thoughts and reasoning behind why we’ve gone that way.

We’re not a leading authority on the subject but we’re hoping in committing this to the web we’ll stimulate comments and feedback that will help us whilst also providing a resource for others trying to do the same.

This first article is going to focus more on our motivations and limitations, giving background on who we are and what we’re trying to achieve. Later articles will focus on specific items and have more of a “how-to” flavour than this. I feel its worth discussing these items first to give you an idea of where we are coming from; that should help guide you as to how much of the subsequent posts will be relevant to you.

Who Are We ? Mighty Oaks From Small Acorns Grow

My name is Simon Crozier, and I am a development manager / lead developer at HighSpeedTraining, we’re based in Leeds (Yorkshire, UK). We’re not the biggest company (less than 15 people in total), and we work on a relatively modest budget – in short we’re no IBM. We definitely consider ourselves a technology company, although we work in a market that is relatively immature in IT and development terms (e-learning).

Technology in e-learning is generally regarded as equipment and resource rather than key business and market drivers, as such much of what is considered the norm in other industries have yet to be widely adopted in e-learning. We’re a fairly young company and as such it’d be fair to say our development team is still finding its feet slightly but we’re committed to doing things Right.

Its not all bad news though !… Being a small technology company everybody in the team, including non-technical members, appreciates that the good use of technology is key to allowing us to compete with our more established competitors. Further more being a young company we’re still defining our standards and we’re flexible enough to adapt and make big changes quickly. We’re also lucky enough to have a group of developers who are enthusiastic about their roles, see themselves as craftsmen and appreciate you never know enough. No RFAs here !

In short we’re currently in a really positive position, but we think the decisions we make at this point will have a big impact on the company’s future. Collectively we’ve no interest in being good enough; we want to be as excellent as budget allows.

What Are Our Drivers

The development team

For these articles to be useful both for us and you, its important you as the reader work out what it is you’re trying to achieve and have some appreciation for what budget you’ll have to play with. If your budget is tiny some of what we’re looking at simply won’t be practical or possible. Equally if you’ve an enormous budget some of what we’re doing won’t be appropriate for you either – in that you may have options we don’t. We’d love to get some feedback on what the rest of the world thinks about what we’ve done but a comment of “buy X piece of software its brilliant and only cost £3m” – brilliant it might be but that just ain’t going to happen for us in the near future – that said it might still be worth noting because others reading may have the budget.

So what are our drivers here? As a lead developer I want my team to be producing the best software for the future of the business, to do this i need to get the best from each and every developer.

Whilst that’s easy to say, it masks some basic conflicts that every development team suffers from. “How do you get the best for the future that you don’t know yet” :- if the business wanders into submarine building in ten years time, spending nine years developing an awesome cup cake icing process isn’t a good use of time.  That sort of conflict is a given really; frustrating but obvious and its visibility makes it manageable.

There are also more subtle conflicts. For example the “best” code base for the business in our case is the most reliable – appreciated in other markets efficiency may trump accuracy or similar.  On the other hand the “best” code base for developers maybe written in language X that is really easy to work with but resulting code is a little haphazard. As the lead developer the best code base for me is one that can quickly adapt, is easily manageable – i.e. bugs are spotted quickly – and code quality can be assured. Whilst none of these are mutually exclusive there is often a trade-off between them somewhere.

The management of these types of conflict aren’t the responsibility of any one person or a collective, everyone in the business will, at some point, have to give and take. There are things you can do to mitigate these conflicts business plans, project management, development methodologies can all combine to ease the burden but ultimately there is no total solution.

There’s not even a single “good approach”.

In broad strokes what we’re talking about won’t directly resolve any conflicts but it will help to highlight that there is a conflict happening, allowing a decision to be made. Our watch word here is visibility; as I’ve said there is rarely one solution but an early heads-up there is a problem festering is always a good thing.

What we’re going to discuss is simply what we’ve tried, it might not even work for us… if it doesn’t we’ll try to identify why and post up our findings.

What Are We Talking About

What we’re going to be talking about is what we’re doing with our development environment. Not the IDEs and languages as such but the processes that are triggered once the code-base has been altered. The drivers are broadly the same as mentioned above but as a developer myself discussions will likely be skewed towards the developer’s motivations with an eye on where the business is going rather than directly from the business’s point of view.

The aim of this series is to not only tell you why we’ve done something but also how we’ve done it – using screen-shots and coding listings.  I’m going to try and show you the nuts and bolts of what we’re doing, while also highlighting the business motivations and impact of the individual items. Our experience has shown us that for a very little budget and a reasonable amount of time you can have a very decent development environment running. Ideally roughly following what we’re about to set out any team should be able to replicate a similar environment for very little cost and start to get the benefits.

As such for the series we’re using examples surrounding our code base which is C# .net based with NUnit tests around it and some selenium tests but to be honest that shouldn’t matter too much. Most of what we’re talking about surrounds what goes on after the code has been created and is not language specific. The key components we’re talking about will actually be the continuous integration engine and post build events which are pretty much language agnostic.

In A Nutshell

I was explaining the idea for these articles to a non-technical friend and the best metaphor I could come up with was that I discussing building a crane. If you know in advance you’re building project is going to need a lot of lifting and shifting of heavy stuff the first thing you do is build the crane.

There is little value in the crane itself, and it could even be described as non-essential. But in a lot of circumstances the things the crane allows you to do and the speed it allows you to do them more than justify the cost of the crane and its construction.

I see the things we’re going to discuss as similar, arguably non-essentials but the abilities they offer have what I’d think is a massive positive effect on the development team and their ability to consistently produce high quality code.