I’m not smart enough to have ideas before I need them

Last week an attentive colleague heard something potentially self-contradictory in my reasoning and reflected it back to me. His question was too precisely unexpected for me to remember it precisely well, but it elicited an immediate response that was memorably clarifying for both of us: “As a developer, I expect to be surprised often by what the business needs from the software we’re building, so I want to be surprised as little as possible by our software.” He asked if I’d ever said those words in that order before. I had not, and perhaps never would have, but for his careful observation and question.

I’m just smart enough to cope

An observation by Pat Maddox a few months back induced me to formulate:

”If you want to want to X, then arrange for whatever helps you want it. Enthusiasm engineering.”

I have lots of values of X I want (for varying degrees of “want”) to be handling differently. Most of them aren’t, at any given time, my most pressing concern. So they tumble around at the back of my brain, taking up a bit of space, and seeming more and more difficult the longer I’ve evidently failed to address them.

The downside is that no matter what doesn’t work about my current behavior, it’s relatively easy for me to make a habit of it. The upside is that as soon as I notice the problem — usually when it’s more biggish — it’s relatively easy for me to change my habit. I wasn’t doing it that way for any particular reason, so if I’ve got a reason to do it another way, I can arrange myself to do that until it sticks.

I can sometimes evaluate more eagerishly

If a future habit-induced difficulty would be sufficiently biggish that I’d rather not wait for it to get that far, I can try to arrange myself to address it sooner. This is considerably less of a sure thing. My main strategy is to change my scenery.

Changing which desk/office/coffeeshop/city I’m working from today, what I’m working on today, and/or whether I’m working today induces temporary changes in what I notice and attend to. As such, I can rely on changing my scenery to be temporarily useful. Among the Temporary Usefuls are invitations to consider making more lasting changes to one or two of my default settings. If I’m a complex adaptive system, and I want to be making different choices, then I need to arrange conditions that are likely to encourage me to make those choices. I’m willing to make the effort for one or two things at a time, if they seem likely to be worth it.

I default to comfort

When I’m not paying attention, I seek comfort above all else, which places me in familiar vantage points, where I stop noticing things I’d otherwise want to notice. That’s why, as a general rule, when someone invites me to do something I wouldn’t choose to do on my own, I try to accept: art museums, concerts of music that isn’t my absolute favorite, vacations through tropical locales, etc. It’s a good rule, if I ever want to expand beyond my self-imposed horizons.

Eine kleine Enthusiasmusingenieurwesen

I want to want that, so I arrange for others’ invitations to help me want it.

Posted Mon Aug 3 07:55:08 2015 Tags:

When I was in college, I discovered that after two semesters of the kind of thinking that helped me complete my course assignments, I’d itch for the kind of thinking that helped me consult for clients. And after a summer of practical-minded problem-solving, I’d be minded to float my head back up in the clouds.

When I graduated and got another programming job, I discovered that the kind of thinking I do to make worthwhile software energizes the kind of thinking I do to make worthwhile music. Once again, the converse also turned out to be true. On work-from-home days, I alternated between computer keyboard and piano keyboard as often as necessary to keep my code, and my brain, valuable and sustainable.

Chet Hendrickson recently reminded me that what we now call sustainable pace and had once called 40-hour week had originally been defined in XP as “no overtime”. These are not identical concepts. Overtime, as the XP folks meant it, meant “time spent in the office when you don’t want to be there”, or perhaps identically “time spent working that makes you less effective in the long run”. Maybe some people average 40 hours of wanting to be in their (real or virtual) office. Maybe some of them even cluster closely around 40 hours every single week. But there are plenty of us for whom 40 isn’t the average. And whatever your number is, no matter how closely you cluster around it, every now and then you need to take a zero.

I love my work, and I’ve enjoyed a cluster of completely terrific opportunities over the last couple months. But taken all together, they’ve taken altogether too much of my time away from the life my work is supposed to be a part of. By any definition, it’s been overtime. So last week and this week, I’m taking intentional zeroes. (Don’t worry, the writing of this post happened outside zero hours.) And when I get back into the swing of things, knowing myself, I’ll be energized to think and act to sustain my sustainable pace.

Posted Wed Jul 22 08:00:02 2015 Tags:

At Agile and Beyond a few months ago, I launched a new micropodcast: Agile in 3 Minutes, “the simplest podcast that could possibly work”.

For as long as I can remember, I’ve always wanted to produce a real podcast. In college, to share my music (mostly) with far-flung friends and family, I published an irregularly-scheduled “Schmonzcast” here on schmonz.com. That sort-of podcast mattered a great deal to me, but would never matter to more than a few others.

I’ve long wanted to be real-podcasting because it seemed like it’d play to my strengths. I’ve learned that some people find my voice pleasant to listen to, and that sometimes I express ideas in ways people are receptive to. And I’ve already got a handle on the podcast-publishing basics.

As soon as the idea to describe aspects of Agile in tiny timeboxes landed in my head, I knew it was worth trying. How many minutes, though? Four felt like a giant blank canvas; three felt liberatingly constraining. Three, then. I bought a domain and a decent microphone, wrote and recorded the first couple episodes, and announced them, fittingly, in a Lightning talk. Every week since Agile and Beyond, I’ve been writing, editing, editing, editing, recording, processing, and publishing one new episode. (Episode 12 went up yesterday.)

You might be wondering, how Agile a production is Agile in 3 Minutes? The one-week iterations keep me delivering, the 450-word increments feel sustainable, and the one-at-a-time batches give me chances for feedback.

Until now. Whatever I might have learned from delivering #12 won’t be reflected in #13, because they were written and produced in rapid succession. (I’ll be mostly off-grid until it’s time to cook 14.) The larger batch size makes me a little uncomfortable. But I’ve learned in other contexts — including software development — that choosing not to indulge my perfectionist tendencies often produces results that vary in some useful way. And since one of my goals for the show is that every episode be someone’s favorite, maybe there’ll be useful variance in these two. We’ll see, won’t we? I have no idea what Agile in 3 Minutes will add up to, but I’m pleased that it’s starting to add up to something.

You might also be wondering, did I use the whole 5-minute timeslot for my lightning talk? I did not. 3 minutes was enough.

Posted Wed Jul 15 08:00:03 2015 Tags:

Previously

This is the last in a series about TDD’s value to humans, following

  1. Keeping my job, in which I lost my manager’s trust,
  2. A last-minute feature, in which I regained some,
  3. Deadline pressure, in which I earned quite a bit more than I’d started with,
  4. Continual delivery, in which the circle of trust grew to include our Operations team,
  5. Fail-safe, in which we were always deploying soon,
  6. A big project, in which we delivered an 8-month project with minutes to spare,
  7. Win-win, in which we helped another project hit the same deadline,
  8. No secret, in which people oddly found the reasons for our success disappointing, and
  9. Thwarted, in which we almost reached a new level of collaborative development

Is there a doctor in the house?

People who rely on the outcomes of software development work, but who have not experienced firsthand what it’s like to do that work, sometimes present with a disheartening cluster of chronic symptoms:

  • They want to do something to help bring about an outcome
  • They see some simplistic knobs they could turn
  • They don’t see the costs of turning those knobs, or notice the less visible knobs, or consider abstaining from knob-turning altogether

People exhibiting these symptoms might, for instance, ask a developer to spend less time testing. (Note that they wouldn’t be caught dead on the record instructing anyone to write fewer tests, but that’s exactly what they’re wishing for.) This particular simplistic knob appears to provide a way to trade quality for speed. If we rarely have shortfalls in quality, and we’re perpetually understaffed, then let’s turn this knob just this one time. Oh, and while we’re presuming that developers don’t spend their time wisely, let’s also presume that in any given unit of time they can always find a way to accept more work.

By contrast, managers and customers in good software health know that developer productivity is nonlinear. Even when solving relatively well understood problems, time can’t usually be reclaimed from test-driving and redeemed for more stuff done over any horizon longer than a few lungfuls of overly conditioned air. The outcome of attempting to trade quality for speed is often not only to have traded quality for nothing, but also to have undermined the hard-won basis of the attainable speed that had once been attained. (And “productivity” is itself a questionable construct when the goal is ostensibly not to maintain busyness, but to solve problems for humans.)

Is there an epidemiologist in the house?

Quite a few folks with other goals do nonetheless exist, as do those who come to poor knob-wiggling conclusions via faulty premises: people who don’t begin to understand the nature of software development work, don’t begin to imagine that their lack of understanding could possibly hinder the outcomes they wish for, don’t prevent themselves from intervening roughly and habitually in sensitive systems, and cause pain for themselves that perhaps only hints at the pain they cause others. I worked with (and for) many such people at the organization featured in this series of stories. Their broad and deep misunderstandings of the costs and benefits of TDD and of software development in general — and my overall lack of success in reversing or otherwise overcoming them — ultimately limited my effectiveness in my various team roles. But everything I learned along the way is mine forever, to keep and to share.

Retrospective

We had a great run. Along the way, while reviewing my performance, I summarized it thus:

Test-Driven Development has become thoroughly entrenched as a standard practice for $OURPRODUCT Engineering. The dividends, many and profound, are difficult to completely quantify. Nonetheless, three overall patterns are striking:

  1. We’ve reversed the usual signs of software aging. As typical projects expand, the risk of change increases and the pace of development therefore slows; as $OURPRODUCT’s test coverage expands, the risk has decreased and the pace has accelerated. With TDD, we can safely develop complex, invasive new features (like support for an archaic database system’s not-exactly-identities) and trust them to work as designed without breaking existing code.
  2. We’ve fundamentally changed our relationship with Operations. They now trust us to ship working software because they understand how TDD works. We’ve taken advantage by releasing monthly (up from quarterly), which controls the rate of change, ensures that new code is always production-ready, and maintains our sharp and careful release habits.
  3. We’ve identified a new paradigm for collaborative development at $COMPANY. The situation: $OTHERPROJECT1 needed $OTHERPROJECT2, $OTHERPROJECT2 needed new code in $OURPRODUCT, and $OURPRODUCT was laser-focused on that $ARCHAIC_DATABASE_SYSTEM, leaving me zero time for requirements and design discussions with $OTHERPROJECT1. They generously offered a developer on short-term loan (a week or two) who happened to understand our product and had the needed technical skills. The paradigm: I accepted the loan on condition that it result in a set of test cases for our test suite. This forced all the discussions to happen upstream where they cost me nothing, made efficient use of the loaned developer’s cross-silo expertise, and delivered a simple, unambiguous spec which took me an hour or two to implement. $OTHERPROJECT2 and $ARCHAIC_DATABASE_SYSTEM both shipped on schedule, thanks to TDD.

In summary, the cultural shift to Test-Driven Development has resulted in less risk, more intelligent use of existing resources, and more agile reactions to the changing needs of the business.

Conclusion

On our own, in a little corner of a big company, we created half a humane workplace. If our efforts had been recognized and reciprocated, it could have become a whole one. The pride I always felt in our work, combined with the pain I frequently felt while doing it, led me to become a software development coach. I want to help people understand how this kind of work works, and how it can be done better, because I want our lives to be filled with less pain and more pride.

And that, as fully as I can tell — and have now fully told you — is the human value of TDD.

Posted Thu Jul 9 20:55:30 2015 Tags:

Previously

This is the ninth in a series about TDD’s value to humans, following

  1. Keeping my job, in which I lost my manager’s trust,
  2. A last-minute feature, in which I regained some,
  3. Deadline pressure, in which I earned quite a bit more than I’d started with,
  4. Continual delivery, in which the circle of trust grew to include our Operations team,
  5. Fail-safe, in which we were always deploying soon,
  6. A big project, in which we delivered an 8-month project with minutes to spare,
  7. Win-win, in which we helped another project hit the same deadline, and
  8. No secret, in which people oddly found the reasons for our success disappointing

A growth opportunity

Our team had solidly established the habit of writing good tests first and listening to what they told us. People who could read Perl could read our tests, and we’d taken full advantage of that to build shared understanding with stakeholders of sufficiently technical backgrounds, whose trust served to reinforce the effectiveness of our collaboration and our product. We knew how valuable it’d be if we could find a way to extend that understanding and trust to a broader audience. We were on the lookout.

When our product and team moved to a better-fitting department, our team’s reputation garnered some attention from our new neighbors. For the first time, we found ourselves living next to a group of QA folks, whose perceptive manager saw us as an opportunity. His more skilled people could help us and learn from us. Would I like to borrow one of them for a full two-week iteration?

Unlike previous occasions when I’d been offered a person on short-term loan, I instantly had a pretty good idea how we could put a skilled tester to effective use. But not yet. First, we needed to prepare.

Our preparations

Our TDD practice was already oriented toward system behavior, aimed at uncovering not only design choices but also acceptance criteria. We would usually find surprising ramifications of a chosen approach early in development, while it was still relatively cheap to review with stakeholders and either get more precise agreement or adjust the goal. We wanted our borrowed tester to comfortably participate in those conversations and potentially contribute test scenarios. We now needed a language more shared and more commodious than Perl. And we didn’t need — indeed, couldn’t afford — to start shlepping around any manual tests or non-executable specifications on our journey. Dear reader, you doubtless see what we saw: Gherkin could be our shared language, and Cucumber could incorporate it into our build.

There was one small problem: none of us had ever used Cucumber before. We didn’t want to waste any of our tester’s limited time figuring out how to wield a new tool. We wanted to be ready the moment he arrived. So we immediately picked a feature perfect for learning: a low-urgency feature intended for the benefit of our compatriots in Operations, and whose desired behavior we understood very well. Instead of confidently writing our usual tests, we wrestled with how best to express our assertions in Gherkin-inflected English, and how best to arrange for them to fail meaningfully against the production code we were wanting to change.

When we got it figured out well enough, with Cucumber hooked into the build, we asked Ops to review the spec with us. Because they could! And maybe they’d spot something we’d misunderstood! When they didn’t, we proceeded to test-drive as usual, albeit with slightly different red-test messages; when we got to green, the feature was every bit as done (and well done) as usual.

The payoff

We were ready for our tester. When that iteration kicked off, we would set right to pair-writing scenarios, likely conjuring more meaningful tests than we’d have done on our own, and our visitor would be acquiring a new and marketable skill.

Or at least he would have, if the window of opportunity hadn’t been rudely slammed shut.

A change of plans

The original offer, and our preparatory actions to take advantage of it, occurred while product decisions had still been mine — which is to say, when the team had opinions distinct from mine, I generally listened and took them into account. But I was in transition to a much-needed role as an internal Agile coach, so my team and product were necessarily in transition too. By the time the promised iteration rolled around, product decisions were no longer mine — which turned out to mean they were made with very limited consideration for the team (me included).

The new product manager promptly nixed any further efforts with Gherkin as a language, Cucumber as a tool, and QA as a partner in our development process. No reason was ever shared with us for this decision, which we felt wasted our investment in time and effort, ignored our needs and wishes, and limited our options for improving our effectiveness.

Conclusion

Cucumber continued to be the test runner for that lone Ops feature. But who knows how much it might have helped us collaborate more productively with testers, non-technical managers and customers, and the business as a whole? We never got the chance to find out.

Posted Thu Jul 2 22:30:05 2015 Tags: