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.

2 Comments »

  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





SERVICES
SOFTWARE SOLUTIONS
I have over 10 years of software development experience on several different platforms (mostly Ruby and .NET). 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.
PROJECT LEADERSHIP
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.
AGILE COACHING
I believe that Agile processes and tools should be applied with common sense. I've spent the last 6 years working on Agile projects as a consultant in many different environments, both in leadership roles and as a practitioner doing the work. I can help you find out how Agile can work best in your organization, not just apply a prescriptive process.
TEST DRIVEN DEVELOPMENT TRAINING
TDD Boot Camp is a hands-on, three day, comprehensive training course that will teach you all of the skills, tools, frameworks that you will need to use test-driven development to develop real world .NET applications. If you're not looking for something that intensive, check out the the half-day version.
Have any questions? Contact me for more information.
PRESENTATIONS
The Business of You: 10 Steps For Running Your Career Like a Business
From CONDG 2012, Stir Trek 2014
From Stir Trek 2013, DogFoodCon 2013
From Stir Trek 2012, QA or the Highway 2014
(presented with Brandon Childers, Chris Hoover, Laurel Odronic, and Lan Bloch from IGS Energy) from Path to Agility 2012
(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