It smells worse if you realize that the 15 other developers in the meeting are impacted by exactly 0 minutes of that hour, and are lucky if the meeting is only an hour.

Ahh... I see that a stringent dose of RUP is helping you see the light on the true business value of lengthy meetings and inordinate amounts of shelf-ware documentation. (sarcasm intended)

Two comments:

"Team building a feature is far better than a group of individuals doing tasks" - lately I have been trying to lead a Scrum team where there is no Sprint Backlog.  In exchange, I make sure during the Sprint Planning Meeting everyone understands the goal of the Sprint and commits to the user stories.  I will tell you how it works out.

"Something smells if you sit in a meeting for an hour and are only impacted by 5 minutes of that hour." - institute the "Law of Two Feet" from Open Space.  If someone is not getting anything out of a meeting within 10 minutes, they can leave no questions asked.

If you ever wondered what the point of Twitter is, it is little observations like this. ;)

Pingback from  Stand-up meeting practice ¦  Micka??l Sauv??e’s blog

Good observations.

On the source control issue, I think it is also possible for developers to go overboard on this advice and check changes in too frequently. I've seen lots of developers view source control as a personal backup system rather than as a repository for a working build. When this happens you get all kinds of bottlenecks occur with people checking in non-working code that breaks other people's code.

I think as long as you have a continous integration system in place that runs tests and you have set up a culture where it visible and a bad thing to break the build, then you can encourage very frequent check-ins. Otherwise, I would temper this advice with a warning about the integrity of the build being paramount.

@Russell,

Branching. Make a branch, do days work, check-in, merge from the trunk, check-in again.

Source control IS a personal back-up. It's on the server, your desktop hard-drive isn't.

@Jeremy,

I find DiffMerge from SourceGear (it's free) to be so much better than SVNmerge. When used as described in the help, it's quite nice.

@Simeon - I disagree. I think working folders should be mapped to a network drive on a server that is backed up. The purpose of backup is to make sure you don't loose work. The purpose of source control is to be able to logically manage changes, revert to prior versions, and easily diff files.

I like  branching, but merging has its own overhead associated with it, so I prefer to only use it to manage production branches or major functionality forks for very large teams. I don't think it is worth the overhead to have every person have their own branch.

@Jeremy - I agree. CI is key, but I although the idea is becoming mainstream, I don't think the practice is quite mainstream yet. I just started a new job and set one up for them. They recognized that it was a good thing, but I don't think they ever would have gotten around to setting it up if I hadn't taken the initiative.

@Russell - Working folders on servers doesn't scale to large teams, or large projects, or both.  I agree trunks shouldn't have 101 check-ins a day. Keeping a personal branch in sync is no harder than keeping a working folder in sync. In fact it's the same effort. Because nobody else is changing your personal branch. You then check-in a larger change-set to the trunk/project branch. Seams it's on the server, your version uses code based space per user, where-as a branch uses delta's. This all assumes your using a real repository tool.

@Simeon - I don't agree that disk space considerations should be a major factor in determining check-in policy. My working folder is only a small portion of the space I am using on my network drive. Most disk space issues in my organization have been addressed by putting policies in place about storing large personal files such as mp3's, movies, and photos. Relatively speaking, src text files don't take up that much room, especially since you are only keeping the most current version.

I also have some concerns about the affects of using one personal branch per person would have on the effectiveness of continuous integration practices. For example, would you run a separate continuous integration build for every person? If so, that will introduce some major overhead and scaling problems on your build server. If not, then I question whether code will be integrated frequently enough. If I have to go through a two step process to integrate my code (checking it in and then merging my personal branch), then I will probably reduce the frequency I do this as much as possible. This will negate the effects of getting more immediate integration feedback.

@Russell - my server issue is more of a IO concern with developer directories on a server, gigabit ether gets swamped quickly. As to CI, why would you do integration testing when your not integrating it? It's a personal branch. So points where really, compiling code that sitting on a non-local disk doesn't scale. Long periods of not check-in code into the trunk is bad. I find personal branches a solution that fits my needs.

Pingback from  Barbricks.Com » Little observations

Pingback from  sgentile.codebetter.com/.../little-observations.aspx