Quick and dirty scripts

Without getting too far into the specifics about the stuff I'm doing at work (random on-call stuff to fix problems that have cropped up in systems) one of the common tasks is to make a quick throw-away script that'll automate the work you're doing.But the problem is that if you're making a new script for every instance, you start to waste time making scripts.On the other hand if you're trying to architect the perfect script for your use case, you'll likely wind up with a broken architecture the next time you need to add a feature that's orthagonal to your design.There's always a fine line to walk between reusability and hackiness. It's a hard line to draw sometimes.After a while of living with the cruft that you've created you can maybe take a step back. You've explored the problem space for a while and can finally have a pretty good idea of what to write.And don't bother with the code reviews up front. They make things more expensive than needed -- alll you'll do is get everyone on the team to write their own scripts to not bother with code reviews. The code reviews will hold the crufty quick-and-dirty script to a higher architectural standard -- which I just said that it's not quite ready for.