The Dev Manager has a phrase that he uses from time to time when he wants to take some shaky code, perhaps lashed together for speed or an acute need, or prototyped as a script, or created as a demo, and bring it into the product.
Let’s make an honest woman out of that, he’ll say. The novelty of the unexpected anthropomorphism with a side of sexism soon wears off, although some of those kinds of projects can feel a lot like organising a wedding – expense, stress, unrealistic expectations, Mothers-in-law. (Go on, tell me you’ve never had a Ma-in-law on your project.)
What I’ve taken from it is the idea that I should always consider coding my quick-and-dirty investigative scripts with a view to making them part of a regression suite later. I don’t go that way every time. For instance, when I know it’s a stricly one-shot deal like processing log files to diagnose an issue, I’ll use whatever is fastest. And when I can get what I need inside an existing suite easily I’ll probably do that, although sometimes the overheads there are high.
When I’ve chosen to write outside a suite but I’m thinking of future incorporation I’ll try to match up against the suite on the following kinds of things:
- the language, framework, libraries
- any variable names (where they’re equivalent) or other coding conventions
- the structure of any data the tests use
- the way the tests are invoked
but only to the extent that I think it’s worth trading my main mission against later ease of migration. Or to put it another way, I like my dishonest women fast and my honest women cheap.