Communication with customers and within a programming team, even one as small as two is vital. Take today’s scenario: we have an entry form where the user can select multiple names to be added to a list. When the form is submitted, we send the result off in an email.

The first time I implemented this, I had it so that the user typed in the details submitted the form and then used a standard part of our system for selecting users to add them to the object. But the customer didn’t like this because it was easy for the user to forget to click the ‘Finished’ button to trigger an email to be sent and for the object to progress in the workflow.

So I reimplemented it using ajax: the list of users is manipulated using ajax CRUD and then when the user submits the form, the email is sent. To keep it simple, I used a suggest style text entry that populates a drop down list with suggested names as the user is typing. This seemed like a good way to select from a really big (>4000) list of names.

However, the customer wasn’t happy with this form because it didn’t conform to the standard way of selecting names which is to offer the user the choice of typing a ID, a name or to click the letter of the alphabet and get to another page that lists the names starting with that letter. So I was asked to make this functionality happen in the ajax.

It was easy enough to add the search by ID entry but the alphabet clicking list was a pain. I had to make a second hidden part of the form to toggle into view and populate with names when the letter is clicked. It works ok but the list of names for each letter of the alphabet is still very large for certain letters. When I spoke to Dave about this, he just said it’s what the customer wanted and we can’t argue with their stupidity.

I’m sure that with some proper communication we could come up with a better way of doing this that moves the product forwards rather than having stupid design decisions implemented into it at the behest of people who don’t understand the technical problem.

What can we do to improve this situation? How do you convince a customer that they are wrong without getting them offside and when do you have to put your foot down and refuse to do what they ask?

A couple of months ago I started work for a small IT company that sells a web application product which is at heart a specialised CRM.

My first task was to setup version control so that I could collaborate with the other programmer who works remotely. I chose subversion because I wanted to start very simple and it is widespread and has lots of supporting tools. I also setup webSVN as a quick way to view the repository.

We have a number of customers who each need the web app to do slightly different things. It’s a bit of a maintenance nightmare but currently we maintain a separate branch for each customer. For each customer we also have a staging site that also has it’s own branch:

• root
  • trunk
  • tags
  • branches
    • customer1
    • customer1staging
    • customer2
    • customer2staging

• ...

On the webserver I manually rsync files from a clean working copy of the subversion repository. That way I get a little bit of buffering between doing a svn update and publishing live.

When we do work for a customer, I work in the staging branch and when I’m ready to show the customer, we just update the web server to the HEAD of the staging branch. Once that work has been given the greenlight, I copy from the staging branch to the customer live branch and commit that so that we have a rollback path for the live site and can also keep an eye on what it’s up to.

If I develop features for one customer that we can use in the main project I also use SVN merge to get the changes into the trunk.

Doing all this merging requires me to document where I’m merging from and to and which revision numbers in the svn logs.

So some problems with this approach are:

• The complexity of the merging makes it error prone
  
• Merging from branch to branch takes a lot of time – when I have a bug fix that needs to go to all customers, it’s a lot of work.
  
• There is duplication of effort when I need to integrate sets of changes between customers where the divergence of the code is enough that automatic merging can’t be done
  

The alternative to all this branchy maintenance is to actually make the code have a lot of conditionals to handle the case for each customer or make the different customisations to be configurable options. I wonder if it’s worth the pain to consolidate all the customer branches and go down this road? The drawback of having the one codebase for everything is that it can take time to integrate differing ways of doing things into the one application – the complexity of the code could end up being a source of bugs.