software solutions / project leadership / agile coaching and training

… but not all the time

Posted on September 6, 2012

I saw this in a job posting the other day, describing the work environment at the company:

We pair a lot, but not all the time. We test a lot, but not all the time. The key is being able to explain your practices with rational argument.

I love this. There are practices like testing that I hold in high regard, but nothing should be done all the time. As the posting says, “the key is being able to explain your practices with rational argument.”

Can you explain why you do something like TDD? That’s probably easy for you. But can you explain when you shouldn’t use that practice? That’s a little harder to do, and maybe because you’re holding onto some ideal that says you should test all the time or have 100% test coverage.

For every idea or practice that you find valuable, you should also be able to explain when it doesn’t apply. If you can’t explain when not to do it, I would say that you don’t really understand when and why you should use it.


  1. We have a similar philosophy where I work as well. We believe in having default patterns and practices, but we encourage people to apply critical thought to modify those patterns and practices to fit individual scenarios.

    In other words, we like to strongly adhere to PRINCIPLES [short feedback cycles, reduce cost of change] rather than PRACTICES [TDD, pairing, etc].

    This works well for us, and I’d venture that it works well for EdgeCase/New Context too.

    However, there is some risk. It’s sometimes hard to tell if you’re eschewing something because you truly have a good reason, or just because you THINK you have a good reason. For example, the team says “on this project, we decided not to TDD because [the tests are slow|take too long to write|etc]“. In some cases, those reasons are just manifestations of the team’s immaturity with a process or skill.

    My point is, the easier it is to do and the more comfortable a team is with avoiding recommended practices, the greater the risk that those practices are being avoided for the wrong reasons.

    In other words, when you explain when something doesn’t apply, make sure you’ve identified the TRUE reason! I find the “5 whys” technique is very illuminating when making these decisions!

    Seth Petry-Johnson — September 6, 2012 @ 10:41 am

  2. Sure there’s some risk, but that’s where you need to have good people. If you have A players, you can trust them to make the right decision, and their talent will shine as you set them free. If you have a mediocre team, they might not succeed because they need the extra guidance and structure, so you pretty much guarantee that you’re going to remain in mediocrity. This is just one example of why we need to get the wrong people off the bus and get the right people on the bus in the right seats.

    Jon Kruger — September 6, 2012 @ 9:56 pm

Leave a comment

I have over 15 years of software development experience on several different platforms (.NET, Ruby, JavaScript, SQL Server, and more). I recognize that software is expensive, so I'm always trying to find ways to speed up the software development process, but at the same time remembering that high quality is essential to building software that stands the test of time.
I have experience leading and architecting large Agile software projects and coordinating all aspects of a project's lifecycle. Whether you're looking for technical expertise or someone to lead all aspects of an Agile project, I have proven experience from multiple projects in different environments that can help make your project a success.
Every team and every situation is different, and I believe that processes and tools should be applied with common sense. I've spent the last 10+ years working on projects using Agile and Lean concepts in many different environments, both in leadership roles and as a practitioner doing the work. I can help you develop a process that works best in your organization, not just apply a prescriptive process.
Have any questions? Contact me for more information.
From Stir Trek 2017
Iteration Management - Your Key to Predictable Delivery
From Stir Trek 2016 and QA or the Highway 2015
From CodeMash 2016, QA or the Highway 2014, Stir Trek 2012
The Business of You: 10 Steps For Running Your Career Like a Business
From CodeMash 2015, Stir Trek 2014, CONDG 2012
From Stir Trek 2013, DogFoodCon 2013
(presented with Brandon Childers, Chris Hoover, Laurel Odronic, and Lan Bloch from IGS Energy) from Path to Agility 2012
From CodeMash 2012 and 2013
(presented with Paul Bahler and Kevin Chivington from IGS Energy)
From CodeMash 2011
An idea of how to make JavaScript testable, presented at Stir Trek 2011. The world of JavaScript frameworks has changed greatly since then, but I still agree with the concepts.
A description of how test-driven development works along with some hands-on examples.
From CodeMash 2010
From CodeMash 2010