I'd like you pause for a moment and think about the project you're currently working on.  What is the longest, most painful process in your workflow?  What is the step that, when you reach it, you say to yourself "Well, now I have to stop being productive while I do this."?

Really think about it.

All done?  Did you think you of some manual, repetitive step?  Did you think of your build?  Is it testing?  Is it your deployment process?  Is it an organizational process?  Did you think of more than one thing?  

Now, think about how your could reduce the amount of time it takes to accomplish this task. What impact would that have?  How much time could you save?  A few seconds? A few minutes? A few hours?  How much money could you save?  How much faster could you deliver value if you didn't have so many yaks to shave?

Whatever method you just thought of to reduce the required time for that task, that is a velocity multiplier.  Put another way, velocity multipliers are any practices, actions or processes that can be used to shorten the development feedback cycle.  They are the little hacks that have a big impact on productivity and the major practices that keep the project rolling along smoothly.  They are the tools that, after you start using them, make you wonder why you hadn't been using them all along.

Examples of Velocity Multipliers


Know Your Tools: If you are working with a particular set of tools then you should take the time to become intimately familiar with them.  Working in Linux?  Get to know Bash inside and out.  Using Intellij?  Learn all the shortcuts.  No matter what programming language you're working with take the time to learn everything you can about it.  Do these things not to simply know them for the sake of knowing, but to know how to use them well and how to use them quickly.

Maintain A Toolbox: Every craftsman has a toolbox that they maintain in order to let them do their job more efficiently.  This is just as true in software development as it is in any other trade. These tools often start out as one-off scripts that might one day become full-fledged applications and they end up paying dividends in the amount of time you save by re-using them.

For example, as a technical interviewer I'm often asked to conduct a pair-programming interview with candidates in which the candidate is asked to come prepared to write code in the language of their choice.  Frequently, and despite the candidates' best efforts, their environment is misconfigured and not in a state to write code.  I've come to expect this problem, and I now maintain a number of skeleton projects in my github account.  If a problem is encountered I simply pull down the appropriately skeleton on my machine and set up a new project so we can begin the coding exercise without further adieu.

Automate Repetitive Manual Tasks: How many times have you had to type the same long command or set of commands to accomplish a task?  Why not just write a script to do it for you?  This will 1.) save you time, and 2.) reduce the number of mistakes when performing the task.

As an example, in a previous role I was frequently asked to generate ad-hoc reports for my project manager.  I quickly discovered it was more efficient to keep the SQL scripts around for re-use later than to rewrite the scripts by hand every time the request came through.  These scripts saved me a ton of time and made my project manager very happy.

Optimize Your Build: This may take some work if you're dealing with a large codebase, but it is in the large codebases that you'll see the most gains.  First things first: kill the monolithic build.  If you have to build the entire codebase just to run a subset of tests your feedback loop is too long.  You should be able to run your unit tests almost instantly, and your integration tests nearly as fast.

A modularized build will not only allow you to build a subset of your code quickly, but it will also open the door to other optimizations, such as distributing the build across multiple nodes and running your tests in parallel.  Modularization will also help you to tease out dependencies, and to eventually starting breaking the codebase into several smaller, more manageable pieces.  Once this occurs it becomes much easier to have multiple teams working on the code at the same time without stepping on each other's toes.

These are just a few examples of how you can use velocity multipliers to reduce your feedback loops.  Each project is unique, and I'm sure that if you were to examine your workflow you could find optimizations just waiting to happen.  Often these optimizations are not realized because we think to ourselves "Sure, I could write a script to do that, but it would take a while to do and in the meantime X won't get done."  To this I reply with Nike's old stand-by: "Just do it." Whatever time you spend to save yourself time for the next N-infinity times doing it will be worth it.  Don't waste another minute, save yourself and your team hours.