Twice this week my team spent some time testing something that wasn't in the environment we were testing in.
It happened twice this week.
It had happened before.
It will never happen again.
Why? Because I did what I always do. I write a tool. I happened to call this tool “Dude, Where's my Code?”.
This little tool will allow you to put in the SVN (subversion) revision number of your check-in and tell your which environments have higher SVN revisions deployed to them.
I am not writing about this simple little tool though. A tool of this size can be thrown together in less than an hour. What I am writing about is the time this little silly tool will save.
Software development is about automation
So, shouldn't we automate software development? I've written about this topic before, saying every project should have a dedicated developer's tools team. I'll probably write about this topic again, it is that important. We spend a large amount of time doing the same thing over again in development and quality assurance activities. We don't notice it that much because our head is in the game, trying to complete the task at hand, but if someone were watching us from the outside, they would see the repeated processes. Not only would they see your personal repeated processes, but they would see that all the other developers on your team are doing the same things.
I have a general rule I like to follow, it goes something like this:
Do some tedious process once, I'm game.
Do some tedious process twice, I'm thinking about how to automate it.
Do some tedious process thrice, I created a new tool.
Some people I have worked with are annoyed by this. Some management I have been under has thought I am “playing around,” but almost always the tool gets used heavily and in the end everyone wonders how they could function without it. I'm not trying to toot my own horn here. The reason for this is not because I create awesome radical tools or that I am a super genius. (Neither of those is true.) The Reason is because I see a need and I fill that need. When you make people more efficient, you provide an exponential return on investment.
If you're not convinced here, let's break it down a little and think about how software, for the most part, is automation. Think about the last program you wrote. Was it written to automate some manual process? Most likely it was. And if it was, why? What was the benefit in automating that manual process? If you don't know the answer to that question, you might have a hard time selling your software or justifying its budget.
My point here is that if the very software you are creating is to automate a manual process because it will save money and make people doing “x activity” more productive, then how can you think it is okay to do the same tedious thing over and over again? There is a term for this. It is called “eating your own dog food.” The ultimate “eating your own dog food” as a software developer is automating your software development process.
READY… SET… AUTOMATE!
Now that you're all on-board with automating and writing good tools that will help you become more productive, you may be asking yourself “great, but what do I automate?” In my next post, I will cover some common areas that you might look for in your software development process that could benefit from automation.
“What's mine say”
“Dude!”
“What's mine say”
“Sweet!”
What's mine say”
“Dude!” …
