For what seems hours, you scan the board. The colors are sharp against the
simple background. Some movement catches your eye, but it doesn't feel right,
so you ignore it. Time stretches on.
There! The perfect move. Leaving the perfect next move. A quick flick. A match.
The pieces fall into place. Another match. Another. Another. A special piece.
Another special piece. It fires, triggering more. Chaos consumes.
The board is in ruins. Your carefully planned next move is lost in the
destruction. You're back to scanning the board to try to find where you belong
in this new world.
Is this a game, or is it your development strategy?
Software development is chaos. Either you work to managing chaos, consuming it,
or it works on consuming you. There are too many possibilities, too much input,
to brute-force your way to completion (how much software do you know of that
can be considered complete?).
In the face of these possibilities, a rigid development plan will fail. Vague
goals are better. Goals written in terms of a problem are best. Problems don't
change, once you find their roots.
I didn't know this post was going to be about Agile, but there it is.
Exact is for computers. We are not computers. We are human. We are chaos.
The past me is another person. Sometimes antagonist, sometimes friend, past me
(postaction?) had ideas, hopes, and dreams and developed some of them into
software that I and others use. Unfortunately, that asshole left bugs all
through the code for me to fix.
I can't blame him. Nobody's perfect, not even idealized/demonized copies of my
past self. But I do have to fix them, and deal with the messes he left.
Lucky for me, while he was writing buggy software, he left extensive notes for
me to use...
Continue reading Leaving Crumb Trails -- Talking to Myself...
My job at Bank of America consists largely of data collection and storage. To
collect data in Perl, I have to write XS modules to interface with the
vendor-supplied native libraries. Because I want to know my code works, my XS
modules come with robust test suites, testing that everything works correctly.
Since the XS module was intended to be used by other, larger systems, I decided
to help those larger systems test their dependency on my module: I included a
Test::MockObject that mocked
my module's interface. By using my test module, the tests can try some data and
see if their code works.
But the hardest part to test is always the failures. How do they test if the
news service goes down in the middle of a data pull? How about if it goes down
between data pulls but still inside the same process? How do they test if the
user has input an invalid ID for data?
Continue reading Testing is a Feature of Your Service...
How often have I told myself, "I'll kludge this now and rewrite it later"? And
how many times did I actually go back and rewrite that kludgy bit? "Too often"
and "not enough". Many job postings include the phrase "update legacy
applications," as a euphemism for "rewrite poorly-designed spaghetti." The Y2K
problem was a huge exercise in code out-living the developer's plan, with a
healthy dose of cargo-culting thrown in. Lately, I've been learning to plan for
a likely possibility: My code will survive to haunt my bug lists and my resume
for a long time.
Continue reading Chicago.PM - Beyond grep - Expanding the Programmer Toolset...