A Career Accounting

Ideas I've contributed to & how they relate

As part of my reflection on my relationship with running a sustainable, sustaining business, I have engaged a marketing coach. One thing about coaches is they ask good questions.

How do these methods [ed: ideas I’ve contributed to] relate to each other?

We had been talking about my mission to help geeks feel safe in the world. I rattled off some ideas I’d contributed to. Then the coach asked how they related. Well, here’s my answer, expressed as best I can in terms a marketing expert (who’d done some coding) could understand.

I want to emphasize before we start that all of these ideas were collaborative. I’m viewing them through the lens of my career. I owe a great debt to Ward Cunningham, Erich Gamma, Martin Fowler, David Saff, Massimo Arnoldi, Ron Jeffries, & many others.

Ideas

Ideas I've contributed to in software engineering (in roughly chronological order) are:

• Patterns. Record a catalog of common problems in programming and the (relatively few) reasonable approaches to solve them. Weave these patterns so together they help folks solve larger problems. Provides a precise vocabulary for design conversations.

• JUnit. A tool for programmers to write their own tests. Before JUnit programmers were assumed to be untrustworthy, requiring a separate organization to test all changes.

• Test-driven development (TDD). A workflow for programming inverting the usual sequence make changes->test those changes. Instead we first write a test that is bound to fail because we haven't made the changes yet, but that will succeed when those changes are made correctly. Alleviates common anxieties for programmers like "am I done yet?" & "did I break anything?".

• Refactoring. Design a little at a time. Before, all design was assumed to have to happen before implementation. If you made mistakes (and you always made mistakes), you were just stuck with them.

• Extreme programming. A social style of team development. Programmers, designers, users (real, actual users), & product experts sit together. Every week the system does something new that the users are grateful for. Every week is a chance to change direction & focus. Every day pairs form to work on bits of the week's work together. Every hour or so everyone working merges what they are working on at the moment into the live production system.

• 3X: Explore/expand/extract. Suggests 3 different styles of management & execution for projects depending on whether they are speculative, rapidly growing, or maturing.

• Thinkies. Much of my "creative" thought (as judged by other people) is the result of habits. I'm recording the 40 or so habits I recognize that I use repeatedly. (If this sounds like patterns, I hadn't noticed that before but it's the same trick.)

• Empirical Software Design. Making large design changes in small, safe steps. Also describe the fundamental forces--economic, social, psychological, & technical--driving software design.

Connections

I read the question as "how does Idea X support Idea Y?".

Patterns->JUnit. We used the patterns to discuss the design of JUnit, helping that design be replicated in every contemporary programming language.

Patterns->Refactoring. Refactoring is often a collaborative process, & precise vocabulary smooths collaboration. Listening to pattern experts discuss changing a design is like listening to a highly coded conversation but it's clear to the participants.

Patterns->Extreme Programming. Maintaining a steady, unrushed flow of features requires high level execution skills, including continual design to keep the system flexible.

Patterns->3X. I describe the phases in terms of conflicting constraints, pattern-style. Also, the different strategies for dealing with each phase is described pattern-style.

Patterns->Thinkies. I haven't dug deeply into any of the habits, but I expect them to come out pattern style.

Patterns->Empirical Software Design. 

JUnit->TDD. A new programming workflow requires tools that fit into the existing programming workflow. JUnit tests are written in the same language as the code being tested. This makes switching back & forth between coding & testing quick. This is important in TDD because you switch so much more often.

JUnit->Refactoring. To make changes in small steps those steps have to be demonstrably safe. JUnit makes it economical to demonstrate that you haven't accidentally broken anything.

JUnit->Extreme Programming. To survive the kind of transparency required of social development, programmers need a way to take responsibility for the quality of their work. JUnit is one way to do so.

TDD->JUnit. JUnit was developed using TDD, giving us the confidence to move quickly & evolve aggressively because we could cheaply demonstrate that we hadn't broken anything that used to work.

TDD->Refactoring. TDD makes refactoring work by offering an efficient way to take small, safe steps.

TDD->Extreme Programming. Pairs (or ensembles) need a way to confidently move forward together, to improve the product in small steps. Tight connection between programmers, users, & production only works if the programmers keep the system reliable, which TDD enables. (There are other ways to do this but the cycle times are longer.)

TDD->Empirical Software Design. ESD is the study of succession, making changes in small steps & creatively ordering those steps. TDD offers the confidence to explore the many possibilities. (Again, you could do this without TDD but at greater cost.)

Refactoring->JUnit. We refactored extensively as we developed, important when 2 part-time developers support millions of users.

Refactoring->TDD. The incremental style of TDD wouldn't work without a discipline of design change. Without refactoring you'd be forced to make all conceivable design decisions up front.

Refactoring->Extreme Programming. Maintaining a steady flow of user-valued features requires a discipline of design evolution. Otherwise the well-meaning mistakes build friction in the present.

Refactoring->Empirical Software Design. ESD is making large changes in small, safe steps. Refactoring is those steps. (ESD adds "when" & "why".)

Extreme Programming->3X: Explore/Expand/Extract. XP is flexible enough to be adapted to the very different needs of the 3 phases.

3X: Explore/Expand/Extract. 3X completes Extreme Programming by asking the critical first question, "What is at risk at the moment?" Development needs to adapt to the various common answers.

Thinkies->everything. All the ideas have been the result of Thinkies (an essay for another day). The elaboration of each idea also required all of the Thinkies.

Empirical Software Design. Too soon to tell.

Conclusion

Do you see other connections? Disagree with the above. Did I leave out any ideas that affected you? Please comment.

I’m building up to reiterating my personal mission statement in a few weeks. But first a vacation.