Prior to inking my employment with JBoss, I served as backend developer for a firm specializing in rich-media webapps.  The founders at the excellent 9mmedia in Manhattan have background in user interface and interactive design, and as such built a team heavily centered along these core competencies.  So I was always a bit of an oddball by nature of my minority role in the place.

Around the same time, Agile Development was really collecting religious momentum, and a guiding precept there was roughly: “Do only what needs to be done now.”

This makes sense; it helps to ensure that we avoid scope creep, we don’t invent requirements that may end up being unnecessary, and we don’t overengineer.  Let’s just focus on delivering the minimal set necessary, then worry about expanding it later.

As such, I adopted the “no” philosophy.  I figured that if a feature was really that important, it would persist and nag in some way until it was included.  Otherwise, it must not be that worthy.  So as a default, my answer to everything was “no.”  Like a knee-jerk reaction: no.  Want me to do something new?  No.  New technologies?  No.  Component upgrades?  No.

It’s not a hard methodology to enforce.  Just pretend you’re every girl I’ve ever met.  ”No.”

So then I came aboard into Professional Open Source in building the EJB3 Container for the JBoss Application Server with Carlo de Wolf.  Oh boy, does that guy know how to separate concerns.  Over the course of a few years my new and reluctant mentor would drill into my head the importance of defining a contract for interaction between components and keeping everything in their rightful place.  Does this belong here?  No.  Build a new thing.  Then integrate it.  It carried along my tradition of “no” quite nicely, but at least it offered, “not here, go play over there”.

Then I got really sick of running the EJB3 TestSuite upon JBossAS, and started building out some tools – some great, some hacky – to improve the situation.  One of these, a then-unnamed API for manipulating Java Archives, caught the attention of some dude from Oslo named Aslak Knutsen.  Who really started fucking up my universe.

This guy wanted to implement every single integration and feature under the sun.  He wanted to deploy these archives not only into AS, but other vendors.  He wanted to use custom JUnit runners.  He wanted to code stuff just to see if it could be done.  And he’d prototype a way to do it.  For awhile, it was all I could do to keep up with this runaway nutjob that I was sure we’d never be able to support or put into any maintainable form.

The Java Archive API became, of course, ShrinkWrap, and Aslak went on to employment with us as lead of the Arquillian Testing Platform.

And still I advised, “Slow down.”  We needed to keep focus on our primary goals here.  We needed to learn to say “no”.

Well, “no” isn’t in the Norwegian dictionary, I suppose.  And it certainly didn’t help matters to have Seam lunatic Dan Allen be coming along to goad on what was becoming an endless litany of “cool stuff we could do”.  My little team was comprised of children prone to chasing shiny balls; fantastic.

In the years that followed, we’ve watched the Arquillian Suite of projects blossom into a wide array of tools intent on easing the testing of Enterprise Java.  And it turns out, just by trying new ideas in a sometimes half-baked fashion, having something concretely usable is enough to determine if the concept has merit.  Other people in open source will pick it up, be drawn to it.  We’ve got contributors coming in from all sorts of angles: “What about the UI?”  ”What about Behavior-Driven Development?”  ”What about Persistence?”  ”What about…”

Turns out the risk of taking on too much or letting quality suffer naturally corrected itself as these ideas matured.  And the bad ideas just silently died, with minimal effort wasted.

I remember reading something once written by Red Hat People and Brand SVP DeLisa Alexander about the willingness to fail acceptably.  Meaning that if you invest minimally in a bunch of ideas, your eggs aren’t all in one basket and you can afford to lose a few along the way.  From those eggs, you just might get some extra chickens you weren’t expecting, which in turn makes: yep – more eggs.  In short, saying “yes” solves the chicken/egg problem.

But none of this really hit home for me until today.  For one, I’ve been debating with a colleague about accepting more risk in general.  About having the faith to try some new things, even if they may not work out I believe the acceptable risk quota is still in the black.  And I took some time away from this lengthy email exchange to read Tina Fey’s “Bossypants“.

See, Tina spent her formative years as a professional comedienne in a Chicago-based improv troupe where the rule is, “Yes, And…”.  Meaning no matter the premise of the scene thrown at you, agree with your costar.  And then add upon it.  Wrong answers do not exist.  It’s an exhilarating approach.

Of course, I work in software and business.  Obviously wrong answers exist.  Most answers are probably wrong.  But when I’m wearing my hat as a creative problem-solver, probably it’s useful to invest just a little bit into each stupid nugget that comes across, or at least enable the idea-bearer to make some headway on his/her own.  Because I still believe I was right before: good ideas will persist.  Just don’t kill them too quickly.

Yes.  It’s so simple.  Minimally commit yourself to new things and see if they warrant further investment.

And if you have any doubts at all about this approach, check out the movie “Yes Man.”  Because Jim Carrey embraces the affirmative, and he gets to nail Zooey Deschanel.

S,

ALR