Fog Creek Software
Discussion Board




The last few days before a product ships

were always the scariest time for me when I was managing software development.  Why?  Because as the last few known bugs were getting stamped out by the developers responsible, other developers were getting bored.

Those bored developers were trying to keep busy, and that meant they were changing code.  Code that was already considered stable.  I'd find the strangest things changed or even broken immediately after a release.

How do others keep people engaged and productive right up until the end to avoid these types of problems?

Bob Crosley
Wednesday, November 28, 2001

One way out is to get them writing help. (or at least checking all the help goes somewhere useful).
I also think that anyone who complains about help files should be forced to write one.

Peter Ibbotson
Wednesday, November 28, 2001

I do two things.  The first thing I do is anyone that doesn't have a bug assigned to them is locked out of source control.  Can't change what you can't get access to :-)

The second thing I do is I get the developers that are not doing anything started on the next version.  Not so much writing code, but investigating new technologies that we might use.  Get them into brainstorming meetings and let them talk about refactoring whole portions of the application.  Set up a Quake III server.

Justin

Justin Rudd
Wednesday, November 28, 2001

When programmers write tests for code before they write the code, then refactoring is much less likely to lead to regression.

This is important especially when tweaking code about which they've forgotten all the details.  The tests "remember" details forever.

It is no panacea, but it does help a lot.

Robert Anderson
Thursday, November 29, 2001

Regressions:

The only problem with that is getting bugs in test cases because the specification moved on.  Naturally if you're using Extreme methods you should move the test cases before moving the code.

For those that do use Extreme Programming how many do actually revise the test plan?

Simon Lucy
Friday, November 30, 2001

Some of your developers are bored and idle the last few days before the ship date; others are removing a few bugs.

Congratulations!  You won!  This is what *should* be happening just before ship date if you have scheduled well.


Want to put the bored developers to work?  Easy.  Create a release branch in your source control system for what you are about to ship.  Then the developers can keep moving forward with the code without adding extra risk with extraneous changes just before the ship date.


Of course, I don't recommend going a long time in this mode, nor do I recommend "code freezes" of significant length.

Kyle Cordes
Friday, November 30, 2001

If it was my choice - I was giving developers a free time, let them simple read the books or play tetris, whatever ..
Getting bored ? While there are so many interesting books on Amazon/eBay ? ;)

Evgeny Goldin
Monday, December 03, 2001

*  Recent Topics

*  Fog Creek Home