Development engineering

[Alex Martelli]

Cameron Laird <claird at lairds.us> wrote:
   ...
> Excellent developers, among other things, diagnose accurately
> and quickly; slightly less (I claim) differentiating is their
> creativity at remedies.

Yeah, debugging skill #1 is diagnosis -- fixes are easier, more often
than not.  Not too sure about the "excellent developer" generalization
in this context, tho.  The skills of, say: finding bugs; architecting
complex systems effectively; mastering some technologies (languages,
libraries, operating systems, protocols, existing algorithms in some
field, ...) thoroughly and effectively; designing pleasantly usable
languages, mini-languages, file formats, library interfaces, user
interfaces; inventing good new algorithms; etc, etc... ARE all
correlated to SOME extent, sure, but no more so, I think, than some of
them correlate with other skills not directly connected to the practice
of software development (crossword puzzles, ikebana, cooking...).


> I have a large, large theory that I summarize as, "Cut your
> losses".  The local application is that one big win for
> engineering productivity in software development is avoidance
> or management of those it-took-*months*-to-track-down-this-
> simple-problem situations.  I've sure lived through them; in
> fact, I'm dealing with three different ones that I know right
> now.
> 
> They are humbling, indeed.

Yeah, and avoiding or wisely managing them would be wonderful, but isn't
necessarily easy.  "KISS" is always helpful, of course: the more
helpings multitasking (of whatever kind, but "free-threading" issues are
the deucedest ones in my experience), distributed programming (...runs
away screaming...), even humble (ha!) event-driven programming, there
are in your system, the likelier that bugs will emerge that are very
hard to identify.  But we can't always be writing nicely simple
sequential programs -- we DO need to work with networks, GUIs, ...:-(

Abstraction cuts both ways -- great while it works, but sometimes bug
emerge that become horridly difficult to connect across huge gaps of
abstraction.  Eric Raymond has some wise comments about that (and
pointers to more such material) in his great book "Art of Unix
Programming".  Same for avoiding boilerplate coding and copy-and-paste
reuse -- such avoidance is an important bug-avoidance practice, BUT if
to pursue it you end up with highly generalized, parameterized, and
likely complicated procedures (or, worse, deep hierarchies of classes,
eek!) you may easily risk losing more than you gained.  Unit testing,
generous use of assertions, pair programming, and, to a far lesser
extent, "linting" and code inspections, all help a bit... but the race
condition, weird interaction of complicated frameworks, etc, will always
hit in the one spot which unit tests didn't exercise, that you didn't
think to assert anything about, and that looked just as good to your
programming partner, your linter, and all code inspectors...!-)

 
> I've lived through quite a few, as I just wrote.  I do *not*
> particularly associate their resolution, in my memories of
> first-hand experience, with debuggers.  Among other things,
> this makes me wonder if I'm missing out on the capabilities
> of debuggers.

This is a reflection I had as a consequence of this episode.  But if I
meet about two "super-horrible bugs" a year, and a perfect debugger
would save me 3 days or so in each case, I need to find one that I can
learn to use with perfect skill in less than 6 days, and keep
well-trained on at no cost.  Half the incantations that WingIDE guru was
incanting were completely lost on me and the other guy helping us out in
that debugging -- if I took a week to learn it, and then didn't have any
need for it for months, I'd have to relearn it again 7 months later...
not a net win.

I was highly skilled back when I had to use MS Visual Studio to develop
and debug C++ code -- but it's the kind of skill my brain expunges as
fast as it possibly can, as soon as it becomes unused (as opposed to,
say, weird interesting facts about languages and libraries I may not
have used for years -- THOSE, for me, tend to stay around somewhere in
my brain!-)


> I don't know what the answers are.  In this area, I'm still
> wrestling with what questions to ask.  This stuff *fascinates*
> me, though, in utter contrast to what I consider the utter
> irrelevancies of which editor to use, which ...

Of course -- the answer is so obvious (vim, what else?!) than debating
it _is_ utterly irrelevant...!-)


Alex