Sometimes the programs you are running aren't as fully featured as you need them to be. If it's your program, extend it to do work like you want it, the ad-hoc extensions will make it soon feel like a warm worn-in shoe. If it's not your program, and the missing feature is correctness, just fix your copy, and submit the fix to the author. Otherwise add the extra functionality outside, with an appropriate contraption. Here's a couple from me, based around pipes.
There is a belief, especially popular under university graduates with heads full of Noam Chomsky, in the inherent hierarchy of grammars, and there are people out there who think it's something that has to be followed. Obey the hierarchy, they tell you. I suggest you hear them out, learn what is there to be learned, and then reply, I didn't know there were any rules about this. Dear reader, you are my fellow human and I want you to be strong and empowered. I'm gonna show you how to parse XML with regular expressions, and then you can make your own choices.
The usual way to control a script's behaviour is to provide a config file or command line arguments at startup. Actually, it's also common to modify the script's code, typically after executing it and noticing it's not doing the right thing. Neither of these are very convenient when you are including the script somewhere else. This post is about the third way, its curious advantages, and how it's usually epically bad but sometimes it isn't.
This is going to be an introduction for programmers who don't know much bioinformatics, pretty much me before I started working on WormBase ParaSite. For something less ignorant, simplistic, and without swearwords, you could read Genome annotation: from sequence to biology (2001).
An externally facing application is tested before delivery to assure it meets expectations placed in it. Uncle Bob is sternly clear that you're really not doing a good job if you don't have an automated means of doing that. This of course assumes you care about the expectations people place in your software, but (even outside the commercial setting where people try to get others to pay for their work) disputing that assumption is only allowed in what my friend calls a "philosophical free-for-all" - perhaps you are the Rothko of coders demonstrating that software having to do something is just another assumption to be challenged, or another V the cloaked renegade directing an orchestra of humming fans and creaking CPUs.
When you're employed on a large software development project, you gotta write tests, maybe even before you write the code, and then you gotta submit pull requests, and there will be tools checking that you wrote enough tests, and that they pass. In a less hip but equally large environment, like a bank, you still you gotta run tests, and e.g. attach their results in a spreadsheet.
At Expression Atlas, I did some work on the experiment import pipeline. I could choose how many tests to write, and it wasn't typical to write tests, but I believe it's quite neat that I did.