We’re In This For The Money

(When I’m teaching and coaching, I have a number of themes that I discuss and that will show up somewhere in everything I do. Here’s the money theme, which I usually bring up at the earliest opportunity.)

Look, kids, we’re in this for the money.

Somehow you got the idea that TDD, pairing, micro-stepping, and refactoring are not about increasing your productivity.

It could be the misguided craftsmanship movement, who give you the excuse to say “we don’t have time for art.” Or maybe you heard it from nay-sayers who are against these notions from the get-go. Maybe you read stuff from the early days, when we still didn’t understand that internal quality was such a huge determinant of success. Or, worst of all, some of you heard it from people who are in favor of these ideas, but get lost in the thick of things and say stuff they really should know better than to say.

It doesn’t matter how you got the idea, though. The simple fact is it’s entirely untrue.

TDD is in every respect about increasing software development productivity.

It is not about craftsmanship or art or beauty.

It is not about being a good citizen.

It is not about taking some illusory long view instead of the short.

It is not about you being a better person.

It’s not about improving quality.

It’s about money.

Do you want to make more money? Does your company want to make more money?

There are various goals you could aim at to do that. Maybe you need to ship more quality. Maybe you need lots more features. Maybe you need a whole new approach to the problem.

Funny thing, though. No matter what your target is, or even what time-scale it lives in, you will get there faster if you are more productive.

Driving with microtests increases productivity.

The microtests do a number of things to make us faster. See my articles on how TDD works its magic, for the many cases:

  • They multiply developer intentions, which provides a powerful “online” memory.
  • They demonstrate with a flick of the wrist that a change you just made did not hurt anything.
  • Their blinding speed far exceeds any other means of feedback in utility.
  • They *force* us to work in small objects with small methods.

In a single phrase? TDD increases productivity because the hard part of programming is thinking, and they make thinking faster.

Pairing increases productivity.

This one’s been demonstrated so many times its not funny. Pairing — at a real pairing station — has the following impacts on productivity:

  • Pairs find dumb-assed syntax errors faster than solos.
  • Pairs find *shared* language for programmer intention, the most subtle and elusive part of the primary task of programming, which is understanding the code in front of you at a  glance.
  • Pairs share energy back and forth, which means they can focus on a single task for far longer than solos.
  • Pairs are more fun. (Okay, that’s not about productivity. Fine.)
  • Pairing is the most efficient mechanism for knowledge transfer.

In a single phrase? Pairing increases productivity because the hard part of programming is thinking, and they make the thinking go faster.

Refactoring increases productivity.

The reason this one’s so hard for the noobs to get is that they haven’t yet understood that the code-to-which-you-are-adding is the single biggest determinant of the speed with which you add. Continuous micro-refactoring provides these benefits to productivity:

  • They render the code-base smaller. Smaller = less to grasp. Less to grasp = faster to change.
  • They reveal intention, which is the hardest part of code-grasping. Not, “what does this code do”, but “why do we want this code to do this”.
  • They continuously improve the overall design, including performance, of the code.

So, you know, in a single phrase? Refactoring increases productivity because the hard part of programming is the thinking, and they make the thinking go faster.

Micro-stepping increases productivity.

We do all of our work, testing, designing, refactoring, really *everything*, guided by one simple question: “what’s the smallest interesting step I can take?” And we do this because micro-steps improve our productivity in these ways:

  • They mean smaller scope, meaning fewer independent concepts, meaning easier reasoning.
  • They make most bugs emerge in those same small scopes. Time debugging is dramatically reduced.
  • They provide readily testable and trackable change. Continuous change is faster than chunky change.

Oh, in a single phrase? Micro-stepping increases productivity because the hard part of programming is the thinking, and micro-stepping makes the thinking go faster.

In The Beginning…

The only time these activities slow you down is in the beginning, when — guess what — you’re still learning their basic mechanics.

Here’s the deep dark secret: working this way is not how you learned to work. How you learned to work was either on-the-job-under-the-gun or buttressed around with perfectly reasonable theories that have no bearing on actual successful practice.

Learning to work this way is hardest for skilled geeks: they have a lot more practice to unlearn. But they’ll also have the biggest productivity gains once they get it.

Step Zero? Set up a decent comfortable pairing rig and invite experts to come and play. They’ll come. Pairing is the beginning, not the end, of this technique.

Learn Your Damned Trade

Too busy to TDD?

Too busy to pair?

Too busy to refactor?

Too busy to micro-test?

I call bullshit. My buddy Erik Meade calls it Stupid Busy, and I think that nails it pretty well. All you’re really saying is that you’re too busy to go faster.

We’re In This For The Money

So Stop Screwing Around And Start Going Faster

16 thoughts on “We’re In This For The Money

  1. Pingback: Estimating Blogs | Pearltrees

    • Ian…

      Hey, you noticed! This is the first time anywhere that I have mentioned microsteps in public, but it is rather lovely, yes? One of my other themes is what I call ‘tiny-ism’, and it’s all about micro-refactors, micro-tests, and micro-steps. Soon cutting a video on how to get your ‘stride-length’ right, and why it’s so important.

      • The second ones can also be claled the learning tests.Would you have access to third party source to even consider the code coverage.95% is high but how do you ensure you bring others in this journey in a diplomatic manner. Enforcement makes you enemies I found it the hard way.

    • Hi Dave!

      You are absolutely right. One of the things I often say to my teams: if what you’re doing isn’t fun, aside from the pain of first-time learning of course, then you’re likely not doing it right.

      Pairing is a blast. Green bars are a blast. Finally killing that horrific monster class is a blast.

      One of my three blobbie things (which are how I describe my basic stance to strangers), is Geek Joy. I don’t know everything that’s required to become an excellent software development team, but I know for damned sure that geek joy is one of the pieces.

    • Dan…

      I bet you have a user group, and I bet there are at least a couple of people with a broad range of expertise in your language/environment. Ask them to come pair with you for a half-day a week. You might be surprised how many folks will answer “sure!”. Scheduling can be hard, though, so you may have to do something like have a half-day in an evening, where people on your team blow off the morning and plan ahead to stay until 9. Offer food bribes.

      You can also get major players, of course, and many of them will give you a talk or even a whole day, for nothing more than the cost of getting them there and feeding them.

      Most of us *believe*, and believers will go a long way to share their joy.

        • Sure, I’d say there are two cases where you might write tests against third-party code: – you don’t trust it, or – you don’t undsnetard it. I’ve done the first for services that were developed specifically for one of our apps. So I wrote tests that verified various user stories. While I happened to write them using the same tools I use for unit testing, these are really acceptance tests written by the customer of the services (me). The second I would call exploratory testing. Basically, the purpose isn’t to verify, but to reveal: If I call this, then that, what do I get?

      • Hi Basil,Interesting read. I think your logic is sound, but you are missing the boat when it comes to acromyns. What on earth is a UUM or UUMR? Clearly a cool sounding acronym is needed! I suggest replacing Use Understood Methods (UUM) with Apply Reliable Methods Only Rule (ARMOR). It is a fitting acronym because you are protecting yourself from bad code. =)Justin

    • Open-source that’s not distributed in birany form (so you’d build it yourself) would be included in code coverage, unless you exclude it. And that’s what I do.As you say, enforcement doesn’t work. I try to lead by example. It takes patience, because you have to establish a history of good deliveries before you’re take seriously.

  2. Pretty nice post. I just stumbled upon your blog and
    wanted to say that I’ve really enjoyed browsing your blog posts.
    In any case I’ll be subscribing to your rss feed and I hope you write again soon!

    • It seems to me like there might be some benefit in writnig unit tests for third-party/open source code, for while you might not change the code, you might need to update to newer releases. If your code assumes certain semantics for that code and a new release changes the semantics, then there is a chance that your unit tests could detect this change. Just a thought.

  3. Nice post, thanks. Quite ufeusl. I heard about writing the tests first, but didn’t consider applying the same logic to legacy code. Unit testing does reduce the stress a lot, you can concentrate on one thing at a time, and feel less loss and entangled. MIT has great materials, I’ve found their Open Course Ware to be wonderful. Even the introductory programming course introduced the unit testing approach.I certainly hope you will keep up this blog!I myself am only an apprentice programmer, and that’s what I blog about. For now I’ve written about web and scripts, but will cover the fundamentals as well later on (algorithms etc.)Good blogging and programming!

  4. Great post! I refer to it often. In my experience, the biggest reason development teams “skip” craftsmanship is the business not understanding what is in it for them. The misunderstanding of putting pressure to deliver as fast as possible overshadows the concept of delivering fast by keeping the ease of making changes low over time. The business needs to go through the same paradigm shift as IT. They need to be enablers by behaving in a way that seems counter-intuitive to going fast.

    Yesterday, I posted an article on how to use Excel to demonstrate “craftsmanship” to the business first hand. Hopefull this helps illustrate the point. http://densom.blogspot.com/2015/01/demonstrating-software-craftsmanship-to.html

Leave a Reply

Your email address will not be published. Required fields are marked *