[p4] Which dept for build/release engineers?

Janulewicz, Matthew mjanulew at alarismed.com
Tue Jun 15 12:59:26 PDT 2004

I think it has at least a little to do with proximity. I'm not saying that
proximity will encourage this to happen outright, but it doesn't do anything
to prevent it from happening when CM doesn't have enforcement authority. Not
everyone has (or has had) the luxury of working in a mature, disciplined
engineering environment. In, say, a startup environment, having the (not a)
testing group and engineering group coupled so closely makes it much easier
for everyone to develop and maintain a free-for-all attitude.

I'll put this another way, with a real-world example. Let's say you had to
hire a third party to do some work for you, some experts in the field.
Internationalization projects are a popular function to outsource. You
provide code to them. They return product. Do you trust them to do their own
testing, too? They can have as many groups as they want, and you can have
whatever process you want, but you're essentially trusting the 'third party
group' to test and approve their own code. If anything, you should hire a
second third-party to test the translations. Sending a Korean product to
China because your third party became too complacent with itself does not go
over well. These things happen internally all the time too.

I'm just advocating that some sort of soft buffer be in place between
engineering and testing bodies to minimize the temptation to introduce rogue
code into a product. A good start is to not have them answer to the same
(immediate) authority.


-----Original Message-----
From: Ivey, William [mailto:william_ivey at bmc.com] 
Sent: Tuesday, June 15, 2004 11:57 AM
To: perforce-user at perforce.com
Subject: RE: [p4] Which dept for build/release engineers?

> -----Original Message-----
> From: Janulewicz, Matthew [mailto:mjanulew at alarismed.com]
> It's probably just my personality and the fact that I've been 
> burned by this
> kind of thing in the past. It does have to do with process 
> enforcement,
> authority, etc., but I've been victimized countless times by 
> testers that
> want a certain fix in a build for whatever reason, one that is not a
> requirement and not part of the design, and the engineer 
> provides it to them. It promptly breaks everything.

That's a failure in the process and has nothing to do with
the proximity of the testers. The same thing happens when
the testers are on a separate floor if they and the
engineers decide to ignore the system.

In my case, "our" testers always submitted change requests
for review (with the exception of the occasional stupid
mistake - such as giving them the wrong media).

And no one said every team member has to be part of the
same department. In fact, these weren't, they were
attached to our team for the project. (And their career
advancement was based on how bug-free the product was
when it went to final QA, so they had every incentive
to get it right and cover their rears with paperwork.)

perforce-user mailing list  -  perforce-user at perforce.com

More information about the perforce-user mailing list