Failure. It seems we talk about it more than success in the startup world. Mark Evans suggested that in “Canada, unfortunately, failure is a four-letter word”. Our fear of failing here prevents us from reaching, from leaping, from succeeding.

Some other guy suggests that safety nets are for failing. The idea that allowing yourself the space for failure becomes a self fulfilling prophecy.

So which is it? We’re too skeered of failing or we’re too prepared to fail?

Here’s the rub. Until you accept that failure is a possibility, you’ll get nothing started but until you decide that failure is no longer an option, you’ll never succeed.

Step 1: Accept that failure is a likely and very real possibility. Focus on squeezing every last drip of learning out of every misstep.

Step 2: Decide that failure is no longer an option.

Another rub. There are very real rewards to failing that are attractive and appealing. Yes, rewards. Their appeal is strong, Dorthea Brande calls it the Will to Fail. For starters, having tried and failed allows to spend the rest of your days saying you tried…

“I had that idea”…..”Ya I had a startup but the timing wasn’t quite right”…..”I took a shot at it but I had the wrong cofounder”

Trying and failing keeps you from having to see what your idea looks like when executed on. Executing on a idea is ugly. It’s no longer a pretty, puffy dream with dollar signs, friendly customers and investors. It’s a real business that you had to white knuckle into submission. Chances are it was not pretty and it changed you as a person, not always in a good way. The difference between the finished work and that idea you had is often massive. Not having to ever see that difference is appealing. Leave me to my dreams please!

There are other rewards to failing, the point is that failure isn’t necessarily this ugly endpoint that you naturally navigate away from. It’s important that you consider what’s appealing to you in failing and what may actually attract you to it. You will never succeed until you choose that failure is impossible. Yes, it often is just that simple.

Ever since DHH’s keynote at Railsconf 2014 and his subsequent blog post TDD is dead. Long live testing., the development world (or at least the Ruby community) has been abuzz with thoughts on Test Driven Development (TDD). Uncle Bob, as well as a number of other influential members of the community, have jumped in to give their thoughts on the topic. I’ve listed some of these other posts at the bottom for further reading. I figured I may as well jump on the bandwagon myself, because hey, bandwagons are fun right?

One thing I’ve noticed about all of these posts, forum discussions, and tweets, is that there is a lot of focus on the speed of testing and the importance of decoupling. I must admit to being confused by this focus. TDD, as it was explained to me, is pretty simple:

1. Write a failing test
2. Write some code that passes the test
3. Refactor

Red, green, refactor. Notice how it doesn’t say anything about speed? Or whether the tests end up hitting the database? It doesn’t talk about loading Rails in order to run your tests, or the difference between stubs, fakes, and mocks. It just says three simple things: write a test for some new functionality, write some code to pass that test, and then refactor that code.

While many discussions have revolved around speed, DHH seems to also not agree with the test-first approach in general, because in Test induced design damage he criticizes BDD for being such an approach:

At this point BDD proponents might well argue that, yes, testing units is not what we should be doing. We should be going outside-in. But as long as that’s also done under the test-first regime, I don’t think it generally help matters much. It still leads down a road of excessive mocking and artificial boundary installations.

I don’t agree that the simple act of testing first needs to lead to excessive mocking. By itself, test-first says nothing about how I write my test, just when I write my test.

The point of testing first is to focus on the task at hand. What functionality am I implementing? Perhaps more importantly, what am I not implementing? Once I’ve figured out what I’m trying to do, I get there the quickest way I know how, and finally, refactor that code to something I’m happy with. It’s not unlike writing. Create an outline, write your first draft, and then polish it until you’re happy with it.

So where did all this preoccupation with speed and decoupling come from? Nothing in the steps I’ve talked about so far says whether 4.5 minutes for your test suite is too long or if times over one second are too slow.

However, Wikipedia does have a fuller outline of the steps than what I’ve presented in theirTest-driven development article. Let’s take a look (emphasis mine):

1. Add a test
2. Run all tests and see if the new one fails
3. Write some code
4. Run all tests
5. Refactor code

If you want to run all your tests every time you add a new one, you want them to be fast, otherwise they will just slow you down. But the fixation on what is the right amount of time is damaging the discussion. If DHH is fine with waiting 4.5 minutes for his test suite to run, who cares? I think it’s pretty awesome that he has thousands of assertions; most projects I see don’t have anything close to that.

DHH also makes a point in his post Slow database test fallacy about not running all your tests everytime you add a new one, and it is an approach I find reasonable:

I still wouldn’t want to wait 80 seconds every time I make a single change to my model, and want to test that. Of course not! Why on earth would you run your entire test harness for every single line change in a particular model? If you have so little confidence in the locality of your changes, the tests are indeed telling you that the system has overly high coupling.

Speed is important. If your tests are too slow to be useful, what’s the point of having them? What entails “fast enough” though, is something that is a matter of individual preference. It is also dependent on whether or not you agree with DHH about not running all of your tests all of the time. Faster is better, but I don’t believe in pursuing that at the expense of more important concerns, like writing the code that passes the tests.

Red, green, refactor is, to me, the core of TDD. Decoupled logic in my application is also good idea. If TDD helps me to get there, and decoupling also increases the speed of my tests, those are just bonuses on top of a process I already follow.

So why all the fighting and confusion over TDD? Well, Test Driven Development is just a name. Names are pretty useful things; they help us have discussions about rather complicated topics. If you know what Object Oriented Programming is, and I know what Object Oriented Programming is, we can have a discussion about it without having to stop to define every detail along the way*.

But names can also be harmful. If you “know” what Object Oriented Programming is, and I “know” what Object Oriented Programming is, but our understanding of those two things differs greatly, our discussion will be rather difficult and confusing to follow. We’re both assuming that the other has the same ideas in their head, which makes it hard to communicate effectively.

While reading Sandi Metz’s book Practical Objected Oriented Design in Ruby, I noticed something interesting about the way she writes. She doesn’t tell you what things are called until after she’s already shown you how to do it. You don’t have a chance to let your previous knowledge of those concepts get in the way. It’s a great way of explaining ideas that ensures everyone is on the same page.

So what does this have to do with TDD? Well, Test Driven Development is a name that means a lot of things to a lot of people. To me, it means red, green, refactor. Everything else just helps me do that better.

Maybe when we have discussions about TDD, we should be stating what our definition of TDD is. If we are all arguing about different ideas, perhaps we could find some common understanding and begin our discussion there. Our first test might fail, but we can figure out how to make it pass and refactor from there.

*Growing a language can be fun. If you haven’t already watched Growing a Language by Guy Steele, you should! It’s a great talk.

Related Reading

• TDD is dead. Long live testing. – DHH
• Test-induced design damage – DHH
• Slow database test fallacy – DHH
• Monogamous TDD – Uncle Bob
• Test Induced Design Damage? – Uncle Bob
• When TDD doesn’t work. – Uncle Bob
• Professionalism and TDD – Uncle Bob

Personally I’ve had a long standing policy to not respond to unsolicited Requests For Proposals, known as RFP’s. In the early days, I couldn’t give you a sound reason for my avoidance. I’m sure my main reason was that I didn’t feel confident I could craft a worthy response to your 64 page fancy-pants RFP with its budgets, timelines, stakeholders and other terms that had me reaching to wikipedia. Or maybe my gut was telling me to steer clear?

Eventually we tried responding to a few in earnest. While we’ve only done that a few times, the results have been consistent. We’ve earned 0% return on all our RFP work to date.

My policy to date remains that I don’t respond to unsolicited RFP’s unless I’m able to have direct conversations with the key stakeholders in the RFP process. Why? Simple, in some cases RFP’s are not what they appear to be. They are rarely a level playing field. Often decisions have already been made, or the vendors have been narrowed, and the RFP process is a corporate requirement intended to present the illusion of an unbiased process. That means you’re lucky if anyone even reads that response your team spent weeks or months crafting.

Even in the case of a truly open, democratic RFP process, it’s very premise is in direct contrast to how I tend to work. All of my best clients over the years have been relationship based. That means we courted each other first, we put time in, met each other, talked about our world views etc, maybe had a few drinks, shared some meals. Only after all that did we end up at “hey, we should work together”.

I’m not alone. Alan Armstrong of Eigenworks writes that “unsolicited RFPs can consume precious team energy, and our win rate is essentially zero.  I made the tough decision a long time ago to focus my team’s efforts on clients where our relationships are more direct”.

So here’s the rub. If your company is currently relying on RFP’s to find your vendors, you need to reconsider that approach. I can’t imagine that your company does NOT want strong vendor relationships. By choosing the RFP route to find and select vendors, you are immediately eliminating myself, Alan and a glut of other potential vendors who have all come to the conclusion that RFP’s are a waste of their team’s time.

Recently the company I work at, Boltmade, was undergoing a rebranding. Naturally we looked at the websites of other software development companies to see what they were saying about themselves. To me, one site stood out. 8th Light says in their company principles that, “we take responsibility for the correctness of our code by testing it thoroughly. We do not tolerate preventable defects”. Going further, the blog post that accompanies this says, “if we make a mistake, we’ll fix it quickly—for free. It’s that simple”.

What strikes me most about this is that it’s surprising at all. Why shouldn’t this just be how software development is done? Why do we just accept that all software will have bugs? It is true that is technically impossible to remove all possible bugs from a piece of software. But an over acceptance of this is leading us to create software with far more defects than should be acceptable.

It may be impossible to remove every final last bug, but if I’m doing my job correctly, I can guarantee that the things I know about will work. An article I read recently (Bug Free Software? Dream on) stresses the impossibility of getting rid of all bugs. In particular one phrase bothered me. The article says that “developers play whack-a-mole” with bugs. This bothers me because in that game, the moles come back out of the same hole some undetermined time after you knocked them down in the first place. In a way, it’s a perfect description of the experience of many developers. They fix one bug over here, rush to put out a fire over there, and when they come back they find that somehow the first bug has come back again. However, there is no reason developers should have to play this game. Proper testing should ensure that when you fix a bug it stays fixed.

The only way someone can deliver on their promise of bug free software is to test it thoroughly. I don’t really care if that means you clicked every path through the system, and tried every use case. If you’d rather do that over writing tests, be my guest. Just remember you’ll be doing it every time you change anything. As for me, I’ll write the tests once and have them catch things for me from then on.

So why don’t more people do this? Well, testing is hard. It takes time to learn how to test, it takes time to setup the tools to test, and it takes time to run the tests (much less time than it would to click through every path in the system, although I would argue that almost nobody actually does this when they say they tested it manually). But that doesn’t mean it’s not worth it. Investing the time in this area will pay off. But if you don’t make testing a priority, figure out how to set it up, and ensure that everyone is running the tests, you won’t see any benefit. It takes buy in from everyone. If one person is over in their corner diligently writing tests and nobody else does, you will still end up with a fragile application.

AirBnB just posted a great article about how they went from, in their words, “a handful of brittle tests to a large, resilient suite”. There are some good pointers in that post on how to achieve the same thing. To me, there were a few important things that stood out:

1. Change your culture to “make testing a first-class citizen”. As I mentioned, if nobody believes in it, it’s not going to happen.
2. Avoid the pattern of “we know tests are important, but we’re too busy to do it right now”. If it’s important, it’s important. Do it.
3. Make “the bar to writing tests…so low you can trip over it”. Make things easy and people will do them.
4. And finally: “The important thing is to test all the f***ing time. Even when it’s hard. Especially when it’s hard.”

So how do you know if you should be thinking about tests? To me, the test for if you need tests (or more tests), is how comfortable you feel pushing a new build to production. Does it make you hesitate? Do you cross your fingers hoping things will be ok? Do you always do it early in the day so you can be around in case something goes wrong? If so, then maybe considering getting some more tests in there. Deploying shouldn’t be a scary process.

I’m happy to hear your thoughts, please leave comments below! I could ramble on this topic for a while but I don’t want to write a huge wall of text. I’m happy to continue the discussion in the comments or write a follow up post.