Setting subversion up to work with contractors

Posted on July 28, 2008

In my last post I promised I’d write another about subversion and how to set things up to work with contractors. I was supposed to post this the next day, but I got caught up with other things.

Anyway, let’s just jump right in…

We run all our projects out of one big subversion repository, some people create a repository per project or group projects into a number repositories. In all honesty it really doesn’t matter how you group things, I think that one repository works better for us, I can move things around and I can allow people access to all or parts of the repository. You may feel differently, but for the time being I’m going to assume you’re working with a single repository like us.

getting started: installing apache, subversion and mod_dav_svn

I recently upgraded to Subversion 1.5, there wasn’t a package available for the version of Fedora we’re running on our server so I had to build it. It was a relatively painless process of simply making sure dependencies existed and following the instructions in the INSTALL file.

http://subversion.tigris.org/getting.html

Go do that now, get subversion and mod_dav_svn installed. There are more than enough resources out there on how to install subversion that I’m not going to go into too much detail about building from source or installing on any specific platform.

In fact since the steps and concepts I’m going over in this post don’t require a specific version I’ll just throw up some common defaults.

If you’re on a Red Hat based linux system try:

# yum install subversion
# yum install mod_dav_svn


If you’re on a Debian based system try:

# apt-get install subversion
# apt-get install libapache2-svn


In your apache configuration file, near the module declarations make sure you have the following lines.

LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so
LoadModule dav_svn_module /usr/lib/apache2/modules/mod_dav_svn.so


setting up a repository

Again moving quite quickly here, there are tons of other better resources for getting started with Subversion on the web, better than I could hope to write. The basic command you need to run simply creates the directory structure that subversion needs.

$ svnadmin create /path/to/repo

It’s usually best to create this somewhere near, but not in the document tree for the webserver.

Open you’re apache config file, or the config file that stores the details for the virtual host you’re using and add the following lines:


DAV svn
SVNPath /path/to/your/repository
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /path/to/your/passwdfile


Now create the htpasswd file and add a user or two using the following commands

# htpasswd -cm # htpasswd -cm /etc/svn-passwd andrew
New password:
Re-type new password:
Adding password for user andrew

# htpasswd /etc/svn-passwd -m simon
New password:
Re-type new password:
Adding password for user simon


Restart apache and that’s it all done. You should now have a running subversion repository with two users, andrew and simon, they should be able to view and commit anywhere. We’ll assume these are staff members who can view and commit on any project.

Setting up for an external contractor

Now you want to bring a contractor in on a project, so let’s create them a user:


# htpasswd /etc/svn-passwd -m john
New password:
Re-type new password:
Adding password for user john


The next thing you need to do is to setup svnauthz to control access to the repository. Back in your apache config file, add the following line into your svn config:

AuthzSVNAccessFile /home/goroam/dev.goroam.net/user/repos/svn-authz


So that it looks something like this:


DAV svn
SVNPath /path/to/your/repository
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /path/to/your/passwdfile
AuthzSVNAccessFile /path/to/your/repository/svn-authz


I tend to keep my svn-authz file within my repository path, you may wish to place it elsewhere – whatever works best for you.

The next step is to create the svn-authz file. That’s as simple as this:

[groups]
staff = andrew, simon
contractors = john

[/external-project]
@contractors = rw


The file is pretty simple and self explanatory but the first block starting with [groups] defines the groups. In this case we’ve got two one for staff with andrew and simon and one for contractors with john as the single member. The usernames to use here are the same as you set in your htpasswd file. Authentication is controlled by the standard basic authentication, subversion is only controlling access.

The next two blocks are paths within the repository. The first:


[/]
@staff = rw
* = r


Tells subversion to give all members of the staff group read and write access to everything under the / path – basically the whole repository. The next line * = r tells subversion to give everyone else, read access to everything.

Again this may not work for you, but we tend to allow read access to everything to everyone with a password. If we trust them enough to give them a password, we trust them. Also it allows contractors to build dependant libraries from the head, which is required at times and saves us the trouble of working out dependencies in our svn-authz file.


[/external-project]
@contractors = rw


In the next block, above, we’re giving everyone in the contractors group read and write access to everything in the /external-project path of our repository. This of course is the project they’re currently working, so your path will be different.

That’s it. Contractors hired, up and running in your subversion in minutes.

Slightly more complicated, but easy now that you know how

Let’s just complicate things a little bit by adding two external contractors from the first company and a third from second working on two different projects.

Let’s say that CompanyA Limited are working on project-x. They’ve asked us to create accounts for Dick and Jane. Then we hire Dave from CompanyB to add a feature called zing-bang to project-y. You could, of course just create two accounts, one for each company – but we tend to avoid that. We like to know WHO committed what code. Not just where they were from, we work closely with our contractors and it helps us when we’re communicating with them.

We know how to create the users, but just to recap here we go again:


# htpasswd /etc/svn-passwd -m dick
New password:
Re-type new password:
Adding password for user dick

# htpasswd /etc/svn-passwd -m dave
New password:
Re-type new password:
Adding password for user dave


Assuming, as above we have andrew and simon as staff users we should make our svn-authz file look something like this:


[groups]
staff = andrew, simon
companya = dick, jane
companyb = dave

[/project-y/branches/zing-bang-feature]
@companyb = rw


We’re only building slighty on the previous file with the groups entries, and that should be clear. The entry here for project-x should also look familiar – Both dick and jane, members of the companya group have read and write access to the path.

For the next entry we’ve created a branch and we have company b working on the branch. I’m really just throwing that out there, mostly because I can, but also to show that you can go to any depth in the repository tree granting access as you see fit.

In this case it’s been determined that the work CompanyB in engaged to complete only needs to take place in this branch, so while they can read the whole repository they cannot write anywhere except here. This would allow you to continue internal development, or indeed external with some more entries on project-y making point releases while zing-bang feature is developed and CompanyB could merge the trunk in at will, since they have read access to it.

a lot of words

It was a lot of words, but the concepts are pretty simple. It doesn’t take long to set subversion up and even with basic auth and htpasswd files it’s not complicated to administer. So go on, get your contractors under control. I promise the dividends paid through increased accountability, visibility and communication will more than offset the time spent administrating the system.

Related articles by Zemanta

• Collaborate and Connect with Subversion

I’ve been a little slack with the posting

Posted on

I’ve been busy and haven’t had a chance to get things posted like I wanted to. Work and personal commitments have a habit of getting in the way of otherwise good intentions. I’ll do my best to get a few posts out this week and I’ll see if I can’t get caught back up and maybe get a few posts written and scheduled.

It’s been an eventful couple of weeks on a number of fronts – I wouldn’t go so far as to say exciting because that would imply all good stuff. Some of it was good, some was bad – other parts just interesting.

Hopefully we’ll be able to push out some good news on the goroam front in the next few weeks. Despite what our detractors may say or think we are working hard on getting things done – but stuff takes time. Especially when other commitments get in the way.

In the meantime, where were we?

Get your contractors under control

Posted on July 22, 2008

In a recently conversation I was told of a situation which I’ve experienced in the past and I’m sure others have as well.

While on holiday the code I’m responsible for has been modified by an external contractor. Before my holiday I pointed out that we should make sure version control is used by anyone making any change. It wasn’t. Now I’m frustrated and pissed off.

The problem isn’t that someone else was editing the code, or that I somehow lost control of a fiefdom or anything like that. It’s that I’ve just spent hours I could be using to do something else tracking down file modification dates and then diff’ing them against my versions out of version control. Time I shouldn’t have to had spent doing anything

The bigger issue is now I’m under pressure by my boss to deliver some changes at the same time as I have to deal with this, and no extra time has been allowed for it.

You pay contractors to do work for you, a large part of that should be to insist they do it in a way that is consistent with your working practices. You wouldn’t let them commit changes to a PHP website in ASP, Perl or Python and equally you should insist that changes are delivered consistently and in a manageable format.

Warning flags get raised if someone tells me they don’t use version control. Not knowing how and asking questions is one thing; I have no problem helping someone, a contractors included, learn our version control system and practices because I see our relationship as a long term one, so any investment in that relationship is worthwhile. If a contractor tells me they cannot or will not use our version control system though, we have a problem and usually we end the relationship then and there. It may sound like a hardline call based on a single criteria but it is a deal breaker for me.

For a contractor there could of course be some concern that they’ve submitted the work and may not be paid. Version control is not the cause of this – it’s dishonesty, plain and simple and if the person you’re working for is that dishonest submitting code via email before the cheque clears is equally risky.  

Some ground rules

Our most basic rule is commit at least once a day while you’re working on the project. This is especially the case if the work is being done on a day rate, but also if the project was quoted on a fixed rate basis. We use the data to judge if a project is on time, we’re completely upfront about why we want this: Knowing the current velocity for changes gives us a really good indication of where we are in the development cycle. With a current version committed to our repository we can just checkout, deploy and see. It removes the chances of miscommunication, misunderstandings and estimate errors.

Committing early and often by contractors is much like releasing early and often to users. It allows us to make regular builds and run QA on the project. The benefits of this are that we can start to run our testing regime long before we would otherwise be able to test. We try to encourage external developers to follow similar methodologies to those we use internally, the primary goal of any new project is to make a deployable release as quick as possible, then add features to it in a sensible manner. This coupled with regular commits allows us to test features as they’re added, not weeks down the line days or hours before the project is to go live.

Once bitten, twice shy

We’ve had a few projects in the past where we outside contractors for a variety of reasons failed to deliver on time. This has lead to our losing a follow up contract on at least one occasion we’re aware of. By getting code committed to our repository we can see where a project is, and if necessary step in early with concerns about the deadline.

Both daily commits and QA help immensely with this and all but eliminate estimate errors because we can have an honest objective conversation about how far we’re going to miss milestones very early in the process because a miss becomes obvious when you can see the velocity. The earlier you can do this, the better your chance delivering on time.

Rules for some, but not others

Sometimes it doesn’t make sense to go the whole forcing version control down someone’s throat route. For some projects and changes we’ll just bang a few files into an zip archive, email it and get the same back, then integrate it ourselves. It usually depends on the scope of the changes and how long they’re likely to be working on the project in question. We would only work with someone familiar or willing to learn version control though, even in the above scenario they’d would have to be willing to use it if we’d asked them to.

How have your experiences using version control with contractors gone? Post a comment and tell us about it!

I think tomorrow I’ll post a bit of more hands on article on setting up version control for contractors. I’ll try to focus a little more on how to build, install and implement subversion with access controls. See you then.

another new design

Posted on July 21, 2008

You may notice that this site has yet another new design today. I’ve left blogger and gone back to wordpress and hosted the blog. I like Blogger and I really like the idea of hosted applications but it just wasn’t giving me the control I wanted and I was finding it time consuming to get things the way I wanted. 

It’s not you, it’s me.

Hosted applications are great and Blogger has got to be one of the best free ones out there. I really do like it, but we wanted to make all our goroam pages consistent, so we bought the great thesis theme from diythemes. We bought a developer licence so we could use it on all our sites and would be free to modify it. 

I wanted something with a little more space for this blog, I liked running things down the side but it was getting too long and I had no space for anything else. For goroam and citrus I wanted to get something that would combine both the info at the top and blogs towards the bottom. Again in the next week or two we’l hopefully get there with this new theme.

is this the last change?

Honestly, no. I’ll probably change a whole load of things over the coming weeks to try and differentiate the sites. Mostly I think I just like to change things.

There is no excuse for… back buttons that don’t work

Posted on July 18, 2008

The back button is one of the strongest and most pervasive conventions available to developers, yet some fail to use it correctly and see it as a burden rather than a resource. The fact of the matter is all users great and small know it’s there. From novice to expert they quickly learn to know and use the back button and taking that away from them in your application, well there is no excuse for it.

The back button has become a usability must by convention; no matter how obvious your navigation is if the user clicks and link on your homepage then wants to go back they are more likely to use the back button than to click a navigation element labelled home, your logo or any of the other ways to get to your home page.

Security, or something

A big offender here is online banking, my back button is always throwing me errors – or worse I don’t even get the address bar and navigation stuff. I’m stuck in their little application and have to use it as they dictate. I’ve heard arguments that this is to make applications more secure. Unfortunately the rhetoric is just that, hot air Not letting me do something useful doesn’t make an application more secure, it just means I’m inconvenienced. Most of the time these applications let me right click and use the context menus to go back anyway- so what’s the point?

If your security model depends on hiding or not letting me do something useful, you have more serious problems than a back button.

But back doesn’t make sense, the process has completed

The back button shouldn’t always just show you the previous page. For example if the process is an order, of course it doesn’t make sense to allow a user to step back into the ordering process and change details. Show them a page that tells them the order is completed, the details and provide useful links to modify the order – chances are if they’ve clicked back they want to change something. If not they’ll just keep clicking back till they get where they want to be.

Which brings us to our next problem…

Why do I have to hammer the back button to get back and skip some redirect page?

I really hate sites that make me do this and the worst thing is, the back button is normally completely functional otherwise. Make sure if you’re using redirects that they’re not chained so that back button use is forcing users to click it a few times to get over a hump in the process.

I give my users a link to use

Not nearly good enough. You’re in fact acknowledging a problem exists and providing a workaround, but your work around flies in the face of convention and forces users to think – usually after they’ve tried the back button on autopilot and things didn’t work out.

That’s just lazy

It all comes down to developer laziness I’m afraid. There is no reason to break the back button it’s a navigation convention all sites should encourage by default and it should always just work.

Saying no some more

Posted on July 16, 2008

Re-reading my post about saying no got me thinking about the other reasons we’ve turned down work. It’s hard getting work in the first place and doubly hard turning it down, but sometimes you just have to say no.

One big one that comes to mind is we quoted to do some work for a company we’ve had a long term working relationship with. A small company, they were unfortunately facing the loss of a key member of staff in the final few months of development of a key project already well overdue. A update to a project we’d worked with before, so we were familiar with the architecture, team and almost every aspect of the project.

We made quoted a day rate at the low end of the scale and offered to agree fixed times for each bit of development, insulating them from any estimate errors by delivering that iteration for the quoted price before undertaking the next. We agreed to put the work we were quoting on first, push our own development schedule back, not take on other work and offer any time the needed to get their project released.

I got the very distinct impression they wanted the work done cheap from a discussion with the technical lead for the project. I tried to mitigate any problems by sending an email detailing our costs and how they break down from developers salaries, equipment costs and the meagre profit margins. I also made it clear that we were uniquely qualified for the work, due to our extensive working history directly with the project.

The response was disappointing, they were willing to pay about half the rate we quoted. I had a brief discussion with the technical lead, who was as disappointed as us with the reaction, but it was clear there was going to be no middle ground. The offer was never even going to come up enough.

We gave up in the end – a shame really, like any small business we could have used the money. It was an issue of value. Despite all the positives, the experience, the fact that there was nobody else who could have hit the ground running like us and our prior working relationships they weren’t willing to pay what we consider a very reasonable price. They effectively wanted work done for less cost to them than it would have cost to hire a member of staff, with none of the security or benefits. A short term contract under terms worse that a job I’d been offered months prior.

In the end they had to give the member of staff who had planned to leave a significant pay rise to entice them to stay, hired another, less experienced developer who needed more managing and training and still haven’t delivered the project, months later.

For us, and for anyone else considering taking work at less than a market rate, it’s a tough choice. Though we could afford to survive without the work, it would have been nice to have the money in the bank. There is also always the potential that work can lead to more work, however do you want cut rate work leading to more of the same? It’s all too easy for it to set the tone of a working relationship and an expectation that you will continue to work for the low rate. Also the whole time you’re servicing the contract you’re not getting new clients or doing other more lucrative work. As a consultant if you’re not saving for a raining day you’re taking a huge risk, especially if things get a bit lean for a few weeks or months.

There is no excuse for… bad URLs

Posted on July 11, 2008

The address bar is at the top of every user’s browser and it’s often totally overlooked by developers. We all know we should think a little when choosing a domain name, well mostly, but after we’ve done that normally let the our toolkit or internal organisation work against the user and clutter up the address bar with crap.

it should make sense to the user

All developers primary motivation, for the address bar as with the rest of the ui, should be something that’s useful to a user. It’s there on every browser, on top of every page of every visitor to your site. Make them short and simple, easy to see where you are, easy to remember and easy to type.

http://mysite.com/products

http://mysite.com/services

http://mysite.com/services/urls

http://mysite.com/contactus
These are all good URLs, easy to see where you are and easy to remember.

I’ve seen a number of applications or frameworks that want URLs in the form http://somesite.com/site/PAGES/EN/index.php. It irritates me just seeing it. None of that cruft has anything to do with anything a user cares about. It’s inattention to detail, it’s endemic on the Internet and there is no excuse for it.

case sensitivity

A URL should not under normal circumstances be case sensitive. Storing something at the same place with the same name only differing in case is very confusing and counter intuitive to users. Don’t do it.

http://mysite.com/HOME

http://mysite.com/Home

http://mysite.com/home

These are all the same to most users and you wouldn’t actually put different pages at each of them would you? So why not do the sensible thing for the user and make sure that no matter what case they use it just works?

The case to use depends on a variety of factors. For most uses all lowercase is probably the best default choice, however using CamelCase in a wiki, casing for adherence to brand standards or common conventions are all reasonable situations where preserving case may be the prefered option. Preserve the case yes, but don’t make the URL case sensitive.

In the 37 signals book Defensive Design for the Web [amazon.co.uk] they point out a classic from a usability best:

I typed “www.apple.com/iTunes” in my browser’s address bar but instead of information on the MP3 application, I received a “Page Not Found” error. Even though the application is called “iTunes” apple’s site only accepts “www.apple.com/itunes” (all lowercase).

This is an unfortunate branding situation for Apple. Customers are actually punished for adhering to the brand’s naming conventions

At the time of this post on Apple has fixed it, both URLs will now give you the correct page but I think it’s a great example. As well as a great excuse to link to the excellent 37 signals book. It’s worth pointing out that the apple page currently redirects to the lowercase www.apple.com/itunes url so it’s not case preserving or using the correct case to adhere to the brand’s naming conventions, but at least it works.

file extentions

Why do so many websites have pages that end in html, asp, php, jsp, .do? Users don’t care about what language you’re using, telling them is pointless and worse makes it hard for them to figure out URLs from memory or by making an educated guess. Take the time to configure your server to at the very least drop the extensions.

The exception to the rule

There are times when a file extention is important, and developers should know when to apply the above rules and when for everyone’s sake not to- when a file extention dictates the mime type, or when you’re providing a file for a user to download you obviously want to maintain the extention. There is nothing wrong with having .pdf, .exe, .dmg, .gif, .jpg, .avi, .mov etc. Most of those files are embedded, or downloaded and should maintain their extensions.

Querystrings

I hate them. I really hate them. What the is index.php?ID=123 anyway, what does that mean to me? Keep your database IDs in the database and give me something useful. Blogs get this right a lot of the time, or close anyway. Forums are notorious for getting this wrong.

A querystring is alright, if you’re running a query, a search or something similar where various parameters are going to affect the outcome. It’s not alright if you’re pulling one element out of a database. It’s alright if you’re using an API. If you’re pulling a single item and the only identifier is a numeric id you can still do better than a query string. How about: http://mysite/items/12345/

why should we care?

It seems like a small thing to worry about when you’ve got a whole application to build. The URL is like a lot of little things, it shows attention to detail. It’s easy to make them sensible if you choose to and it will make some users lives easier. The short term pain of making all your URLs sensible will in the long run improve usability- you might even retain a few more users here and there and eventually that will add up.

Take for example something like a property sales application. Let’s give it two URLs for the sake of argument.

1. http://joespropertysite.com/PAGES/EN/SITE/property.php?ID=233223
2. http://joespropertysite.com/property/spain/malaga/2Bed/StunningTownHouse

I hammed it up a bit on the last one to prove a point- they’re both a similar number of characters but the second is so much better even though it’s longer!

• The second is much more user friendly.
• The second URL is much more information rich than the fist. You’re looking at a property, on a page, on a site written in php in english – or – You’re looking at a property, in Malaga, Spain with 2 bedrooms and it’s a ‘Stunning town house’.
• To quickly broaden a search for related two bedroom properties in malaga it’s obvious you can just remove the last part of the URL on the second. The first you’ll have to use the search function.

No excuse for… regular features on blogs

This might turn into a regular feature, I’ve got a growing list of things and there is no excuse for them. I think what I’ll do is queue them up as I write them then post them for a Friday afternoon read.

Spartan Programming

Posted on July 10, 2008

Jeff Atwood was pleased to find that his coding conventions, the ones we all settle into, have been tending towards those of a style of programming called Spartan Programming. Which is minimalist programming, as in “a spartan lifestyle”. Check his post out for a more in depth explination but suffice to say the aim is to reduce complexity in any way possible.

I’ve got to agree that more and more I’ve tended in that direction too. I don’t remember the last time I had more than a handful of conditionals or loops in a method. My methods are terse and accomplish one thing, sub tasks are split out into other methods. It’s come very naturally, but it has taken time. I don’t think it’s something you can be taught, or learn. It’s definitely a practice thing.

One aspect of Spartan Programming where I disagree is with the terse variable names. I think they could end up introducing more accidental and avoidable errors. They lessen the utility of some key IDE features. And generally would just make my life harder, so I’ve gone the other way. Once upon a time I would happily create the following code:

public void sendMessage() {
    MimeMessage m = new MimeMessage();
    m.setBody("This is a test");
    m.send();
}

These days I try to avoid calling variables things like m and prefer to call them what they are:

public void sendMessage() {
    MimeMessage message = new MimeMessage();
    message.setBody("This is a test");
    message.send();
}

I know the arguments and logic:

• The method should be simple enough that the variable name m is clear enough.
• The shorter name reduces complexity and therefore errors.
• Less characters means lines don’t get too long

Of these three the third is the only one I really buy though. Long variable names and too many characters on a line can push some stuff too far to the right potentially hiding errors or overly complex code; but it’s an edge case and there are other ways to solve the problem.

While true that in a short minimalist method a variable m would be clear enough, a variable called message is equally clear. The shortening doesn’t gain anything in clarity. The argument for less characters reducing errors in the era of modern IDEs doesn’t wash with me either – My IDE tells me of I mistype a variable and auto completes them furthermore by typing actual words I actually improve the accuracy even more.

Shorter names on the other hand can tend more towards a crowded namespace and can result in properly typing the wrong variable. This is especially a problem in a weakly typed language.

Consider the following:

function sendInviteMessages(n)
    for i = 0 to n
        Set m = Server.CreateObject("MimeMessage)
        m.Body = "Welcome to our fancy new site!"
        m.Send
        Set n = Nothing
    next
end function

What you see here is something that wouldn’t happen, or not as often with a variable name like number instead of n and message instead of m. Worse still, depending on the language and how it treats null variables it might even pass a quick test with a single address and appear to be working!

The one place I totally disagree with the terse variable naming conventions though, is the method parameters. That actually makes life harder when working with code completion. Which is easier to follow?

There are plenty of other code completion and helpful shortcuts in a modern IDE where the parameter names are used to make our lives easier. All of which lost, with no real gain.

I’m not arguing that variable names shouldn’t be terse and sensible. Going back to the first example the following is just stupid and is far worse than using just m, it’s practically illegible and very difficult to just eyeball the code to see what is going on.

public void sendMessage() {
    MimeMessage theMessageToSend = new MimeMessage();
    theMessageToSend.setBody("This is a test");
    theMessageToSend.send();
}

Other times I go the opposite way and have adopted conventions for making some variables extremely terse. InputStream and OutputStream variables for example I always call is and os. So I do try and be as terse as possible, but never terseness at the expense of obviousness of intent.

While I agree with most of the practices and like Jeff was nodding along as I read about Spartan Programming, there are a few I don’t fully follow and some I’m against. In the end though I tend to agree with his assertion that Minimalism isn’t always the right choice, but it’s rarely the wrong choice as long as it’s not at the expense of clarity of intent.

Release early – Release often

Posted on July 9, 2008

Agile methodologies have recently been getting something of a bad name, it’s not unwarranted but it is unfortunate. The problem isn’t actually the process, an agile process will work very well – if the infrastructure supporting it is capable of of being agile as well. By supporting infrastructure for a process here I don’t mean servers and software I mean the people and the organisational foundations. The organisation trying to use an agile process must it’s self be agile, quick to react to change. Agile processes that work have one thing in common, they encourage features to be released early and released often.

A pretty basic overview of our process goes something like this:

Big Bag of Features

Our projects and releases go through a number of stages, the first we call The Big Bag of Features. When a project is really just an idea, it’s something we might want to build and we basically rough out some ideas and start to grow them into all sorts of crazy future versions, we talk about all the features we’ll need to achieve them and how we’ll go about it.

Minimum Stable Feature-set

From the BBoF we usually end up with at least one, more often than not a number of possible outcomes and development paths. By talking through all of the options, all the features and all the future versions we’d like to be able to build leads us naturally to something we can build; a vision for a product.

Citrus is a good example of this practice, we’re at the stage where we’ve decided the vision for the project, have a big bag of features we’d like to implement and are now in the process of creating our MSF

From the vision we decide what we need to make a product work; less is definitely more at this stage. We normally take each feature we’ve decided would be nice to have and try to think about who would use it and why. If we can’t come up with a compelling argument for most of our users using it, we normally chuck it back into the bag to worry about later. We refer to the result as theMinimum Stable Feature-set (MSF) or Minimum Launch Feature Set.The bare minimum we need to launch a working product.

The MSF becomes the next iteration, and once it’s set we don’t alter it. Nothing is added or taken away. On the surface this might seem either silly or a bit high and mighty, but we can do it because we put the work in ahead of time. We’ve discussed how we envision the product being used and we make sure we’ve covered all the bases. New great ideas just aren’t important enough to include, no matter how good they are. We leave them for another iteration and another day.

These ideas can be politically disastrous in some organisations, it’s downright heresy to tell the boss, or the sales director or a colleague what amounts to: their newest great idea just isn’t good enough. It’s important for an organisation to have focus though, this is where the MSF and short iterations come into their own. Releasing early and often means that you’re quickly on to the next round of updates and those great ideas can be looked at objectively alongside anything else in the Big Bag of Features.

Getting started

Finally we start coding the interfaces first, then backend to meet our MSF. In the case of a new project partial interim releases are made for testing. We try to work out an entire area of the project first then release that to our testing audience for feedback. As the iterations contiune towards release we add all the features from our MSF.

Updates

When it comes to updating projects we throw away the Big Bag of Features and start all over again.You heard it right, throw them away, gone. A long time ago I learned that feature lists just cause trouble. You can’t help but schedule them, the schedules are very loose and they’re never met but still promises are made based on them. In the end they start to read more like a list of failures, things your application doesn’t do. More importantly, things your application will more than likely never do. So we throw them away and start again with a new Big Bag of Features, the most important features will bubble to the top of your memory anyway and will end up right back in this new BBoF.

For an update our MSF is usually a single feature, or small feature set if they work best that way. The aim is to keep the releases small and concise, targeting one area of functionality. This doesn’t mean that we don’t set milestones or visions for the future development of the product, we normally make a milestone accomplish some greater goal or vision for the product. But we try not to roll a list of disparate fixes to various parts of the application into a single release, we break them up into many smaller releases.

Rinse and Repeat

We continue in this way for the life of the project releasing features to users early and often so bugs are spotted quicker and we never go too far down a dead end, creating something users won’t use. It’s during this stage that we really work hard to measure how an application is being used, or not used so we can focus our energy only on the most important parts. We never try to be everything to everyone, we’re not afraid to disappoint some people or to just say no. We want our application to be great at what it does, not mediocre at everything.

Get your development under control – all about version control

Posted on July 7, 2008

The key to any successful development team, far more than any other tool, is version control. No matter how many team members you have, if you’re dozens of people spread across the globe or one lone developer in a basement you need version control.

A number of free and paid for systems exist, largely they accomplish the same ends: the ability for multiple developers to collaborate on the same code, the ability to track changes and the ability to manage changes across concurrent versions of code.

change management

This is potentially the biggest benefit of any source control system, the ability to manage changes in code. Most version control systems manage changes through a series of checkouts and commits by developers.

You check the code you want to work on our of the repository creating a local copy, make changes to the code and commit your changes to the repository again. Any developers that are working on the code can update their local copies an the changes you’ve made will be merged in.

This can be a massive boon, even if you’re working alone. Version controls systems will also let you roll changes back, so if you’ve made a mistake, deleted a file or need to see how something worked before you can go back to any previous version.

concurrent versioning

Concurrent versioning is a great benefit when you’ve released software or are developing more than one major feature at the same time. It’s the process of having two working versions of the code which can be edited independently.

In the case of a released version of software this allows you to release a patch before new features still in development are ready to be released. You can patch the bug, release an update to users and then use the version control system to merge the change into the development code so that your next release with the new features gets the fix too.

If you’re working on a major feature you might also want to branch your code temporarily. This would allow you to perform some pretty significant refactoring on areas of the code which would not affect developers working on the rest of the code, when you finished the work you could then merge your code into the main development branch prior to release.

what else

For more information about version control see the excellent Visual guide to version control at betterexplained.com.

How to get started

There are a number of choices and a number of web based version control systems. Opensource subversion and git are used by a large number of people and compete on features with most commercial offerings. If you don’t want to set up your own server to host a repository Google code, beanstalk and lighthouse are just a few web based services that can host version control environments for you. Google code is free, but you’ll need to be developing an opensource project the other two are subscription services.

I personally use subversion and love it but with any version control system, commercial or free the most important thing is to pick and fit a system into your development environment. Don’t pick one that is going to force you to change the way you work. Try a couple if you can and pick the one that works best for you.