Martin Fowler – Eugene Eric Kim

Productivity501

Published April 9, 2007 by Eugene Eric Kim

Most of the blogs I subscribe to are by folks whom I know, or folks whom are two degrees away. I don’t search for interesting things to read — way too much of that already — but occasionally, minor perturbations uncover new and interesting things. Today, I discovered Mark Shead‘s blog, Productivity501, via an indirect link back. It’s a blog about productivity. I find productivity so important, I generally avoid spending time reading about it. However, two items jumped out at me. (M6D)

First, Mark wrote a clever twist on the Tortoise and Hare fable, set in an Iron Chef competition. I freakin’ love Iron Chef. More importantly, he made a point I’ve also emphasized in the past — clean working stations are a critical pattern for high-performance work. (M6E)

Second, I previously blogged Martin Fowler‘s hypothesis that bigger screens made developers more productive. Mark cites an actual study that makes the same claim. (M6F)

One Small Change

Published February 26, 2007 by Eugene Eric Kim

How do you improve the productivity of software developers? Software engineering guru, Martin Fowler, has a surprising answer: Give them bigger screens. (LV4)

Thinking like this fascinates me. In Super Size Me, filmmaker Morgan Spurlock suggests that the way to improve U.S. schools is to eliminate junk food from cafeterias, and cites studies correlating physical education and test scores. Learning guru (and Blue Oxen Associates advisor) Marcia Conner recently cited studies showing how outdoor education affects learning in the classroom. (LV5)

In previous posts, I’ve speculated that improved geography skills will lead to better foreign policy decisions, and I’ve also discussed the role that more and better dialog might have on the world. (LV6)

What would be One Small Change that would drastically improve the way you or your team collaborates? Post your ideas to your blog (and link back here), or Ideas send them to me. (LV7)

Opinionated Software

Published July 11, 2006 by Eugene Eric Kim

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)