On Thu, 12 Oct 2006, M. Edward (Ed) Borasky wrote:

> A couple of questions:
> 
> 1. How large is "large"? Is there some kind of "code size metric" that
> the Ruby community uses, and a tool or tools to measure it?

Well, I'm trying to find out about techniques for use where
complexity and size are problem.  What is large for me may not
be large for others.  (I mean, there are some really sharp 
programmers on this list!)
> 
> 2. You say "your code". How much of this application have you personally
> written, how much is "Rails and Ruby and the rest of the
> infrastructure", and how much is "the rest of it"?

I have written all the stuff that is not rails or ruby libraries
out of stdlib.  And it took me a months to write, but under
pressure, so it probably needs rewriting in many places.
> 
        [Parallel history of debugging vs other CS stuff?]
> 
> The "traditional CASE tools" -- IDEs, software configuration and project
> management tool sets, the waterfall model, the CMM levels, and of course
> prayer, threats, outsourcing and pizza. :)

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.
> 
> > The experience I have gained seems to be insufficient to meet the
> > kinds of demands that cannot be unique to my situation, so there
> > must be better approaches out there already if others are meeting
> > such demands.
> 
> Again, without knowing both the scope of your specific project nor the
> size of the team that built/is building it, it's difficult to answer.

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....

> There are bazillions of failed silver bullets to choose from. My
> personal opinion is that you're being too hard on yourself and that
> anybody who claims to have a tool or a process or a programming language
> that is *significantly* better than today's common practices is either
> deceived, deceiving or both.

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.
> 
> > Given the prevalence of metaprogramming in Ruby, I'll phrase this
> > another way, as a meta-question: what are good questions to ask to
> > progress along the road of improving one's ability to debug large
> > systems?
> 
> I think first of all, you have to *want* to debug large chunks of other
> peoples' code. It's an acquired taste. I acquired it at one point in my

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".

> 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?
> 
> And I would caution you that, although testing and test-driven
> development are certainly important and worthwhile, testing can only
> show the *presence* of defects, not the absence of defects.

I know these ones are present, all right! :-)
> 
> 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.
> 
> Good luck ... may the source be with you. :)
> 
        Thank you,
        Hugh