Software development and the locked box

Jason Austin gave a great presentation at CodeWorks Raleigh recently about cultivating one's passion for software development through side projects -- safe spaces where we can play with new technologies and techniques.

The point's well taken:  as developers, we're probably putting most of our energy towards the thing that must be solved, that keeps us employed, that pays our bills.  The downside is that we become insular, deeply skilled in the few tools/techniques that we use every day, but shallow and uninformed about everything else.  Three reasons:

1. Fear.  You're not going to try MongoDB if you're afraid that its Black Box Magic will someday fail you and your business will be at risk. 
2. Resource constraints.  You have a million things to do, you know how to use MySQL already, so why bother figuring out PostgreSQL.  Oh, and code freeze is in 12 hours. 
3. Inertia.  The path of least resistance is almost always the one you've walked down before.

And so all of us, at one time or another, end up in a backwater of our own devising -- a locked box.

What Jason didn't mention as much, but which I think is equally relevant, is the importance of collaboration, and of community, in becoming a better developer.  This is particularly important for those of us that work in non-technology-focused industries or in small shops, where the opportunities to cross paths with a new idea are fewer.  Here in the Raleigh area we have a pretty robust community in the web application development space, and I'm fortunate to have heard some really awesome presentations in the last few months about some of the innovative things my colleagues are doing.

As Jason suggested, a side project is a wonderful place to learn new things and hone our skills without worrying too much about the blast radius of failures.  I'm fortunate to work with a team whose members all have at least one side project going on at any particular time, and I'm inspired by the things they can get accomplished in their "spare time".  I'd add that active participation in the local community is just as important though:  the opportunities for exposure to new ideas outside your sphere are greater than your feed reader will probably provide, and the depth of information that you can get in a conversation may be better than any blog post or man page.

P.S. Josh Adell did a good rundown of Jason's talk and the rest of CodeWorks Raleigh 2011 on his blog -- check it out!

The Magic of Developer Days

Like most software development shops, at DunnWell we're highly motivated to churn out new features.  In that kind of environment, it's easy to deprioritize improvements that the team needs to do good work in favor of features that immediately make users' lives better.   This works for a while, but eventually all the duct tape and baling wire you use to hold your internal tools and processes together comes back to haunt you.

So, our team instituted Development Days, a week at the beginning of each quarter devoted to work on things other than feature development.  The idea is:  let the team work on projects that are interesting, that let us try new or different technologies than the ones that we use in our main software stack, and that improve the performance of the team as a whole. 

For our first Dev Days week, in July, I wasn't sure what to expect, so I set my expectations low.  The results astounded me.   In just one week, our team managed to:

• Replace our godawful manual deployment process (think 4 people locked in a dimly lit conference room for 4 hours) with a nearly-automatic Phing-driven deploy script that runs in about one minute.
• Test and implement an integration testing stack (using Cucumber/Watir) that gives us full browser testing of the major features of our app
• Create a roadmap for moving our legacy application hosting to Amazon AWS

I can't emphasize enough how awesome this experience was.  Automating our deploy script alone was worth giving up one week of feature development.  It's now so easy to deploy code that we do it all the time, which in turn gives users access to new features faster, reduces the complexity (and therefore the risk) of any given deploy, and eliminates the silly pressure to get every last feature checked in right before a scheduled deploy that makes even good teams do dumb things.

And don't even get me started on how great Cucumber has been for us.  My colleague Eric Burns gave a great presentation on how we use this stack at a recent Triangle JS meetup.

Our next Dev Days starts next week, and I can't wait to see the results.  If your team does Dev Days (or something similar), let me know how it's working for you -- I'd love to hear how others do it.

What's Chicken Technology?

This story begins on a chicken farm.  

In the rural area of eastern North Carolina where I grew up, career opportunities weren't exactly overabundant, so my family raised chickens -- lots of chickens.   Every 7 weeks or so, 78,000 birds would arrive in one of Perdue’s converted school buses, to be grown until they could become thighs and wings and boneless skinless breasts.  

Like most agricultural ventures, chicken farming is a tough business.  There’s never enough money to go around, and every piece of equipment seems to be either actively broken or in imminent danger of becoming so. 

So, our modus operandi:  keep the farm running, but don’t spend a cent that you don’t have to.  Ever.   When approached by vendors selling ideas to make our farm “better” if we invested in a new ventilation system (or generator, or incinerator, or whatever), we’d listen politely, then go right back to a solution that Just Worked. 

To get away with this, we had to be constantly and aggressively innovative.  Repairing and repurposing were ways of life.  My childhood treehouse was yanked out of its tree, dragged down a dirt path, and turned into a storage shed.  Remember those “I’ve fallen and I can’t get up!” commercials?  We turned one of those LifeCall boxes into an alarm system that called a pager whenever something went wrong.  

So, what’s chicken technology?  It’s what I learned on the farm:  solving problems in ways that are both practical and cheap.  Stay tuned to see how I’m applying this approach here at DunnWell, where we’re building a facilities service SaaS application that solves real problems without exploding our customers’ budgets – or ours.  Should be fun...