Re: Debugging in the large, modern practice?

Hugh Sasse wrote:

> I clearly need to find out what IDEs exist for Ruby under
> Unix/Cygwin, and what they'll do for me.  I mainly use vim,
> but then I suspect that I'm "so amazingly primative that [I]
> still think [syntax highlighting is] a pretty neat idea".  I will 
> need to be able to configure any such IDE for large print, and
> light text on dark, which will be a factor in what I choose.

On Linux, and probably other UNIX-like operating systems, FreeRide is
available. I don't know if FreeRide will run under CygWin, but the
Windows One-Click installer contains a native Windows version of
FreeRide. Most of the folks here who run Ruby on Windows don't like the
CygWin version of Ruby, although if you want to run C extensions, it's
probably still a bit more convenient. In any event, I've had pretty good
luck mixing native Windows tools with CygWin -- if there's an equivalent
in CygWin, you usually have to do things with your path, but that's
about it.

> I am the team.  I'd love to be able to code-review this stuff with 
> others here, but there's only me.  So if it won't fit in my head
> then....

Well ... knowledge is meant to be shared ... teach someone Rails :).
> 
> Yes, I've read this sort of thing in The Mythical Man Month, but I'm
> wondering about all the tech I don't know about.  For example, much
> of XP seemed to be established practice that I didn't know about
> until I found out about RUnit circa 2001.  So since all these other
> fields I mentioned have progressed, it seems more likely that stuff
> has passed me by than that it doesn't exist yet.  I don't understand
> Aspect Oriented Programming yet, for example.

Or generative programming, or domain engineering, or domain specific
languages or language workbenches. Oh, yeah ... design by contract ...
proving programs correct ... the list is endless.

I'll claim (again) that the two most important factors in programmer
productivity are detailed knowledge of the application domain and
*familiarity* with the syntax and semantics of the programming language
and other development tools. A *bad* environment can destroy
productivity, but a good one doesn't guarantee it -- you need an
acceptable to good environment and detailed familiarity with it.
> 
> Some have it thrust upon them.  I feel like someone with a spade,
> who's thinking,  "They've got steamrollers and cranes, there must
> be mechanical diggers by now".

I suspect an IDE is the closest to a mechanical digger.

> 
>> career but found it unsatisfying. If you *don't* want to debug large
>> chunks of other peoples' code, there are ways you can structure your
>> team and processes to minimize how much of it you have to do.
> 
> Is that, 'for large values of "team"', only?

Well ... more like large values of budget, I think. :)

>> At the point in my career when I was at the peak of my ability to debug
>> other peoples' code, I came up with a simple rule. You'll probably need
>> to adjust the time scales to suit your situation, but in my case, the
>> rule was: If I don't find the problem in one day, it's not my mistake,
>> but a mistake in someone else's work. And if it takes more than a week,
>> it's not a software problem, it's a hardware problem. :)
> I probably need to use the tools more effectively for this case, to 
> reach those values.

In my case, the product in question was a smallish operating system
which shall remain nameless. The tools were an assembler, documentation
of the OS table structure and core dumps. There was in fact a "kernel
debugger" but I rarely used it -- it was too risky on a live system. And
that was after having been to a training on the OS from the vendor and
two years of immersion in it at the assembly language level (this was BC
-- Before "C").