Fog Creek Software
Discussion Board

Change management for small teams

I've been working solo for nearly 30 years and all of my projects have been pretty small stuff. Now I'm working on larger projects (but still pretty small, really) and there is another person involved. Failure to proprerly coordinate our activities is merely an annoyance now, but is likely to prove disastrous if not dealt with quickly. I don't think that this is as simple as using a version control system, but I could be wrong.

I work on all but one of our systems and am having good luck keeping everything I do under control using SourceSafe and Visible Developer. So far anyway :) The other person works on the other system (AutoCAD drawing management, bills of material, etc.). We've now reached the point where we're starting to consume each other's data so we need to put processes (and software?) in place to deal with this. (For example, a few days ago, one person dropped a field, which broke the other person's import routine, which led to a whole class of reports failing.)

I have a pretty good idea of what kinds of things need to be done: Neither of us should make a change without consulting the other; both of us should keep track of what fields, etc. we're using and where, and probably other stuff, too. Obviously there are processes used by those who manage large-scale systems that apply even to the lightweight stuff we're doing. The problem, as I see it, is that these processes look 'heavier' than our project(s).

We've got stuff in Access, Excel, and SQLServer, but everything will eventually be in just SQLServer. We use everything from VBA to .NET, but are trying get as much as possible moved to .NET. I suspect that life will be easier once all the migration is complete, but right now it looks like all the dependency tracking has to take place outside the systems.

Any tips or pointers are appreciated, including terms so that I can actually go search for something.

Ron Porter
Thursday, July 22, 2004

In my previous job we had a "data administrator". Every time we wanted to add, delete or modify a field we had to ask him before the dba executed the changes. This person knew all the applications that we were developing and was aware of the side-effects that a change in the database may cause.  It was annoying at the beginning as we had to queue (sometimes for days) for our changes to be approved. We changed our minds soon as we realised that it helped us avoid the kind of situations you described.

Cecilia Loureiro
Thursday, July 22, 2004

You can try use BugZilla as problem queue.

Thursday, July 22, 2004

We keep the ddl scripts for generating the database in source control as well as everything else.

Yes, sometimes we trip over one another but we can generate a ddl script from the database if we've added fields, tables, indices etc directly.

True this is usually Visual Fox rather than SQL Server but we can do the same for that.

We use NG3Source because we work remotely from each other and about the only thing I'd really like is to be able to cancel a checkout for her (or her for me).

We also use MSN messenger constantly and IssueTracker for handling everything that needs raising, whether its bugs, feature requests or support.

In designing we use Plone to manage all the documents.  We had a slight event with Plone in that all the online documents went walkabout, but I pretty much recovered everything.

Simon Lucy
Thursday, July 22, 2004

I am with Cecilia, we had the same arrangement.  One of you has to own the data.  "Shared" means no one does.  I will also include it is not an envious job as it results in plenty of headaches as you keep track of what fields are used by who.  If there are only two of you then you could share a document that contains what fields are used by what application.  As you grow (you do hope to grow right?), then it can become a position.

The other thing that is helpful is crosstraining. Everyone claims they do it but most are lying or deluding themselves.  Cross training is going through the code with your designated backup.  It benefits everyone if you do because one of you may go to lunch and never come back.  That is not the time to figure it out.

I would also suggest code reviews.  Not because you need them, but because everyone does.  Don't make them painful, just a walk through any changes to see if I missed something (like dropping a field).  You will still miss half the stuff but you will also catch half.  Also, always check working code in so the other person does not have to find it.  It always seems to happen when the developer is on vacation we are looking for "X" they said was working.

I am sure there are plenty more but this is a good start.  I also recommend "Code Complete"
and look at extreme programming not because you choose to use it, but the concepts you are referring to are easily extracted from it.

Thursday, July 22, 2004

Whatever you do, just stay away from "Project InVision" as a purchased solution... <shudder>

Greg Hurlman
Thursday, July 22, 2004

Thank-you to all for the suggestions. I'll be investigating the suggested tools (and finally stop procrastinating on Code Complete!).

I think that the 'data administrator' job suggested by Cecilia is probably the key to the whole thing right now. Since I'm likely to end up with that task along with everything else, I guess I'd better focus on coming up to speed on the other guy's work and why it exists. Along the way, I'd better start doing some kind of documentation so that my successor has something to start with.

Believe it or not, I'm actually quite excited about transforming first myself, then the process.

Ron Porter
Thursday, July 22, 2004

One of the large projects I managed, long, long ago had between 4 and 6 developers all working generally on separate parts of the application suite but there was no source control whatsoever.

So I suggested the big red book, whenever someone needed to work on a module they wrote down the files they had to take in the book with the date and their signature and then write in when they'd finished with them.

It didn't solve everything, but it helped and at least they knew who to blame.

Simon Lucy
Thursday, July 22, 2004

Code Complete second edition is now available ...

Friday, July 23, 2004

Keeping a log of changes on the databases/fields could be useful. This can go at the beginning of each programme as documentation or providing inputs on a small change log database.  Interesting to document on this database why a change is required (with more reasons that it is just the developer's own style).

Definitely as Cecilia says someone has to own the data.

Evolution and me
Friday, July 23, 2004

*  Recent Topics

*  Fog Creek Home