Focus on the Why, not the How

I’ve been mulling this post over for a year or more now, perhaps as long as two. I’ve started a number of drafts and thrown them out, dissatisfied with what had ended up on the screen. I’m tired of struggling to get it perfect, so I’m just tossing it out now. I’m not completely satisfied with what I’ve gotten done in this version, but here it is.

The crux of the debate with myself is an internal railing against the dogma I see in development methodologies and selection of toolsets/platforms/whatever. Too often I see good friends and industry leaders getting angry, condescending, outright insulting, (or a combination of all three) based on their preferred approach to software development.

Yes, I know. You may find this a surprising event in our chosen work domain. The software industry has never had these arguments before. Mere contradiction perhaps, but please, bear with me.

I’m tired of all the hot air around how we build software because too many people have, in my mind’s eye, lost sight of the why. Why do we develop software? To solve problems for the people who are paying us. Most of the time they don’t care how we do it.

Take the platform people develop on. A number of folks on Twitter throw out lines like “Why do great developers settle for platforms which aren’t Ruby?” or “Why are they choosing a bad technology instead of <x>?”

Focusing on the tooling or platform is focusing on the how, not the why of  building software.

The winner of a challenge at the first CodeMash conference won by solving the problem using a table in Microsoft Word, much to the chagrin of the other contestants who wrote a lot of code.

Ruby, Erlang, Clojure, etc. are all technologies we use to build systems on. They have nothing to do with why we build those systems. The software for the space shuttle is written in HAL/S, not Ruby, not Clojure, not some other cool platform of the day. Is that an inferior technology? Likely. So what?

How about the iPhone or iPad? The few iOS developers I talk with scream about the friction and pain they suffer on a daily basis because of the lousy tooling and awful platform issues. But look at why they’re working on that platform. My buddy and ex-colleague Joe Morel works at a company that’s won awards for their Rock and Roll Hall of Fame app. My good friend, muse, and also ex-colleague Leon builds amazing stuff that helps people collaborate on the iPhone and iPad.

They’re focused on why they’re building software and aren’t wrapped up in the arguments of how.

A similar line is dogma around TDD/BDD/whatever test-first methodology is being talked about today – and here is where my post will likely be misunderstood, misread, or flat taken out of context.

TDD/BDD/100% coverage is a how, not a why.

Software testing, at the unit, integration, or functional area, is critically important aspect of development. Software testing is something I’ve been passionate about for years, and have talked emphatically about for years.  Test-first development helps us design good architecture.  It gives us surety around behavior. It is an incredibly important line in the sand against regressions. Test-first development helps us evolve our skills to use the right patterns in the right places, and the right amount of abstraction.

Test-first development teaches us how to think critically because we’re forced to make decisions at a very minute, granular scope while paying attention to the larger impacts of those decisions. We’re learning critical thought as we move along that journey.

Unfortunately, some people carry the dogma to extremes and forego critical thought. (“Extreme dogma” is rather redundant. Sue me.)

An example: A pal of mine got to pair up with a well-known expert. The expert writes books, does training, speaks at conferences, and is extraordinarily influential and impactful on a great many people in our world, me included, and rightfully so.

They spent five hours ripping apart one specific view class to be able to get more tests around it. All the behaviors dependent on the view were tested in other areas of the test suite, but the expert felt compelled to get this particular aspect of the codebase completely covered in unit tests. I don’t know all the gory details of the view, but if you’re focusing on finding reasons how they could have succeeded, you’re missing the question of why they should have done it in the first place.

Five hours to try and get one class 100% covered with tests. They didn’t finish. Zero value was delivered to the customer. As a matter of fact, it was an opportunity cost that ended up causing my pal to miss finishing up his feature because he had to roll back a number of significant changes that were left unfinished.

That pair got wrapped up in the how of building software and lost sight of the why: delivering working software to the customer.

Another example of why hits very close to home for me: my diabetic gear. I turned in to a type 1 diabetic two years ago. At some point soon I’ll be dependent on an insulin pump to help keep me alive. Right now I use a blood test meter six to ten times a day, and I adjust my insulin doses based on that meter’s readout. If there’s a glitch with the meter I can overdose on my insulin and go in to a coma. Or die.

Scott Hansleman has a great post on his blog about the insulin pump and glucose meter he uses. He says his phone crashed twice the day he was writing that post. His meter and pump haven’t crashed in ten years.

Having worked in the embedded computing industry for a few years, I doubt the firmware in that gear was developed with any form of test-first methodology. It certainly wasn’t developed in any cool platform you’ve heard buzz about these last two years (unless you’re in the embedded industry).

Go read Agile Testing and pay close attention to the intro chapter where one of the authors talks about walking in to an ICU room where a loved one is hooked up to life-saving gear – and the author realizes she tested that equipment.

You want to tell me the folks in that industry aren’t great developers because they’re not doing *DD or working on some platform you’re enamored with? Two words: Fuck. You. Those people write amazing software that saves people’s lives. How’s that for an impactful why?

Now here’s where I finally get to the point I’ve wanted to make earlier but felt it necessary to first walk you through some over-the-top examples to help make my case. At least I didn’t go all Goodwin’s Law on you. Or make any Mom jokes.

The point is this: testing is critical for oh so many reasons, but it’s like scaffolding around a building under construction.[1] Apprentices and journeymen stoneworkers need that scaffolding and rely on it as they’re learning their craft. A master craftsman knows when he can do something without first standing up a bunch of scaffolding – but he’s making that decision based on years of getting it wrong and learning when he can do it right without the scaffolding. Darwinism may come in to play, too, since he’s obviously lived to know when he needs that scaffolding.

Another example would be the writings of Hemingway or e.e. cummings. Hemingway did insane things with his dialog, and cummings just decided he could throw out punctuation, grammar, and structure whenever he wanted to make a point. Both of them were masters at their craft, and both knew when they could move past the scaffolding they’d grown up with. You as an individual try getting away with that in your lit or comp classes and your instructor will most likely laugh you out of the room.

Testing is that scaffolding. Testing drives you to learn great design. Testing drives you to cut complexity. Testing drives you to learn how to build great software. But what do you do once you’ve learned how to do all that? Are you unable to write appropriate abstractions without tests? Are you unable to create loosely coupled designs that are simple and readable? And above all, are you unable to write software that is correct without tests?

Maybe, just maybe, you have gotten to the point where your experience has driven you to form great habits. Maybe, just maybe you can use your brain and look at your experience and skills – but with an honest, harsh eye – and figure out if you’re ready to move on past that point.  Maybe you can focus on why you’re building software, not how.

Am I saying stop testing tomorrow?

HELL NO. And I’ll call you a liar to your face if you say I did.

What I’m saying is use your brain. Figure out what’s right. Maybe testing is still the answer for you. Maybe some testing is the right answer. If there’s any question or self-doubt at all, then by all means continue your journey with tests to guide you.[2]

Whatever you do, think about the why of what you’re doing more than the how.

 

[1] A pal and I arrived at the example of scaffolding instead of training wheels after a number of very tasty beers at Spinozas. Scaffolding works much better for me because it’s much less diminutive than training wheels.

[2] Public Service Announcement: I will not give up writing tests any time soon. I have no doubt where I am on my personal development journey, and I’m nowhere near close to the level of mastery where I’d even consider going with out training wheels, much less scaffolding. Remember that if you ever pair with me.