Feed on
Posts
Comments

I don’t know.  Sometimes I feel like some of these folks try too hard to soft-sell the excellent way presented by test-driven development (TDD) and pair programming (PP). A lot of alleged agilists make this argument:  you see, by PP’ing and TDDing, you will greatly increase your quality, so even though your productivity goes down, you get the coolest glow by knowing in your heart of hearts that you are a good citizen of the coding world.

I call bullshit.  Not only is it not true that you can trade internal quality for more features, it’s actually the exact opposite case:  the more productivity you seek, the higher you should raise your standard of internal quality.

That’s right, that’s what GeePaw says.  If you want more production, look first to raising your internal quality. So, how can such things be?

  1. Because internal quality and external quality are not the same things.
  2. Because the biggest single determinant in today’s production is the quality of yesterday’s production.
  3. Because typing is not now and never has been the bottleneck in writing code.

If you’re okay with those ideas, then move along, you’re good for today.  If you’re not okay, then follow me into the explanation of these facts.

Internal vs. External Quality

In software, there are two different types of quality, internal and external.  External quality is about the “saleability” of the software you’re making.  If there were a number to represent how many features you have, or whether those features are correct across the entire range of possible inputs, that number would be the external quality.  Now, notice, external quality can be traded for time-to-market. It’s not traded for productivity per se, but it’s a perfectly delightful way of hitting your ship-date.

Internal quality, on the other hand, is about the code.  If you have to have a number, think McCabe complexity, or something like Crap4J puts out.  It’s about crossing your t’s and dotting your i’s.  It’s merciless refactoring, delightful pairing, and using microtests to drive the code. I reiterate for the obtuse:  you can not go faster by shorting internal quality unless you are a noob.

Yesterday Determines Today

Do I really still need to rehearse this?  All day long, every time you make a move, you will be depending on the code that’s already there.  Every line of it you have to study will slow you down.  Every extra open dependency will slow you down.  Every bad variable name will slow you down. Every flawed design decision, be it big or small, will slow you down.

If you want to work as fast as you can, you want to work with clean code.  Period.

Typing Is Not The Bottleneck

The most common reaction to pairing and TDD is to suggest that they’ll really slow the team down.  It’s obvious, isn’t it?  If two people sit at one machine, that’s got to mean that we have 50% less hardware utilization, which has just got to hurt our production.  And don’t even get me started on the TDD: tests are code.  If I can only produce 100 lines of code a day, and you expect me to have that code driven by tests, you’re basically telling me to write just 50 lines of code and 50 lines of test.  So it could not possibly be the case that TDD and pairing will help my production.

Yes.  You’ve run rings around me logically.  Two people together can code as fast as two people separately because, get this, the hard part of coding isn’t the part where you type.  When people say they ‘coded’ all day, what do they really mean? They are usually saying they:

  • typed in code;
  • drew some pictures;
  • ran the debugger;
  • waited for the debugger;
  • figured out how to set the breakpoint so you got your failure case;
  • read 20-50 times more code than they wrote;
  • asked peers to look at a problem;
  • got asked by peers to look at a problem;
  • stared into space;
  • threw some kind of something at other people;
  • surfed the web looking for answers;
  • and so on…

Notice that writing code into the machine occupies only a very small portion of this list.  That’s because the hard part of programming is the thinking, not the typing.  Everything else on that list (except possibly the throwing stuff) is about thinking, not typing.

TDD increases your production because it serves as a thinking-aid.  It limits back-tracking and gold-plating  and it reduces code-study and debugging.  Pairing increases your production for the very same reason.  Two developers together don’t type as fast as two developers separately, but we don’t care: the  bottleneck is the thinking, and pairing and TDDing both improve it.

Conclusion

If you want to increase the productivity of your team, then do these three things:

  1. write a microtest that fails before you change any code;
  2. adopt a “no-pair no-keep” agreement;
  3. establish a shared understanding of internal quality.

Alright, then.  I’m glad we had this little talk.

Share

32 Responses to “How TDD and Pairing Increase Production”

  1. Lisa Crispin says:

    +1 on this excellent post. My current team is living proof of it.

    By focusing on writing the best quality software we can write, over the past five + years, we have been able to do more in less time. We aren’t overburdened with technical debt. We are slowly replacing the legacy code that’s hard to maintain.

    So if anyone wants to know if what GeePaw says really works, just ask anyone on my team!

  2. [...] This post was Twitted by davidwhite – Real-url.org [...]

  3. [...] blog posts (May 26/2009) Jump to Comments A good post for those who don’t quite get test-driven-development and pair programing, Mike Hill provides counter arguments to demonstrate why TDD and PP both work well in a development [...]

  4. Urs Enzler says:

    I completely agree but for your list what a developer does during a day.
    When using TDD the amount of time spent in the debugger is very very low. This is an advantage of TDD over “test-after-if-ever”. Debugging takes a lot of time, using TDD eliminates the need for debugging almost completely, because when it does not work as expected there is very little code that can be responsible for it.
    And of course, you don’t have to start your application, navigate to the dialog where your just implemented code will be invoked. You can just start your unit test. And therefore, once again TDD saves time!

    Cheers,
    Urs

    • GeePawHill says:

      I always feel unhappy when I start the debugger (since TTD). When I do, I try to always take it as a lesson-opportunity: once I find the problem, how might I have tested differently so that the failure would SCREAM out at me the moment I made it.

  5. [...] http://anarchycreek.com/2009/05/26/how-tdd-and-pairing-increase-production/          Uncategorized benefits, essays, from the trenches, pair programming, quality, tdd, test driven [...]

  6. Very nice post! i will take the arguments/facts with me and when bosses tries to break the PP because they whant do “optimize” the teams then i can show them this article and its arguments.

    Thanks :)

  7. I loved your post!!! It makes a lot of sense to me.
    I now fell reinvigorated to push for PP again :)

  8. Well put. Well said. … and how long will it take to do that? Hmm… how long does it take to catch a fish!

    Although one of the best pair programming experiences that I’ve had was with a person on the other side of the country. Let’s not forget the power of VOIP and Desktop shairing for PP! Great post.

  9. Jerome says:

    Pretty straightforward and radical, but actually so true it is almost embarrassing for the skepticals.

    Maybe for some projects it may take the right balance of plan driven and agility but in every places I worked so far PP and TDD were appropriate. It naturally leads to better quality that won’t hurt any project.

    I find that without TDD and refactoring, there is not much good design being done and it gets plain boring. At least, when the code is lean and covered by an harness we can move things around to get the design naturally evolving. I find that even on very short interrations, as short as 2 days, TDD helped me to finish faster.

    Thanks for the post!

  10. Stan Kurdziel says:

    I really like the differentiation between Internal and External quality. As a software developer, I agree with your conclusions. There may be some even more widely applicable conclusions here as well – that apply to everyone involved in software development. Managers, Users, etc:

    1. Quality is not an on/off switch. It is always possible to improve internal or external quality or to let it slip.
    2. Internal Quality is a worthwhile pursuit. Working on internal quality is one of the best ways to increase production of the software development team.

    There may even be a corollary available:
    * It’s impossible for Internal Quality to be completely isolated from External Quality. At some point during development on software with a lifecycle longer than a prototype, Internal Quality (positive or negative) will impact External Quality.

  11. As a tester, it’s not my business to tell people how to write programs or manage their teams. Yet I can assure you that the cleaner the code I get, the better test coverage I can obtain for you. Why? The answer is that it takes more time to (perform a test AND INVESTIGATE AND REPORT A PROBLEM) than to (perform a test). Typically many, many times longer. A program that has lots of problems in it means longer testing (assuming you’d like the same amount of test coverage), or reduced coverage (assuming you want to allocate the same time between the programmers’ declaration of “done” and release), or as is more typical, both longer testing AND reduced coverage.

    Conversely, a program that has fewer bugs can receive better test coverage in the same unit of time, or can ship earlier.

    Note that this discussion doesn’t even mention the amount of time required to fix the problems, which is also non-zero, or the delay imposed as the programmers and managers try to decide which bills to pay first in the great big pile of technical debt.

    http://www.developsense.com/presentations/FindingBugsVersusCoverage.pdf

    Cheers, Mike.

    —Michael B.

  12. MoisesDaniel says:

    If pair programming increase your productivity, why not three-developers per machine programming??
    It has no sense.
    Good programming is about good thinking. Think accurately about your code, and put in it assertions (design by contracts) and you will have a really increase of internal quality. Test your components, do carefully test for your functional requeriments. You don´t need to lost your time in big amounts of meaningless tests.
    Regards!

    • GeePawHill says:

      It’s absolutely true that you don’t need to lose time in big amounts of meaningless tests. “Meaningless” tests are not what microtests are. I don’t advocate *any* pro forma gestures, and certainly not pro forma gestures that would create meaningless tests.
      I think I’ll pull out a Ron Jeffries -ism: you may be smart enough to deliver good thinking and to validate that it’s good thinking through sheer power of mind. I am not. And most of our industry is not. You sound a little like someone who’s accepted the hyper-rationalist cant of traditional software development.

  13. ScottLock says:

    Meaninless tests? Even if you do “test-after-if-ever” you will be a better developer for it. There have been countless times where tests saved a developer ass. Learning the impact of change early is way less expensive than learning about it during a push to…well…anywhere.

    TDD gets a bad wrap for being “hard to implement”. I think that once a developer sees how you follow the TDD flow, then it is in fact easier for them to write code. Not only that but the code they write will be very high quality. Finally, if you put PP, SOLID principals, and TDD together you can have a very efficient team and high quality application.

  14. [...] "El Desarrollo guiado por Pruebas" y "Programación por pares" son dos de las más ampliamente conocidas prácticas ágiles, aunque no so muy practicadas por muchos equipos ágiles. A menudo, las personas dicen estar "demasiado ocupada" para adoptar tales prácticas; en esencia, abogan que trabajar por la calidad del código puede reducir la productividad. Mike Hill explica como esta lógica esta seriamente viciada. Mike nos dice, esencialmente, que uno debe "ir mejorando" si se busca  "ir más rápido": [...]

  15. Fredrik Klintebäck says:

    I’d rather think about run time quality vs design time quality, what you describe as external quality I don’t see as quality attributes at all.

    Run time quality are qualities that you can observe at run time, such as availability, performance, stability and such.
    Design time quality is about the code, such as testability, modifiability, portability etc.

    That said, I totally agree with the rest of the post.

    • Annette Neergaard-Möller says:

      Annette Neergaard-Möller=Annette Johansson=NDB
      Tjena.
      Att man skulle hitta dig bara sådär… Googlade tjänstehanterare och Klinteback-blogg-sogeti flipprade förbi. Kollade Sogeti/Umeå men hittade ingen e-mail så det fick bli lite mer Googlande på Klintebäck; Foto (jajemän, där var du. Tunnare hår annars samma Fredrik). Tillbaka i Umeå. Grattis till tre fina flickor (själv har jag två,4+9). Läste även ditt blogg-inlägg om 80-talet (kännde igen allt:-)). Projekt Heureka … får kolla mer sedan
      Har du någon annan e-post adress eller ska vi fortsätta träffas här?
      /Annette (fortfarande Boråsare)

  16. Alex Radzie says:

    I hate when people paint it all black and white, exaggerate facts and don’t make any assumptions. If you are writing unit tests and working in pairs, then you are good, otherwise you are doing it wrong.
    I call bullshit.
    Writing unit tests is mostly good, but not always.
    Working in pairs is mostly inappropriate, but sometimes it helps.
    If you are working on a routine tedious task, how pairing with someone else will help you?
    If you are engaged in heavy research and have to dig through a lot of documentation and code, will you do this together with a team mate on a single computer?
    This is exactly what I have been doing for the last few day — researching a third party framework and writing a prototype. And I am happy I made it alone an did not bother myself writing unit tests.

  17. [...] is something about Mike Hill’s article about “How TDD and pairing increases production” that resonated in me: “Typing is not the [...]

    • Kevlin Henney says:

      Nice to see my “typing is not the bottleneck” phrase beginning to catch on after all these years!

  18. Andrew G says:

    As for me unit testing is always good and if there is any facilities to do that I do. But sometimes is hard and not worthwhile to implement due to environment. What is really useless is pair programming all the time. You must acknowledge that there a lot simple and template tasks that are routine. Instead of doing pair all the time let’s have a lot of conversations on design issues. I don’t hate pair itself, furthermore I need it from time to time. But it’s twice hard to pair simple, template task.

    “If there are a lot of idle developers, introduce pair programming so it would looks like everybody at work “

  19. [...] How TDD and Pairing Increase Production Publié dans communication, informatique, organisation, réflexion, travail. Mots-clefs : accompagnement au changement, code, gain, productivité, qualité, serveur d’intégration, serveur de build, source. Aucun commentaire » [...]

  20. Keith Ray says:

    “If you are working on a routine tedious task, how pairing with someone else will help you?” — how about by automating that task, so it never has been tedious again?

    We’re using COMPUTERS! They were invented to replace tedious tasks!

    • Jack says:

      Good point. I always feel I’m doing something wrong if a task is “too easy to require pairing”. In my experience automating such tasks is often a fun/challenging task in itself. The result is an automated process and happy programmers :-)

  21. [...] never the bottleneck. Thinking is. Tests make development faster because they help to focus: “How TDD and Pairing Increase Production” and “They’re Called [...]

  22. Oliver says:

    I just worked two days in pair doing TDD and I think the code which came out was of a much better quality than if I would have done it all by myself. Even my coworker admitted today as he started to work alone again that he did not got into TDD all by himself, whereas working together, this was no problem at all.
    Of course, as always, you need to make sure pairing is the right approach for the problem (whereas TDD almost always is). Common sense.

  23. [...] in this post have been heavily inspired by GeePawHill (also known as American Mike Hill) ’s  How TDD and Pairing increase production. These diagrams were meant to follow mikes’ story. After they were done, another order [...]

  24. [...] Programmer.) If you really are as good at Agile Programming as Josh Kerievsky, or Ron Jeffries, or Mike Hill, or Naresh Jain, then yeah, I’m willing to have User-Story-specific discussions about [...]

AWSOM Powered