Velocity Multipliers

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.

Software Craftsmanship Vs The Iron Triangle: Cut Scope, Not Quality

"You can have it fast, cheap, or good.  Pick two."

This phrase is all too familiar to anyone who's spent any amount of time in software development.  For those who might not have heard of this phrase, it's a layperson's way of talking about the Iron Triangle of project management, which describes the constraints that every project must operate under.  These constraints are scope, schedule and cost, where scope is the requested functionality and features the system should provide, and schedule and cost are time and money, which are obviously not unlimited.

The Iron Triangle

Creating balance between these three constraints can make or break any given project, and while literal reams of articles and books have been written on the subject not much has been said regarding how software craftsmanship fits in (hint: often poorly).  This is unfortunate because life in this modern age is increasingly dependent on technology and the software that is directing it. Making decisions which allow low-quality, defect-ridden code out into the wild will have an equally increasingly costly and dramatic effect on an increasingly large number of people.  It follows then that software craftsmanship will become increasingly important to insure that high-quality, defect-free code is released instead.

Having said this I believe it is important to reflect on where software craftsmanship fits into the Iron Triangle.  As a craftsman I don't believe that quality should be sacrificed simply for the sake of expediency.  I believe that if code is to be written it should be written well.  It should be well-tested (Test-Driven!), follow good design principles, and be maintainable among other things.

This stance is not unreasonable, it is in fact the only truly reasonable approach in an industry which can have such a tremendous impact on millions of lives.

To take it out of the terminology of software development and into construction, no one ever goes to the general contractor and says "I can't afford a well-built mansion.  How about you still build me the mansion and just use cheap materials and work overtime to get the job done?"  If they did they the contractor would discretely laugh at the would-be mansion owner and suggest that they instead build a smaller house.

Unfortunately, if you find yourself in a situation where craftsmanship is at odds with the (ever-shifting) constraints of scope, schedule and cost you'll quickly find that the organization's appreciation for well-crafted, maintainable and incrementally delivered code will often take a backseat to cost-cutting, corner-cutting and a "Just ship it!" approach.

Knowing how organizations react when confronted with the choice between supporting well-crafted code and the need to simply ship something we, as craftspeople, should strive to truly understand what the organizations goals and constraints for a project are, and be ready offer approaches which don't call on us to sacrifice the quality of the software.

Let's get back to the "fast, good, cheap" quote I first mentioned and see how craftsmanship fits into each of the scenarios.

Fast and Good

Under the right conditions craftsmanship can thrive in this category.  If the scope is reasonable and the organization has the budget to support a team of knowledgeable craftspeople then a lot can get done quickly.  Obviously there are a lot more factors involved in the success for any project, but a highly motivated and experienced team can crank through an amazing amount of features.

On the other hand, if the scope is outrageous (which, lets be honest, is the more common case) or the budget can't support a team of experienced developers then the level of craftsmanship on the project is at risk.  The business may be tempted to say "All that unit testing you're doing is taking too long, can't we just skip that?", or simple budgetary concerns may cause them to under-staff the project.  Countering these two possibilities from the craftsmanship angle may involve suggesting cutting scope to deliver value while staying within budget, and delivering incrementally to give them something to get their hands on early in the process. 

Fast and Cheap

This is is dangerous territory for a craftsperson.  If the organization wants it done now and they don't want to pay a lot for it then by default they're not really concerned with the quality of the software.  They're concerned with ramming through the project and delivering something. High cost doesn't necessarily equate to a high degree of craftsmanship, but they often go hand-in-hand.  Again, as craftspeople we shouldn't be willing to sacrifice quality just to ship something.  The play here is to cut scope again if possible, and if that doesn't work then you may need to consider walking away from the project (a difficult decision to make in many cases).

Cheap and Good

This is an odd scenario to be in, as it implies that the organization wants it done well and inexpensively, but that it's OK for the project to take longer.  The "taking longer" part doesn't normally equate to inexpensive, as the longer the project runs the more expensive it will be.  If the timeline is fixed (as most projects are), then this scenario implies that the organization can't afford a team of craftspeople to tackle the problem, which places us squarely back in "Fast and Cheap" category.  Again, cutting scope, not quality, and delivering incrementally should be explored as options.

---

Convincing the organization to accept a reduced scope on a realistic timeline with a realistic budget is hardly ever an easy sell.  Often organizations are unable to fathom why what they're asking for is nigh-impossible and will instead push to either rush the project or ask that it be done on a shoestring budget.  Nevertheless, it is up to craftspeople to offer alternative solutions and to refuse to sacrifice quality in the face of adversity.  To those craftspeople who are facing this dilemma I say this: Good luck and stand firm!