go without saying, but the real reason most of us wind up in the pits of
cherry-picking is because we have
not been doing the real work of periodically merging whatever code we
are working against. We have let the
head of the tree, or the tip of the git,
or whatever trite phrase people might
want to use, get away from us, and the
longer we wait to do the merge, the
more pain we are going to suffer. The
best way to keep from being stuck in
the cherry orchard is to have a merged
and tested branch ready to go when it
is time for your project to resynchro-nize with the head of the development
tree. I know this is more work than
isolating yourself in a corner and just
working on the next release, but in
the end it will save you a lot of headaches. The question next time won’t
be, “When do I stop cherry-picking?”
but simply, “When is the new branch
ready to receive the work we have already done?”
KV
Dear KV,
Dear i Know,
Working on software is more than just
knowing in your gut that the code is
correct. In actuality, no part of working on software should be based on gut
feelings, because, after all, software is
supposed be a part of computer science, and science demands proof.
One of the problems I have with
the current crop of bug-tracking systems—and trust me, this is only one of
the problems I have with them—is that
they do not do a good job tracking the
work you have done to fix a bug. Most
bug trackers have many states a bug
can go through: new, open, analyzed,
When you approach
a problem, you
should do it in
a way that mirrors
the scientific method.
fixed, resolved, closed, and so forth,
but that is only part of the story of fixing a bug, or doing anything else with a
program of any size.
A program is an expression of some
sort of system that you, or a team, are
implementing by writing it down as
code. Because it is a system, one has to
have some way of reasoning about that
system. Many people will now leap up
and yell, “Type Systems!”, “Proofs!”,
and other things about which most
working programmers have no idea
and are not likely ever to come into
contact with. There is, however, a simpler way of approaching this problem
that does not depend on a fancy or esoteric programming language: use the
scientific method.
When you approach a problem, you
should do it in a way that mirrors the
scientific method. You probably have
an idea of what the problem is. Write
that down as your theory. A theory explains some observable facts about
the system. Based on your theory, you
develop one or more hypothesis about
the problem. A hypothesis is a testable
idea for solving the problem. The nice
thing about a hypothesis is that it is
either true or false, which works well
with our Boolean programmer brains:
either/or, black or white, true or false.
The key here is to write all of this
down. When I was young I never wrote
things down because I thought I could
keep them all in my head. But that was
nonsense; I could not keep them all in
my head, and I did not know the ones I
had forgotten until my boss at the time
asked me a question I could not answer. It is unsettling to realize you have
a dumb look on your face in response
to a question about something you are
working on.
Eventually I developed a system of
note taking that allowed me to make
this a bit easier. When I have a theory
about a problem, I create a note titled
THEORY, and write down my idea.
Under this, I write up all my tests
(which I call TEST, because like any
good programmer, I do not want to
keep typing HYPOTHESIS). The note-
taking system I currently use is Org
mode in Emacs, which lets you create
sequences that can be tied to hot keys,
allowing you to change labels quickly.
For bugs, I have labels called BUG,
ANALYZED, PATCHED, |, and FIXED,
while for hypotheses I have either
PROVEN or DISPROVEN.
Related articles
on queue.acm.org
Kode Vicious Bugs Out
George Neville-Neil
http://queue.acm.org/detail.cfm?id=1127862
Voyage in the Agile Memeplex
Philippe Kruchten
http://queue.acm.org/detail.cfm?id=1281893
ORM in Dynamic Languages
Chris Richardson
http://queue.acm.org/detail.cfm?id=1394140
George V. neville-neil ( kv@acm.org) is the proprietor of
neville-neil consulting and a member of the ACM Queue
editorial board. he works on networking and operating
systems code for fun and profit, teaches courses on
various programming-related subjects, and encourages
your comments, quips, and code snips pertaining to his
Communications column.