Process improvement on the sly

by Andy Lester

Software process improvement doesn't have to come only with the approval of the Pointy-Haired Bosses. There's plenty you can do on your own without telling anyone... until you show how well it works.


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?


1 Comments

cbrandt
2003-07-16 07:51:43
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.


Best part is, the PHBs found out about this and they now send programmers to me when there is a gap between projects because they know I'll have some improvement tasks on the back burner.


The trick is to keep the tasks small, clearly define your requirements, and have the coder document what they are doing so if the person has to drop the task, someone else can pick up on it later.