On Thu, 12 Oct 2006, M. Edward (Ed) Borasky wrote:
A couple of questions:
- 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!)
- 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
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
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
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.