07 December 2007

when good tests go bad

i'm glad it doesn't happen just to me. Martin Fowler(!) writes of the disrepair that his tests fall into once he and his team leave a system in the hands of a client. i have had the same experience many times. in fact, one of those times is the reason i always put quotes on "architect."

this "architect" created a fairly buggy, lousy, hack-ridden "framework" that my team and i were required to use, even though i had already written my own framework that was actually better (and somewhat tested). on this project, a couple of us started writing tests, especially around our function buckets designed to eliminate some of the bugs in the "framework." turn around and the "architect" had deleted all the tests. when pressed, he removed them because he didn't know what purpose they served and they didn't compile. i fell prey to the same fault that MF did: i didn't teach my "architect" the value of the tests.

how do you convince someone with yonks of "experience" that they suck at what they do?

1 comment:

  1. I have seen this with "architects" of real buildings on campus. They will insist on keeping "features" that they have been told will make it difficult/impossible to maintain that building after it's built. And by after, I mean within a few months of commission.

    I've also seen them implement an HVAC system that will utterly fail to heat and cool a building, even when running at max.

    It's tolerated because they're "architects", and the opposing parties are merely maintenance guys.