At a former job, we were working on a billing system implementation and were in crunch mode, with the deadline fast approaching. The project manager drew the last five days of the project on the whiteboard and divided each day into six four-hour segments. He then assigned each time slot to a team, based on the dependencies between teams. In the end, the development team was blessed with a 12:00 a.m.-4:00 a.m. slot to move the application to production.
Realizing that reasoning would not get us very far, we quickly invented a new task called "Final Code Config" that would have to be completed before the application was ready to be moved out. Based on our recommendation, the (clueless) project manager scheduled this task for the midnight-4:00 a.m. slot, so that the production switch-over could occur from 4:00 a.m.-8:00 a.m. We woke up at 7:30 a.m., dialed into the network from the hotel room, ran the deployment scripts and showed up at work at 10:00 a.m., pretending to have worked all night ...
Gregor Hohpe, Senior Architect
ThoughtWorks, San Francisco, Calif.
All Roads Lead to Rome
Three theories to explain three loco LOCs.
A few years ago, I volunteered to re-engineer a Microsoft Access front end. I was eager to get my first really big mission, but I soon realized that I would rather have signed a lifelong contract with the Foreign Legion. The day came when, while scrambling through the vast tangles of spaghetti code that so conveniently hide almost anywhere in Access, I discovered the three lines of code that changed my life as a programmer (or at least changed the way I view other programmers):
Forms!frmMain!txtValue.Enabled = False
Me.txtValue.Locked = True
Forms("frmMain").txtValue.Value = ""
Each line touches the same object in the same form, but is written completely differently. Why would any reasonable person do this? I've been haunted for years by this question, and have come up with three possible explanations for this bit of early extreme programming (extremely bad programming, that is):
- The conspiracy theory. Concerned about the Echelon worldwide spying system, the programmer wanted to obfuscate his intentions as much as possible. Indeed, no linguistic system could decipher this code, which looks and smells like Visual Basic, but uses the language in such an obscure way that it makes no sense at all.
- The archeological theory. Just as the seas that existed and vanished millions of years ago left layers of limestone and fossils, different programmers modified this procedure, each adding a layer of code—because they clearly could not understand the previous stratum.
- The schizophrenia theory. The programmer was suffering from advanced multiple personality disorder. As you can see, the personality switch was very fast: the first line written by Dr. Jekyll, the second one by Mr. Hyde, and the third—well, the third was by Mr. Anderson (who obviously took the wrong pill this time).
I'll let you choose the most appropriate answer. Someone less ingenuous than me might simply call this sabotage.
David Dossot, Software Engineer and Architect
Thionville, France
Misleading Metrics
Software stats can cause sneaky side effects.
Over the 25 years or so that
I've studied and used software metrics, I've been surprised and extremely distressed
by some of the negative effects that metrics have had on organizations. I can
picture Yoda telling us that applied software metrics, like the dark side of the
Force, may be seductive and powerful, but once we start down that path, forever
will it dominate our actions.
Here are three cases of abuse based on misguided metrics:
Defect Found/Fix Rates
Testers in one organization withheld defect reports
to befriend the developers who were under pressure to get the open defect count
down. Another maladaptive behavior was the creation of "pocket lists" of defects
by developers and testers.
Developers kept these unofficial lists of defects and action items to themselves. One manager went so far as to publicly criticize individuals for having more than five defects against their modules. That project, with 40 modules, now never has more than 200 defects reported, and seldom less than that. The pocket list was benign when it saved reporting problems observed and fixed in code—and a blatant fraud when it was a repository for existing problems that others were likely to encounter. Developers and testers are also capable of reporting and fixing large numbers of defects to create the appearance of a flurry of last-minute, prerelease activity. One incentive for this was the Dilbertian "bug bonus"—paying a bounty for the number of bugs fixed.
Tests Run and Passing
I've seen folks redefine what a "test" was in order to increase the passing
percentage. For example, one of 10 big tests that couldn't run looked much worse
than three of 100, so each big test was divided into sections. This extra work
made the numbers look more appealing, but did nothing to improve the tests or
product quality. Of course, it wasn't reasonable to punish a tester because
the code wasn't ready for testing. So, when management blamed the testing department
for not being able to run all their tests, those that couldn't run because of
missing product features were removed from the counts. This led to 100 percent
of tests running and 100 percent passing (the product is ready for release!),
even though some of the required features were missing. In another case, management
wouldn't let the testers reduce any counts of tests running, so they compromised
by replacing the expected good results with expected incorrect ones, so that
the tests could be run and passed (because we expected the error). Of course,
this guaranteed that future products would have the defect because fixing it
would cause the test to fail.
Code Quality via Defect Density
We needed an easy-to-use, unambiguous direct measure of code quality or defect
density, and calculated this by dividing the count of defect reports by the
lines of code (LOC). The result? Developers added or split lines to reduce density.
Days or weeks of work went into making code more verbose without changing what
it actually did. By adding more code statements without changing the number
of defects, density was reduced. This was particularly noticeable when the number
of lines of code was also used as a productivity measure. The most blatant example
I've seen came from an organization that included comments in their LOC counts.
When the first metrics were published, some developers were chided for having
greater-than-average defect densities. Almost overnight, the number of lines
of code doubled for the entire project, cutting the defect density in half.
Because of the sudden and dramatic change, we checked to see what changes had
been made—and found that almost all of the changes were added blank comment
lines.
Doug Hoffman
Software Quality Consultant, Speaker and Author
Software Quality Methods LLC., Saratoga, Calif.
Close Call
How I nearly hired a convicted cracker.
The Web developer job candidate called me about an hour before our planned interview
and said, "My court appointment took a little longer than I thought, so I'm
going to be about 20 minutes late. Is that OK?" Assuming that he was fighting
a traffic ticket, I answered, "No problem. How did things work out?" "Pretty
well—I got community service." I remember thinking that community service seemed
like a strange penalty for a traffic ticket, but it was a busy morning and I
brushed it off.
Later that morning, Chris, our office manager, stopped by my cubicle: "Your job candidate is waiting for you in the conference room." I noticed the hesitation in her voice. "What's wrong?" I asked. "Nothing, really; he's just a little, well, weird." "I'll see for myself," I thought.
The interview went reasonably well. The candidate definitely knew his stuff, answering a series of tough technical questions with alacrity. Furthermore, he had a feistiness that I found reassuring: I had no doubt he would deliver working applications. True, his appearance was unprepossessing at best: His longish gray hair was disheveled, and he was missing several teeth—but what of that? His ability to produce software was what mattered, and that was what I focused on.
The only relevant negative that I could muster up was the fact that he seemed to vacillate between wanting a job with my company and wanting to analyze our network security on behalf of his own, independent company.
I wanted another opinion, so I asked my boss to speak with him briefly. My boss was something of a stickler for professional appearance, so I cautioned, "His appearance is a little off-putting, but he's a smart guy." After the interview, my boss was less diplomatic: "He's strange, but if you think he's the right guy, hire him."
I told the candidate I'd get back to him soon, and took a few days to decide whether to make a formal job offer. I followed up on his references, which included a famous Silicon Valley entrepreneur. They checked out.
Two days later, just as I was putting an offer together, my boss walked into my office, laughing as he tossed a copy of the local newspaper onto my desk. There, in glaring black and white, was a prominent feature describing my candidate's checkered past. He hadn't been idle. Back in the '70s, this smart guy had cut his hacking teeth on Bell's telephone system and was eventually convicted for wire fraud. He was in and out of jail over the following years for continued hacking efforts, sometimes from inside jail. The article also noted his connections with some sympathetic computer celebrities—including the entrepreneur I'd called. I found more information in a casual search on the Web: Conducting a personal crusade against "the system," the candidate published an ongoing journal of his legal and hacking battles, as well as his attempts to get even with the phone company.
I should mention that our company was in financial services. Our clients—major banks and other financial institutions—would be a bit nonplussed to hear that we had hired a convicted felon with a vendetta. Later that day, I politely let the candidate know that we'd be hiring someone else.
John Reitano, Technical Editor
Software Development
Size Matters
Basic math was beyond these bigwigs.
Several years ago, three different teams were assigned to develop an algorithm
to solve a problem within a specified, short period of execution time. My team
succeeded in developing the most accurate and fastest solution. A few new specifications
were imposed—we met them. Then the project manager said that, because of
hardware memory restrictions, the code had to be less than 25KB in size. As
it happened, our executable was 19KB; the next-best program had an executable
size of 47KB. On the other hand, our source file was 103KB (with many comments)
and theirs was 80KB (almost zero comments). The other team knew the top guys
and convinced management that, based on source size, theirs was the smaller
program! Though we tried to convince management that the binary was all that
mattered, they were unswayed, and sent the inferior product to engineering in
the end.
Mukund Thapa, CEO
Optical Fusion Inc., Palo Alto, Calif.
