Ziki - David Baird's last published content

Ziki - David Baird's last published content http://www.ziki.com/en/davidlbaird+3994 sun, 22 Oct 2006 23:43:56 +0200 120 My aggregated content at ziki.com http://davidlbaird.blogspot.com/2006/10/ive-been-putting-off-this-blog-thing.html I've been putting off this blog thing for too long. I've decided that I finally need time to write some interesting things, and stop thinking about what I should enter in my blog. As if that wasn't enough, I am starting my blogging with two separate sites. This one, on Blogger, is for just about anything I can think of writing about. The other, I put a link on the sidebar, is just about the Agile related things I am doing at work.

I am already published on the web, and just so those other articles get linked from my shiny new blog, here are their links:

I still stand behind what I wrote back then, though I admit that our work environment has greatly changed. I still don't believe in development process suites, even more now than then.

Instead, I am really big on project broadcast centers. A great example is Trac. We don't use it, but if I were to start working in a new company, I think I'd start with Trac. It unites all the various process tools in use with a history log of different activities, and links to a relative web page display of the activity. For example, it has a tool for viewing source code changes for every delivery to the project's main codeline; it will link to a build report for every automated CruiseControl build; and other activities with a web interface.

For small groups, I do think that the version control tool is the collaboration workspace of the project. However, there is another model for version control which involves promotion levels, and is necessary for really large projects. Both approaches are needed and should be considered at the appropriate level. That is, even in a massive project of hundreds of engineers, each small team of five to fifteen members will need an active and dynamic collaborative version control workspace, even while promoting changes to a more rigid project wide version control system. Ideally, both version control systems are the same tool.

As for the BuildForge review, since IBM bought them out, I don't think it has anymore value. I also think that CruiseControl does much the same, and it's what we currently use.

I haven't really decided what to write about in Blogger verses in Agile Journal. Perhaps future articles will touch on non-technical things in my life. Wait and see. ]]> sun, 22 Oct 2006 23:43:56 +0200 tag:ziki.com,2006:/article/1026996 http://davidlbaird.blogspot.com/2006/10/how-much-does-local-culture-affect-your.html How much does local culture affect your software development environment. What I'm talking about is how team members communicate with each other, and I'm not just talking about the language. I am thinking specifically about the Jim Highsmith book Agile Software Development Ecosystems which pushes for a common room for all engineers to work in. This is to encourage free communication, and to allow conversations to be heard even subconsciously by engineers as they work.

Perhaps this idea makes sense in a culture where people go to work, and avoid contact with their team members. I've worked in such a place, in lots of places like it. I can work all day without saying a word to a co-worker, even if we are separated only by a low cubical wall. The question is, would I talk to them if there were no cubicle walls? And what about my current employer, which gives everyone their own private office with a door? When I visited our offices in San Diego, no one would say good morning, let alone ask me a question, unless scheduled a meeting and sat in their office. One on one, the conversation would be very lively, but otherwise, the environment was rather stale, quiet.

Things are a little different in our Haifa, Israel office. We all have offices with doors, but there is this cultural attitude, and I am sure it is rather Israeli, that one can go into any one's office and ask a question, and get undivided attention and a thoughtful answer. A common phrase while standing in line is, "I just have a question," as a means of cutting ahead. Even if you are sitting in a meeting with someone, another colleague will open the door, ask a question, and get immediate attention, then back to the meeting. Cell phone calls get the highest priority, although there is a new tendency to let the call go to voice mail when in a meeting.

This leads to the need for all team members to work together in the same room. We do have this opportunity as well. We have labs with assigned workstations. Our team lead asks us to work in the lab a few hours a day, even if we don't need lab equipment to do our job. This is to facilitate that level of communication which Agile advocates recommend. Truth is, it does increase the number of interactions I have with other team members. They go up to me, or call me from the other side of the lab, and ask their question or discuss their coding problem, or whatever else they need. I can't say it isn't productive, it is. On the spot conversations lead to very relevant ideas and solutions.

So where is the problem? I don't get my work done in the lab. I mean, I pretend I am working, but really, I am debugging something, fiddling with the comments, or doing code reviews. Ten minutes won't pass by without a question. I know being in the lab is important, because I do want to help solve problems. Furthermore, I know that people don't want to write an email or schedule a meeting, they want to see me to ask a question.

When I really want to get some code written, I go to my office and close the door. I suspect it is a cultural thing, and I really wonder what working in a common room in other countries are like.

I've heard about a team which worked in the lab in our San Diego offices who didn't talk to each other at all, except at weekly meetings or through email. They worked no more than a few feet from each other. I might get an question emailed from one of them, and I answer. I assumed that the information I wrote would be shared, but a couple weeks later, I find out that the other team members had no idea that I had already answered the question.

So perhaps putting all team members in the same room is not the only answer to being agile and productive. ]]> sun, 22 Oct 2006 23:43:25 +0200 tag:ziki.com,2006:/article/2786484 How much does local culture affect your software d... http://davidlbaird.blogspot.com/2006/10/how-much-does-local-culture-affect-your.html How much does local culture affect your software development environment. What I'm talking about is how team members communicate with each other, and I'm not just talking about the language. I am thinking specifically about the Jim Highsmith book Agile Software Development Ecosystems which pushes for a common room for all engineers to work in. This is to encourage free communication, and to allow conversations to be heard even subconsciously by engineers as they work.

Perhaps this idea makes sense in a culture where people go to work, and avoid contact with their team members. I've worked in such a place, in lots of places like it. I can work all day without saying a word to a co-worker, even if we are separated only by a low cubical wall. The question is, would I talk to them if there were no cubicle walls? And what about my current employer, which gives everyone their own private office with a door? When I visited our offices in San Diego, no one would say good morning, let alone ask me a question, unless scheduled a meeting and sat in their office. One on one, the conversation would be very lively, but otherwise, the environment was rather stale, quiet.

Things are a little different in our Haifa, Israel office. We all have offices with doors, but there is this cultural attitude, and I am sure it is rather Israeli, that one can go into any one's office and ask a question, and get undivided attention and a thoughtful answer. A common phrase while standing in line is, "I just have a question," as a means of cutting ahead. Even if you are sitting in a meeting with someone, another colleague will open the door, ask a question, and get immediate attention, then back to the meeting. Cell phone calls get the highest priority, although there is a new tendency to let the call go to voice mail when in a meeting.

This leads to the need for all team members to work together in the same room. We do have this opportunity as well. We have labs with assigned workstations. Our team lead asks us to work in the lab a few hours a day, even if we don't need lab equipment to do our job. This is to facilitate that level of communication which Agile advocates recommend. Truth is, it does increase the number of interactions I have with other team members. They go up to me, or call me from the other side of the lab, and ask their question or discuss their coding problem, or whatever else they need. I can't say it isn't productive, it is. On the spot conversations lead to very relevant ideas and solutions.

So where is the problem? I don't get my work done in the lab. I mean, I pretend I am working, but really, I am debugging something, fiddling with the comments, or doing code reviews. Ten minutes won't pass by without a question. I know being in the lab is important, because I do want to help solve problems. Furthermore, I know that people don't want to write an email or schedule a meeting, they want to see me to ask a question.

When I really want to get some code written, I go to my office and close the door. I suspect it is a cultural thing, and I really wonder what working in a common room in other countries are like.

I've heard about a team which worked in the lab in our San Diego offices who didn't talk to each other at all, except at weekly meetings or through email. They worked no more than a few feet from each other. I might get an question emailed from one of them, and I answer. I assumed that the information I wrote would be shared, but a couple weeks later, I find out that the other team members had no idea that I had already answered the question.

So perhaps putting all team members in the same room is not the only answer to being agile and productive. ]]> sun, 22 Oct 2006 23:43:25 +0200 tag:ziki.com,2006:/article/1026997 http://davidlbaird.blogspot.com/2006/10/robert-cowham-has-some-pretty.html Robert Cowham has some pretty interesting ideas about how to best work with Perforce. I bring this up because I was going over with our Perforce administrator how our various project teams were working with Perforce. First of all, so I don't forget, you can start by reading Robert's rather short article on Perforce Auto Merge. I'd rather call it the Catchup/Publish process, and not the other way around. If you dig deep in the article, you will note that Miki Tebeka wrote a GUI interface, and I'm very grateful that he did.

Before working with Perforce, I was in charge of our sites ClearCase usage. As soon as UCM came out for ClearCase, I understood it was the version control process our teams were looking for. Basically, because it allows for parallel development in private branches while providing automated tools for synchronizing with promoted changes and promoting new changes in a controlled manner. I was looking for something similar for our teams switching to Perforce.

Robert provided the answer of how to get it done. Catchup is the process of synchronizing private branches with newly promoted changes. This is the engineers time to get his changes working with team members changes. This is the process which involves the most use of the merge tools because of coding conflicts. Publish is the process of promoting changes to the team's integration branch. There should be no conflicts, as the development branch is already synchronized with the integration branch upon publishing.

Miki's GUI is not widely used in our teams, and that is what currently concerns me. In fact, when merge problems do come up, it is determined that if the engineers were to use the Catchup/Publish tools, and in the correct order, first catchup, then publish, the merge problems would not have occurred. The question is, how does one enforce usage of this process? The Perforce tools allow one to bypass any process tools put in place. This is my current challenge, and I will post an article when I've overcome it.

One can ask, why work in private branches at all? We have two teams working on a common branch, since Perforce already provides means for synchronizing one's workspace and resolving conflicts on a file by file basis. I worked in one of these teams. The process is fine when one engineer is making most of the changes assisted by two others working on their own files. Such is the case in our system conformance test scripts project, where I maintained the infrastructure classes, and two other engineers were writing test scripts. Our experience is quite different when a team of five to ten engineers are working on a shared source code structure, and better control is needed over changes, while allowing engineers to submit their work parallel private versioning.

The main point is, if you are working in a team with parallel private branches and an integration branch, you can get away without a dedicated integrator if you follow a Catchup/Publish process. There are a few other things you need for a stable and lively integration branch, but more on that in another article. Hint: CruiseControl. ]]> sun, 22 Oct 2006 23:42:48 +0200 tag:ziki.com,2006:/article/2786485 Robert Cowham has some pretty interesting ideas ab... http://davidlbaird.blogspot.com/2006/10/robert-cowham-has-some-pretty.html Robert Cowham has some pretty interesting ideas about how to best work with Perforce. I bring this up because I was going over with our Perforce administrator how our various project teams were working with Perforce. First of all, so I don't forget, you can start by reading Robert's rather short article on Perforce Auto Merge. I'd rather call it the Catchup/Publish process, and not the other way around. If you dig deep in the article, you will note that Miki Tebeka wrote a GUI interface, and I'm very grateful that he did.

Before working with Perforce, I was in charge of our sites ClearCase usage. As soon as UCM came out for ClearCase, I understood it was the version control process our teams were looking for. Basically, because it allows for parallel development in private branches while providing automated tools for synchronizing with promoted changes and promoting new changes in a controlled manner. I was looking for something similar for our teams switching to Perforce.

Robert provided the answer of how to get it done. Catchup is the process of synchronizing private branches with newly promoted changes. This is the engineers time to get his changes working with team members changes. This is the process which involves the most use of the merge tools because of coding conflicts. Publish is the process of promoting changes to the team's integration branch. There should be no conflicts, as the development branch is already synchronized with the integration branch upon publishing.

Miki's GUI is not widely used in our teams, and that is what currently concerns me. In fact, when merge problems do come up, it is determined that if the engineers were to use the Catchup/Publish tools, and in the correct order, first catchup, then publish, the merge problems would not have occurred. The question is, how does one enforce usage of this process? The Perforce tools allow one to bypass any process tools put in place. This is my current challenge, and I will post an article when I've overcome it.

One can ask, why work in private branches at all? We have two teams working on a common branch, since Perforce already provides means for synchronizing one's workspace and resolving conflicts on a file by file basis. I worked in one of these teams. The process is fine when one engineer is making most of the changes assisted by two others working on their own files. Such is the case in our system conformance test scripts project, where I maintained the infrastructure classes, and two other engineers were writing test scripts. Our experience is quite different when a team of five to ten engineers are working on a shared source code structure, and better control is needed over changes, while allowing engineers to submit their work parallel private versioning.

The main point is, if you are working in a team with parallel private branches and an integration branch, you can get away without a dedicated integrator if you follow a Catchup/Publish process. There are a few other things you need for a stable and lively integration branch, but more on that in another article. Hint: CruiseControl. ]]> sun, 22 Oct 2006 23:42:48 +0200 tag:ziki.com,2006:/article/1026998