Opinionated Software

Ruby On Rails has a philosophy of favoring convention over configuration. Its emphasis is on facilitating best practices rather than on supporting features, although it supports plenty. Martin Fowler calls it Opinionated Software, and he recently wrote a great post on the tension between being opinionated and supporting the needs of the larger community:    (KTE)

At the recent RailsConf, PragDave‘s opening keynote highlighted a bunch of unsolved issues with Rails, several of which involved dealing with some of these enterprisey concerns. An example of this was his call for support of more varied database structures, such as having compound primary keys.    (KTF)

DHH‘s response to this could not have been a more emphatic refusal. With a clever visual manipulation of his recent wired cover, DHH projected himself as the Neo of the software world, forcefully proclaiming himself to be in a better place, and telling the enterprise world that they need to join him, not the other way around. Applying this principle to compound keys, the reaction is “no way”. Rails will do what it does, and will not complicate itself to support things it doesn’t like.    (KTG)

Here is a solid example of what makes Rails “opinionated software”. In the Rails mindset, life is much simpler if you keep your tables isomorphic to your objects, and give your tables surrogate, integer, primary keys. If you play the Rails way – life is easy; if not – use something else.    (KTH)

I confess I like this opinionated attitude. Perhaps it reflects my Unix background, which thrives on many tools that do one thing well, rather than a complex tool that tries to do many different things. I like Rails’s focus, its determination to pick a certain class of application and serve that well.    (KTI)

In this sense I see a startling parallel between DHH and Kent Beck. For either of them, if you present them with a constrained world, they’ll look at constraints we take for granted, consider them to be unessential, and create a world without them. I don’t have that quality, I tend to try to work within the constraints gradually pushing at them, while they just stick some intellectual dynamite under them and move on. That’s why they can create things like Extreme Programming and Rails which really give the industry a jolt.    (KTJ)

Lying under PragDave‘s talk was a deeper concern. Like me he’s spent much of this life working with people who can’t apply the dynamite. When you need data from a database that’s run by a data management group and has run for a decade with compound keys, you can’t just don a pair of cool sunglasses and blow the constraint away. One answer to this is to “change your organization or change your organization”, but to those who can’t should they be utterly abandoned by Ruby?    (KTK)

The last word of the last paragraph is the key to the answer. Rails is right, I think, to ignore the enterprisey world, but that doesn’t mean that Ruby should. One of the great strengths of scripting languages, like Ruby, is their post-modern delight in diving into the muck of a chaotic software ecosystem. Ruby is a great place for other frameworks to fill the gaps left behind by Rails’s opinions.    (KTL)

Making Change Safe

My buddy, Justin Lin, has a company that recently migrated from J2EE to Ruby On Rails, and he’s been thrilled by the results. This morning, we were IMing about Agile Programming, and something he said about Unit Tests really struck a chord. He said that their tests softened their fear of change, which changed the team’s entire attitude about change in general.    (KJX)

I’ve written about Unit Tests before in a coding context, and of course, their importance is well understood in the Agile Programming community. What struck me about Justin’s comments was that he was describing how a tool in a very specific context was catalyzing a cultural shift within his company. While he didn’t say this explicitly, I can imagine that shift extending beyond the technical component of the company.    (KJY)

The lesson: Tools that make change safe facilitate a culture of adaptation. An adaptive organization is a strong, effective organization.    (KJZ)

What are some other tools that make change safe? I saw Kellan Elliott-McCrea yesterday (welcome back to California, Kellan!), who reminded me of a suggestion I had made for Social Source Commons a while back: Wiki-style editing works because the revision history is visible. A visible revision history encourages change in the form of Permission To Participate, and that in turn can lead to a larger cultural shift within your team and even your organization as a whole.    (KK0)

The Thrill of Pair Programming

I have a lot of different passions, which is lucky in a lot of ways, and unlucky in others. It’s lucky because it makes life incredibly fun. It’s unlucky, because life is finite, and I don’t have time to delve as deeply into things as I would like. It’s why I knew I would never become a professional programmer.    (JZB)

This past year, I spent most of my time doing field work and thinking about social processes. When I switched into technical mode, it was as an architect or a pundit, not as a programmer. And that’s the way it should be. It’s the right mode for me professionally and personally. Besides, the less time in front of a computer, the better.    (JZC)

However, that’s changed these past few months, as I’ve had to wear my coding hat for a variety of reasons. And I have to admit, it still gets me going. My skills have degraded a lot over the years, more from disuse than age, but I can still get it done. It makes me feel like one of those clean-cut, Midwestern types who comes home from his nine-to-five job, then plays poker all night at some seedy underground club. It’s liberating.    (JZD)

In particular, I had fun Pair Programming with Peter Kaminski a few weeks ago and with Brian Ingerson last night. Both of those efforts were toy one-offs, but they were great fun nevertheless, and it got me thinking. Coding with others, and pairing in particular, is one of the most intense, enjoyable collaborative experiences one can have. Read Evan Henshaw-Plath‘s account of his recent Ruby On Rails sprint with Blaine Cook and Kellan Elliott-McCrea, and you’ll see what I mean. It’s the sort of thing I never get to do anymore.    (JZE)

I know a lot of great coders, and I love talking shop. And, I still want to spend as little time as possible in front of a computer. But, I’m going to make a concerted effort to pair with folks at least once every few months. If you’re in the Bay Area and are in the mood to code up something that is small, cool, and will improve collaboration some way, somehow, let me know.    (JZF)

WikiMania Hackfest Day 3

Today’s tidbits:    (JLI)

  • Ward Cunningham arrived this morning and gamely participated in the afternoon session, despite the long flight. At one point, he asked the Mediawiki developers what the consequences of a wrong architectural decision would be. The answers were revealing. These guys are faced with a tough problem thanks to scaling issues. By necessity, they have to optimize their architecture based on user behavior. However, this severely restricts their flexibility, because if their predictions about user behavior are wrong, it is extremely expensive to rearchitect, reimplement, and reconfigure. Moreover, Mediawiki really can’t develop agilely, at least not where new user features are concerned, for the same reasons. If they were part of a large company with plentiful IT resources (e.g. Google), then it would be a different story, but they’re not. This also makes Extreme Usability somewhat of a pipe dream.    (JLJ)
  • Funny observation from a Mediawiki developer (Mark) on downtime: They’re the only site that profits from downtime. When Wikipedia goes down, folks assume it’s short on resources and tries to donate stuff.    (JLK)
  • At the FLOSS Usability Sprint last February, we framed the following conflict between Open Source developers and usability practitioners: With usability, the mantra is, “You are not your user.” With Open Source, the mantra is Scratch Your Own Itch. Those two philosophies seem contradictory. However, it’s not so simple. Many new features in Open Source projects are user-driven, although the degree to which this happens largely varies. My impression with Mediawiki from watching the developers work and from talking to various members of the community — developers and users — is that the developers are open to feature suggestions, but are not particularly enthusiastic about user-driven design. Developers will implement suggestions, provided they are posted to Bugzilla. That’s a poor way of doing things, in my opinion. I’m picking on Mediawiki, but it’s a very common attitude in the Open Source world — it came up several times at the usability sprint — and really, in the entire software development community. With Mediawiki, I’m particularly disappointed, because they’ve got this huge, wonderful user community. As I said yesterday, the purely technical problems Mediawiki faces are fascinating in and of themselves. However, the opportunity to evolve some really cool user features should be just as fascinating.    (JLL)
  • Then again, perhaps Mediawiki just isn’t the place for this to happen. As I said above, doing Extreme Usability would be especially hard, because the high overhead imposed by the architecture makes it difficult to develop agilely. Maybe the place to experiment is with smaller communities, and Mediawiki can steal features accordingly. That, after all, is one of the goals behind the Blue Oxen Collaboratories — explore cool ideas in real communities and teams, and then propagate them so they are stolen far and wide. The only problem with this is that it’s almost impossible to duplicate the social effects of scale seen on Wikipedia.    (JLM)
  • I mentioned a “MySQL guy” yesterday. His name is Jan Kneschke, and while he works for MySQL, he’s really here to help Mediawiki with performance issues. One way he’s doing that is by advising them on migrating to his high-performance web server, lighttpd (pronounced “lighty”). lighttpd is a relatively new implementation of an old idea: rather than prefork or thread a web server, as Apache does, use a single event loop, which saves you tons of memory and CPU, especially at scale. It’s got some other cool performance tweaks as well. Jan is very sharp, and lighttpd seems to be taking off. Another high-profile site that uses it is Ruby On Rails. One thing I find amusing is that FastCGI, which has been around forever, seems to be making a big comeback. Ruby On Rails, PHP, Sympa, and many other high-profile tools use it. It’s amazing how old things can fly under the radar forever, then suddenly find new life.    (JLN)
  • Over and over again, I see that proficiency in one area doesn’t necessarily translate into others, even if they seem like they should. Folks in the Wikipedia community are incredibly knowledgable about online, emergent communities. However, judging from the conference design, they know very little about facilitating similar emergent patterns at face-to-face gatherings. Again, I’m picking on them, only because I’m here, but this is a widespread problem, and it further validates what Blue Oxen Associates is trying to achieve. Two things that the organizers here have done very, very right: Bring together great people and establish a wonderful culture of openness.    (JLO)