Process improvement on the sly
by Andy Lester
I spend a lot of time in the pulpit of automated testing, talking about the benefits of writing tests for your code, in effect creating your own guardian angels. At a
Chicago Perl Mongers meeting where I preached the gospel of testing, someone said "That's great, Andy, but I can't do this. How do I convince my boss that this is a good idea?" The short answer: you often don't need to.
The number of tools available to us in our toolboxes is amazing, and you can usually make great use of them, even if you're the only one using them. You can set up macros in vim or emacs to make life easier for your fingers. Create shell scripts in your own ~/bin directory to speed repetitive tasks. Use CVS to keep track of changes to your files, even if you're the only one in the shop. Check your web pages, especially those dynamically generated, for syntactic errors with
weblint or any of the online checkers. Set up automated tests on your code, even if you're the only one on the project who's doing so.
Acting as the one-person prototype also means that you've got real-world experience with the process that you're pushing. Maybe you find that CVS doesn't do all your department needs, and you need subversion instead.
Better to find out after your own experimenting, rather than after it's implemented across the department.
Improvements under the radar mean immediate results, whether good or bad, without the endless meetings and discussions of how things should be. Far better to show your boss or departmental peers something that actually works than to talk endlessly about what might work.
Whatever your idea, try it. Play around. Maybe it's not the best practice, but you won't know until you try. Once you have some success, whether it's taken the drudgery out of a tedious build process, or had a bug found by an automated test, show it off. In the words of the great Bobbie Flekman, "Money talks, and BS walks," and we PHBs always like the sound of money.
What have you done to improve the quality of your coding life? Was it under the radar? How did you approach it?
Under the radar resources
I work at a university where we have the luxury of student assistants who sometimes have lulls between assignments. I keep a short list of these "when I have time" automation tasks and when I know a student is available, I give it to them on the sly for their down time.