Re: [fw-wiz] tunnel vs open a hole
From: Mike Frantzen (firstname.lastname@example.org)
From: Mike Frantzen <email@example.com> To: "Marcus J. Ranum" <firstname.lastname@example.org> Date: Wed, 9 Apr 2003 22:42:26 -0400
> The last time I was managing a bunch of software engineers, I bought 2
> licensed copies of CodeCenter (a terrific tool literally worth its
> weight in gold) and 2 copies of Purify. Nobody ever used them except
> me and, I think, one other guy a couple times. I guess, as
> "management" I failed because I simply expected that engineers would
> be professional enough to care? No, that doesn't wash - the bottom
> line was that some of the engineers I've worked with (so called
> "software engineers") didn't even know how to use a debugger because
> they thought that using printf()s was "faster" and they were on a
> tight schedule and didn't have time to learn gdb... I'm sorry, but
> that, to me, is not professionalism. Managers have to demand it, and
> have to support their engineers in taking the extra time to use the
> tools and follow the procedures to write rock-solid code. And they
> have to be able to help control executive's expectations as to
> schedules. Everyone, across the board, has to do their job right.
As someone who worked within floor shaking distance of Marcus' office
music, I'll add another perspective. When we were first looking at the
Rationale and Rationale like tools, we would have had to deal with
the "process" and the pointy hairs (not that Marcus has pointy hair
unless he's resorted to hair gel recently) to get something purchased.
It turned out to be easier to spend two days to hack up a malloc() and
family replacement that does the detection of memory problems (usage
after free was a bitch since not every OS is POSIX compliant w.r.t the
siginfo_t fault address). Automatically link it in and run the entire
regression testsuite with full diagnostics every night.
Lesson learned, just do it right. If it isn't going to impact the
schedule, don't bother letting it perculate up too far through
management since it can often result in more time in meetings
(scheduling, reviews, APIs, documentation, blah blah) than
Second lesson we didn't learn the hard way, don't let upper management
know about any automated regression testing. Getting a few weeks
straight of failures is common during the initial development phase of a
project. Having to explain that the code "isn't even alpha grade, leave
me alone", detracts from the heads-down development phase -- I'm only
comin up for air and alcohol so you better be handin me a beer.
The other reason not to widely disseminate knowledge about an automated
regression testsuite is to keep the QA dept honest. There is no use in
them running the exact same tests the developers ran.
Hi Marcus. Now that you're no longer our "boss", I guess we don't have
to worry about you suddenly sprouting pointy hair ;-) Don't go spillin
the beans now.
frantzen@(nfr.com | cvs.openbsd.org | w4g.org)
firewall-wizards mailing list