A fresh perspective

by aaron

Looking back on past code oftentimes gives us all a case of the “What was I thinking?”. You could just ignore svn blame and pretend you didn’t write it, but you did. You sucked. And that’s okay. It’s hard (read: impossible) to write perfect code the first time; there are too many things you haven’t learned/thought/worried about yet.

In the beginning, there was function.

A fully-functioning piece of code is sort of your 1.0 milestone. That was the PluginAWeek milestone. There was all this code and, somehow, it all pretty much worked (at least, for a time it did). There wasn’t too much thought other than, “Hey! Let’s see what kind of fancy, shmancy stuff we can do with this!” Once you get on that gravy train, it’s hard to look back.

A lot of us get stuck in that 1.0 state. When I started on the re-building of this project several weeks ago, I did so with a different set of goals in mind.

And Ruby said, “Let there be elegance”. And there was elegance.

Functional plugins are awesome. But, hell, Apple doesn’t sell laptops just because they’re functional. If that were the case, no one would raise their hands when I ask “Who here is developing Ruby on a Macbook Pro?” (p.s. I am not in that group). There’s a lot more to it. And that’s the part that counts.

  1. Make it elegant. We develop in Ruby. We’re in love with simple, elegant code. Some of us get turned on by it. Make us love your code.
  2. Make it easy. Plugins are supposed to be drop-in code. I learned that the hard way. The more things I have to do to get your plugin working, the less of a chance there is that I’m going to use it.
  3. Write good code. Don’t hack it in. And don’t write hacks. Follow Merb‘s strategy: Distribute simple, elegant code. If someone wants to start using hacks, let them do it, not you.
  4. Extend, don’t overwrite. When I see a plugin copying framework code so some custom code can be injected, I’m immediately turned off. That’s hard to maintain and more likely to fail during upgrades.
  5. Write good documentation/tests. A lot of you hate it, I know. But do you know how many headaches we’ve had because of the lack of documentation for Pound? So many that we stopped using it.

Sequels are underrated. Honestly, who isn’t psyched for Indiana Jones 4?

Failure is just an opportunity to get it right the second time around. So don’t screw it up the second time around! ‘Cuz two failures are an opportunity for me to point and laugh at you and no one wants that, trust me.

Comments

2 Responses to “A fresh perspective”

  1. Yehuda Katz on May 22nd, 2008 6:51 pm

    @aaron Great post. Part of the trick, of course, is to write the initial framework so it’s easy to extend. As you pointed out, we do that with Merb. Additionally, we consider it a bug if people feel compelled to use alias_method_chain on our code (we don’t actually distribute alias_method_chain with merb, so there’s a bit of a disincentive to use it).

    Providing perfect points of interaction is obviously not easy to get right the first time, but that’s why we started over with 0.9 :)

  2. aaron on May 26th, 2008 9:54 am

    @yehuda You know, that’s a really interesting point about alias_method_chain. I hadn’t really thought about that until I watched the Merb presentation from the Gotham Ruby Conference. It seems like, for many projects in Ruby, a well-designed interface is ignored because you can just fall back on the hacking power of Ruby to get what you need done.

    I really like what you guys are doing with Merb. I haven’t used it yet for any personal projects, but it’s definitely under the radar!