Emergencies, and How to Kill Creativity

A post over at Slow Leadership: Slow Leadership: How to Kill Creativity is closely related to a “rule” we have at Oasis Digital: we have a limited “budget” of emergencies; we will spend no more than a small percentage of time in “emergency mode”.  If there appear to be so many fires that that the team spends most of its time fighting fires, we first review who is doing what work – and usually find that most of our developers are mostly doing the right things in the right way.  There is a bit to be gained by “trying harder” – in the short term.  The real solution is not to try harder – in fact that approach almost never works over time.  Rather, the solution is to slow down and get to the heart of the matter, which is usually some variation or combination of:

  • The software doesn’t have the right features to handle unusual situations or inputs gracefully.  Add them.  Make it so our customers/users have the data and features they need, to deal with new situations directly, rather than those situations becoming our emergencies.
  • The software doesn’t have the right documentation and training, to enable its users do deal with new situations directly.  Add that documentation and training.  Users are often far smarter and more capable than the typical software developer gives them credit for.  We have repeatly been amazed and thrilled at what our customers have been able to accomplish when handed even the roughest of tools and explanations.
  • Our software has a deep mismatch to the problem it is intended to solve.  Change it… even if it means something scary like rearranging the core of a large DB schema.
  • We don’t have the right team for the problem/project at hand.  Swap someone around.
  • The team isn’t big enough for the problem.  Grow.
  • The problem is too big for the team/budget.  Trim scope, do a great job on the new scope, then consider expanding it again.

By doing these things, we apply more brainpower / creativity to automation, innovation, and genuine progress on the problems at hand.  This is the antithesis of the “pressure based culture” described in the article linked above.

The Rails aren’t so smooth if you want some [Image]Magic[k]

We started some work recently with the much-hyped Ruby / Rails combination. For the most part, it’s lived up to the hype; going down it’s ‘happy path’ has been far more productive than work with some other web app frameworks and languages. But today I hit several sources of Ruby / Rails pain in a row, and it seems worth writing about them, perhaps to save the next fellow from the same.

The nexus of the pain is RMagick, which, once working, is a great set of tools for drawing graphics in Ruby. My partner on this project had some trouble getting the numerous dependencies in place on Linux and/or MacOS; he thought it would go much easier on Windows, since there are far fewer dependencies.

Indeed, it should have been easy. I went over to the RMagick download site and grabbed the latest and greatest almost-ready Windows Gem, version 1.10.1. Its instructions said I needed Ruby 1.8.4, so I remove my old 1.8.2 and grabbed Curt‘s One-click ruby installer. It is a release candidate (“184-16 release candidate 1”), but Curt said the other night that the installed software is ready to go, he’s only working out a few installer issues.

All good… except now nothing worked at all. Lots of errors like “./script/../config/../app/views/admin/signin_form.rhtml:3: Invalid char `\360′ in expression” and “./script/../config/../app/views/layouts/login.rhtml:2: parse error, unexpected $, expecting kEND”. After considerable searchings I found clues and then the answer. The RMagic docs led me astray – by ignoring them and going back to 1.8.2, it all works again… for small values of “all”… because 1.8.2 doesn’t include Rake, Rails 1.1 prefers 1.8.4, etc.  It appears, if I understand the various posts correctly, that RMagick breaks Ruby by changing a method on String. This is a rather unfortunate, surprising, and in my judgement, bad thing for such a library to do; I can’t imagine offhand why RMagick should do anything at all until invoked. At minimum I’d hope to be able to trust an image manipulation library to not touch, much less break, the String class 🙂

That’s enough digging for now; hopefully when I return to this, the issues will be worked out, there will be matching, current, compatible versions of all these parts, and things will run smoothly along the “rails” as usual.