Stories
Slash Boxes
Comments

NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

use Perl

All the Perl that's Practical to Extract and Report

use Perl Log In

[ Create a new account ]

dws (341)

dws
(email not shown publicly)
http://www.davewsmith.com/

Journal of dws (341)

Friday February 20, 2004

11:59 AM

Social pressure in distributed teams

[ #17524 ]

Unit tests aren't much good if you don't run them. Duh. Unit tests get in the way if they take a long time to run. Developers will avoid running them, even when social pressure is applied.

On my current project, we've tried to achieve a balance. The standard "build" that happens after normal editing runs the in-memory subset of our unit tests. (On a fast laptop, it adds less than 7 seconds to the build.) And I've arranged to fail the build if any test fails. Nobody complains, and large parts of our application stay unbroken.

The "live data" tests run separately, since they required creating a test schema and populating it with test data (and this requires access to a server, which isn't guaranteed for various semi-legimate reasons). This separation of tests works fairly well except that I can't get people to run the damn database tests on a regular basis. Waiting for the overnight build to catch problems takes too long; problems can multiply unseen in the interim.

There are technical aspects of this problem (e.g., we could, for a small expenditure of time, set up a continuous integration and test environment), but I think the bigger problem here is social.

Social pressure works well in colocated projects. One need only walk a few steps before applying a bitchslap. And "Whoever checks in broken code has to wear the funny hat to the morning meeting" can be very effective. I'm looking for techniques for applying pressure in a distributed team.

List all Journal entries

Social pressure in distributed teams More | Login | Reply

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Without JavaScript enabled, you might want to use the classic discussion system instead. If you login, you can remember this preference.

How about this... (Score:1)

by jcavanaugh (1007)

Create a little application that places a picture of the person that broke the build with the goofy hat on everyones desktop background. -- John C
- Re:How about this... (Score:2)
  
  by dws (341)
  
  It's a bit hard to get at their desktops, but the project home page... Oh Yeah!
Carrot and Stick method... (Score:1)

by bluto (225)

Until recently I worked on a large distributed development project, for about 10 years, composed of different government labs and a large corporation. It is very hard to influence someone to do something right if they work for a different organization and they view you as not quite human since the only interaction they have with you is email or phone. (Hopefully this isn't the case.)
More than once I've seen folks sign off on tests, but there was no way they could have run the tests since by observation
How difficult is it? (Score:1)

by jplindstrom (594)

So what's the manual procedure to run the tests? Is it a single command/click?

Does it block the development? (can it be run in the background?)

Can it be run on both what's checked in and what's yet to be checked in?
- Re:How difficult is it? (Score:2)
  
  by dws (341)
  
  The procedure for compiling the system, running the in-memory unit tests, and building a .war file for deployment is
  
  ant
  
  To do the same, and install in a Tomcat server, the command is
  ant install
  
  To compile the system, run the in-memory tests, then run the databases tests, typing
  ant dbtest
  
  does the trick, assuming that you have access to a live database server. Each developer gets their own sandbox, so there's no risk of A stepping on B.
  All of this is incredibly simple, but people wh
Re testing (Score:1)

by grantm (164)

On my current project we have an automated background process running the full test suite every couple of hours. If the tests pass, the code is tagged and checked out onto the staging server which is the first time the client gets to see/play with it. If anyone breaks the build, then no code gets promoted to staging. There's always at least one of us with some new code we want in front of the client so if the stick needs to be waved, we take it in turns to wave it.