Monday, May 16, 2011

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.

Monday, May 02, 2011

Building Great Teams

UPDATE: I totally forgot one critical part of what I spoke on being a team leader – thankfully Dave Fancher’s summary of KalX reminded me.

Saturday at the Kalamazoo X Conference I gave a talk on building great teams. I did it sans slides, but wanted to follow that up with a blog post covering the points I hit during the talk – so here it is!

My 1991 Intramural Volleyball Championship Trophy

The trophy in this picture sits on the top shelf of my closet. I have a look at it frequently as a reminder of what a group of regular folks can do when they put their minds to it.

The trophy is from the 1991 Elmendorf Air Force Base Intramural Volleyball championships. At the time I was the player/coach of the 962 AWACS’s volleyball team. Our team wasn’t filled with the greatest athletes, but we played out of our brains and knocked off other teams that were filled with tremendous individual athletes.

That is the peak of any team experience I’ve been a part of because it continues to remind me that regular folks can do amazing things if they work to a common goal.

To me, all great teams are founded on three pillars: Respect, Great Communication, Passion. No team will work to its potential (or beyond!) if any of those three pillars is weak.

Everyone on a team has to keep those in mind, both individual members and leaders alike.

You as a Member of a Great Team

As a team member it’s your job to figure out how to make your team, not yourself, shine. Fall back to the three pillars and think about how you’re dealing with them.

Respect: Everyone’s got opinions. You’ve likely got a passle and you should feel free to raise ideas and suggestions, particularly in areas which may impact the success of the team. That said, think about how you’re throwing your ideas out to the rest of the team. Just because someone’s baby is ugly doesn’t mean you need to phrase it quite that way. Change “Your code sucks” to something helpful and easier to swallow, like “I bet if we pair up we can figure out a way to cut this method’s cyclomatic complexity from 352 down to something a bit more manageable as well as make it a bit more readable and testable.”

You also need to be able and let go of your own ego, particularly around your own ideas and opinions. Somewhere I heard the phrase “strong opinions, weakly held.”  I’ve always kept that to heart, because it’s particularly apt in our industry. I have extremely strong opinions on how to build great software: frameworks I favor, tools I use, methods on how to actually create software. I have those strong opinions because experience has proven these particular things help deliver great value.

I hold those opinions weakly: show me a better way and I’ll change in a snap. At the end of the day I’m in favor of anything that lets me spend more time on the couch playing XBox with my son or riding bikes with my daughter.

Communication: What are the team’s goals? Having difficulties with someone on your team? Stuck on a task, but aren’t stepping up to ask for help? Those all fall under Great Communication. You’re a part of your team’s communications ecosystem. [1] You need to step up to the plate and ensure you’re doing your part to keep that ecosystem healthy. It’s rarely easy to try and work out interpersonal issues with someone on your team. On occasion it blows up. You know what? Just because it’s hard doesn’t let you off the hook. Work hard at Great Communication because its benefits tremendously outweigh the effort it takes.

Passion: Get fired up about what you do. Yes, sometimes you have to suck it up and get that lipstick on a pig; that’s just a fact of business life. Offset those dreary periods with excitement about other things. Throw a lunch and learn on something interesting. Reach out to pair with someone you haven’t before. Look to learn something new. Share that excitement with others on your team.

You as the Leader of a Great Team

Do everything I just wrote about, but turn it up to 11 – and start with the respectful attitude with which you treat your team.

As a leader you can’t have the same sense of humor you do with peers. You’ve got to be very, very careful of how far you go when cutting up with your subordinates. You can’t in any fashion afford to point edgy, biting humorous insults at your team. That kind of humor (which I actually enjoy with friends and peers) isn’t at all appropriate when directed at those reporting to you.

There’s a completely different context and undercurrent when a boss fires off Mom jokes or insults at their subordinates – and a leader should never, ever even playfully joke about firings, i.e. “Whoever wrote this code should be fired.” These sorts of jokes always cut subordinates more deeply than you realize, and cutting up about firing someone over bad code/design/architecture/tests will crush down your team without you ever having a clue about it.

I can’t emphasize this enough: take care with the humor you present to your team. Make humor a big part of who you are as a lead, but stay far, far away from anything which can have a negative connotation.

Above and beyond that, build a great team. You need to take care forming your team – or improving the team you’re given. As the leader it’s your job to line up the best possible members for your team or work hard to deal with the ones you’re given – and “deal with” may mean moving unproductive members off the team. Makeup of your team has to be something you are willing to go to the mattresses on. Fight to get only great members, fight to turn existing members great, fight to get rid of members who aren’t willing to come along for the ride.

Once you’ve gotten your team built, empower them to do great work. I’m a firm, vehement believer that nobody does well under micromanagement. Set broad goals for your team and individual members, give them some borders on how to get that work done, then step back and watch them do amazing things. You’ve set your team up with great folks, or the potential to be great. They don’t need you to guide them every step of the way.

Empowering your team doesn’t mean you ignore them and abdicate your role of leader: you do need to monitor progress, and in no way, shape, or form does this get you off the mentoring hook. Checking progress from time to time ensures your directions weren’t completely misconstrued or that things haven’t gone off the rails. Checking progress does not mean you’re expecting hourly updates on everything though.

Closely tied to empowering your team is your role as Remover of All Things Roadblocky. I am absolutely not the sharpest tool in the shed. I look to get those folks on my team. What I am great at is helping those folks by getting every friction point out of their way I possibly can. I fight for hardware and get creative about sharing it with others when I can’t get what we really need. I push through for process changes to get asinine hindrances removed. Rinse, repeat. That’s one of my personal favorite, most rewarding things to do as the boss: solve problems so folks can shine.

Don’t forget to recognize the progress your folks are making. Teams get bogged down in minutia, so it’s important to give regular shout outs when they’re deserved. The ever-important BVC is critical so the team sees progress over time: “God, we sucked this week, but look at how much value we delivered this month!” I also make use of gift cards and foodie packages from Zingerman’s when the entire team’s done something really cool – like hit major milestones.

Be Part of a Great Team

Building, running, and being part of great teams isn’t easy. It’s a lot of hard work and care and feeding of your people – and it’s worth every penny. I’ve been on dysfunctional teams, I’ve been on teams that were just OK, I’ve been part of amazing teams that continually astounded me. Amazing teams can happen.

Make one. Be part of one. It’s life changing.



[1] I just totally invented the phrase Communications Ecosystem. Feel free to use it. Or not.

Subscribe (RSS)

The Leadership Journey