Exploration Through Example

I’ll be in Europe definitely between 9 April (Bristol) and 20 April (Kiev) and likely either before or after those dates. I have some ideas for workshops that we might have while I’m there, provided we can scare up someone to do the local arrangements (venue, mainly). I can work on finding participants, though help would be greatly appreciated.

Here are the ideas:

“Shell and Guts” combinations of object-oriented and functional programming

There’s been much talk about a strategy of having functional cores, nuggets, or guts embedded within an object-oriented shell. Here’s a picture from my recent book:

At SCNA, Gary Bernhardt described a different-but-similar approach. (Very neat - incorporating actor-ish communication between shells.)

This workshop would be about exploring the practicalities of such an approach. (Credit to Angela Harms, who proposed a workshop like this to me and Mike Feathers.)

Next steps in unit testing tools

This would bring together tool implementors, power users, and iconoclastic outsiders to make and critique proposals for moving beyond the state-of-the-practice of unit testing tools. Bold proposals might include: use QuickCheck-style generative/random-ish testing instead of or in addition to conventional TDD, or claiming that the next step in TDD is incorporating or replacing the sort of bottom-up tinkering in the interpreter that’s common in (for example) the Lisp tradition.

Community building for language and tool implementors

Although I released my first open-source tool in 1992, I’ve always been lousy at building communities around those tools. Other people have succeeded. This workshop would be a collection of people who’ve succeeded and who’ve failed, sharing and refining tips, tricks, viewpoints, and styles.

Format

Of the various meeting formats I’ve experienced, one of the most productive has been the LAWST format that I learned from Cem Kaner and Brian Lawrence. Some of the LAWST workshops produced concise, group-approved lists of statements that had substantial influence going forward. These three workshops seem like the kind that should produce such statements.

The LAWST format works best if it has a facilitator who has no stake in the topic at hand. (Such facilitators might well follow the style of How to Make Meetings Work or Facilitator’s Guide to Participatory Decision-Making.) I’d hope the local arrangements person could help find such.

If you’re interested in making one of these workshops happen, please contact me.

I’ve been invited to speak at the ACCU conference 9-13 April, 2013. Because I hate long plane trips, I usually only want to go to Europe if I can get something like a total of three weeks of paid work there. That can be a single engagement at one company, typically doing hands-on programming coaching or just plain programming, or it can be several smaller gigs.

Given Functional Programming for the Object-Oriented Programmer, I can also do Clojure or functional programming coaching and training. I have a two day Clojure course on the topic, though it’ll need substantial revision to match the book.

If you think you have possibilities for me, contact me. Thanks!

I’ll be speaking at Software Craftsmanship North America, November 9th or 10th in Chicago. Here is the abstract of my talk:

Primum: logic programming computes values for variables based on relationships between known facts. In the main, introductions to it are either based on logic puzzles (cannibals and boats!) with an at best unclear relationship to the problems we write programs to solve, or on laboriously reimplementing things (arithmetic!) that we can already do perfectly well, thank you very much.

Secundum: generating complex test data is a hard problem, in part because constraints (relationships) amongst bits of the data have to be obeyed. The sadly common result is fragile tests that know too much about the details of their data.

Ergo: I will explain logic programming by showing how it can be used to generate test data from minimal descriptions of what’s needed.

I’ve been thinking about what talk I might give at Software Craftsmanship North America this year. I have a reputation for “Big Think” talks that pull together ideas from not-software fields and try to apply them to software. I’ve been trying to cut back on that, as part of my shift away from consulting toward contract programming. Also, I’ve heard rumblings that SCNA is too aspirational, not enough actionable.

However, old habits die hard, and I’m tempted to give a talk like the following. What do you think? Should I instead talk about functional programming in Ruby? Since this antique Wordpress installation makes commenting annoying, feel free to send me mail or reply on Twitter (@marick).

Persuasion, Scientists, and Software People

Science, as practiced, is a craft. Even more, it’s a high-stakes craft: scientists have to make big bets by joining in on what Imre Lakatos called “research programmes”. (A research programme is a Big Theory like Newtonian physics, quantum mechanics, Darwinian evolution, Freudian psychology, the viral theory of cancer, and so on.) It’s interesting to learn how scientists are persuaded to make those big bets.

It may also be useful. There are similarities between scientists and software people that go beyond how software people tend to like science and to be scientifically and mathematically inclined. Scientists build theories that let them build more theories. They build theories that let them build experiments that help them build more experiments. Software people build programs that help them build programs—and help them build theories about programming. So ways scientists are persuaded might also be ways software people can be persuaded.

If so, knowing how scientists persuade each other might help you persuade people around you to risk joining in on your craftsmanship “programming programme”.

In this talk, I’ll cover what the science students Imre Lakatos, Joan Fujimura, and Ian Hacking say about how science progresses. I’ll talk about viruses, jUnit, comets, Cucumber, Mercury’s orbit, Scrum, and positrons.

I’ll be speaking at the Scandinavian Developer Conference on March 16-17. I may be speaking at the Scottish Ruby Conference on March 26-27. I have to be back in the USA for Philly Emerging Tech on April 8th. I’d like to do a pair tour of Europe sometime in that time. I’m thinking of something like this route:

Göteburg, Sweden -> Amsterdam -> Paris -> Madrid -> London -> Edinburgh. If you’d be interested in working together, contact me. I’m looking into moving into programming-process consulting (like TDD), cutting-edge programming (like Clojure). I’m also wanting to somehow accelerate my learning of Spanish.

The rules for a pair tour is that you let me “couch surf” (sleep on your floor or couch) and provide some food (dinners, for example). I’m a poor American–I can’t afford European prices.

A message from Richard P. Gabriel:

Folks:

Writing papers is fun, but we don’t get to stretch our wings too often. Here is an opportunity to write something in a totally different style:

Submit an essay to Onward! Essays
Deadline: 20 April 2009

An Onward! essay is a thoughtful reflection upon software-related technology. Its goal is to help the reader to share a new insight, engage with an argument, or wrestle with a dilemma.

A successful essay is a clear and compelling piece of writing that explores a topic important to the software community. The subject area should be interpreted broadly, including the relationship of software to human endeavors, or its philosophical, sociological, psychological, historical, or anthropological underpinnings. An essay can be an exploration of its topic, its impact, or the circumstances of its creation; it can present a personal view of what is, explore a terrain, or lead the reader in an act of discovery; it can be a philosophical digression or a deep analysis. It can describe a personal journey, perhaps that by which the author reached an understanding of such a topic.

I’m the assistant program chair (Simon Peyton-Jones is the chair), and I’d love to get submissions from the agile community. Reflections on
how to create software, what the creative process is like for software, what extremes of process could work in the future, where else could agile work, has it worked,… you name it. Anything to do with software.

NB: Onward! is co-located with OOPSLA, but they are otherwise unrelated. OO is fine, but not required. Not even encouraged.

Don’t forget: 20th April.

PS: To get your imagination going, here are a couple of (strongly contrasting) past essays:

* Dan Grossman “The transactional memory / garbage collection analogy”

* Dick Gabriel “Designed as designer”

* Friedrich Steimann “The paradoxical success of aspect-oriented programming”

or pick up your favorite essayist - be it Samuel Johnson (it’s his 300th birthday!), John McPhee, David Foster Wallace (my favorite), William T. Vollman, Edsger Dijkstra (ugh), or, what the hell, Richard P. Gabriel - and get inspired.

You’re more likely to be invited to speak if you’re a good speaker. For the most part, I have the same advice you’ll find at places like Presentation Zen: avoid bullet points, etc. I have some idiosyncratic habits, though. They’re after the jump.

As with the previous entry, a disclaimer: the way I present is driven by my personality and background. I don’t claim any universal goodness for it.
(more…)

Someone asked me for advice on how to get invited to speak at conferences. Key advice:

• become a valuable participant in a niche field,
• grow along with the niche,
• become a good speaker.

I’ll cover the first two in this note. The details are somewhat particular to my personality and the lucky breaks that came my way. But some of them would work for other people.
(more…)

I’m on the review committee of Jason Gorman’s Software Craftsmanship mini-conference. If I can overlap it with a trip to France, I’ll definitely be there. Here’s the blurb:

This is a conference about the “hard skills” that programmers and teams require to deliver high quality working software.

From writing effective unit tests to managing dependencies, and from writing reliable multi-threaded code to building robust and dependable service-oriented architectures.

This conference is all about the principles and practices, and the disciplines and habits, that distinguish the best 10% of software professionals from the 90% who are failing their customers and failing their profession by taking no care or pride in their work and delivering buggy, unreliable and unmaintainable code.

This conference aims to showcase and champion the “hard skills”, and champion the idea of software craftsmanship and the ways in which it can be encouraged and supported in the workplace, in schools and colleges, and among the wider software development community.

This is a conference about building it right.

Notes from a session at the workshop on Technical Debt. It was organized around this question: Consider two sets of Agile teams. In the first set, the teams do a fine job at delivering new business value at frequent intervals, but their velocities are slowly decreasing (a sign of increasing technical debt or a declining code asset). The other teams also deliver, but their velocities are all increasing. What visible differences might there be between the two sets of teams?

The following are descriptions of what’s unique about a typical decreasing-debt team:

• Most of the team produces 98% clean code all the time, but there is some untidiness (whether due to lack of knowledge, lack of effort, or whatever). However, one or two people take one or two hours a week doing a little extra to compensate. (Chet Hendrickson)

• Behavior in relation to the code is not apprehensive. They’re not scared of the code they’re working on, they’re not afraid of making mistakes that break the code base. (Michael Feathers)

• They’re frequently talking about the state of the code. There are many give-and-take technical discussions. They might be heated or not, but participants are always alert and engaged. The content is more important than the tone: they are discussing new things rather than rehashing old issues. The ongoing conversation is making progress. (Many)

• There are no big refactorings; instead, there are many small ones. (Ron Jeffries?)

• No code ownership. (I forget)

• Time is spent on building affordances for the team’s own work. In Richard P. Gabriel’s terminology, they spend time making the code habitable: the code is where they live, so they want it to be livable, put things where they are easy to find, make them easier to use next thing. (Matt Heusser and others)

This isn’t a complete list, only the ones that struck me and that I remembered to write down.