Week 6 at Box… what I love so far

I recently joined Box.  I worked nearly 9 years at Guidewire, more than 3 times longer than I’d stayed anywhere else in my software career, and only the 2nd company that I was at that I wanted to recruit friends into (Sapient was the other one, if you’re curious).  It is obvious to me that I’m still in the honeymoon phase here at Box.   You can hear it in how I gush when my friends ask me if I’m enjoying my new job.  “Oh Yeah!” I heard myself say at a potluck last week at our house.   “Box is great.  I love it there!”   But I do try to temper my response a little.  I don’t want to appear crazy in THAT way.  I also have the discipline to force myself to be objective, and look at it a little over the weeks to figure out what it is that is really making me so psyched.   Here are a couple quick analysis areas:

What I value that is not uniquely Box:

• Open environment:  Box has an open environment… no cubes, no office for the CEO.  I wouldn’t have come here if it didn’t.  It’s that important.  Open work environments foster teams to communicate.  Personally, it helps me overhear random things that are going on that I want to learn more about.  Yes.  I like to stick my nose into other teams business when I know it is going to affect my team.  At Oracle, I was looked at like I was possessed when I took my swiss army knife to the cubicles, and pulled enough dividers out that my team could all chat with each other without leaving our desks.  I did the same on many a consulting assignment with KPMG, and then with Guidewire.  I’ve been a bit of a bull in a china closet, ruffled a few feathers by rearranging furniture when that was “Union work.” But I refuse to back down on it.  I know that software teams operate better if everyone can see and hear each other.
• Lots of smart people:  Another non-negotiable in my book.  Box has it in spades, but not just in the engineering team.  Marketing, UX, and Publicity smarts are very high at Box.  There’s a healthy bar to clear for new hires:  we only hire people that wow someone.
• No dead weight: I can’t over-state how important it is to have people that do stuff at all levels in the organization.  No manager is simply a manager, they’re also a contributor, writing code, or creating wireframe mockups, or writing copy.  When people don’t promote away from doing actual work, you avoid having managers that are out of touch with what the real work is.  You also don’t spend a lot of your time explaining a good idea because people get it when they hear it.

What Box does great that is different:

• Box is fast.  We push a significant release to production every week, and minor bug fixes practically every day, so there’s a massive amount of discipline around automated QA, and around making sure things keep moving.   For big features, this means making sure the code is checked in by the previous week’s deadline, so that it can go through several rounds of testing before the rollout.  Any bugs found have to be fixed by another deadline, or they get backed out of the release.
• Box uses good tools – git, Gerrit, Jenkins: Frictionless branching for every bug fix is possible thanks to git.  A required code review on every single checkin is done courtesy of the army of developers self-policing and using Gerrit to manage the reviews.  Git’s branching (and the team’s intense discipline) also makes it possible to back out individual bug fixes, since each one is on a separate branch that’s been merged into the base.
• Box celebrates.  A lot.  When the sales team closes a big deal, a gong rings, everyone in the office hears it.  You stop for a second and clap, and you know the company is pulling in serious money.  Why do that to the guys writing code?  Because the code is what is making it possible for the sales team to sell.  When recruiting hires a new engineer, they ring a cowbell, and everyone cheers, because we all know how many interviews it takes to find someone special enough that they should be writing code at Box.
• Great food.  Snacks include fresh fruit, yogurt, granola, and nuts, and they never run out.  Sure they have chips and sugar like most places, but junk isn’t the only option, and the drink selection includes good stuff, like V8, Vitamin Water, fresh juice, and every kind of milk.  No need to run out to Starbucks to get a good cup of coffee at Box.  I’ve met more cross-org folks by toasting a bagel in the morning and introducing myself as the new guy on the Platform team.
• Subsidized gym membership.  I value exercise and fitness.  Like attracts like, so we have a lot of fit people.  It’s healthier.  There are some crazy fancy bikes leaning against the walls in the office.  There are rugby balls on people’s desks.  Sports are a part of social conversations.
• Caltrain pass.  Encouraging more people to walk or ride their bike to Caltrain, which also encourages fitness.  A side benefit of this is that I meet co-workers from other teams on the train, and have good conversations, learn what’s going on in other departments, and get to know other people at Box better.  Another side benefit: I avoid being parked on 101 trying to commute to work in a car.
• Box is enthusiastic about Scrum.  My boss and I introduced Agile at Box 5 weeks ago.  Yes, It only started after I got here.  But more than half of development was so excited about it, they decided that they wanted to try Scrum. Right. Then. Most teams starting turning things into Stories right away, and then breaking stories down to 3 point or less tasks.  See my post about what Guidewire does right about Agile to understand my thinking about Scrum and Agile.  I’m sure it will continue to evolve as I learn more.  Finer grain tasks means you track things at a more granular level, and know sooner when things are blocked.  It is working quite well for the 4 or so teams that are adopting it.  Very hard to say what all the impacts will be, since the process is young here.  But it is already making people understand more and learn more.  I’ll blog more about it in coming weeks.
• Box has energy and enthusiasm:  Sure, there is plenty of caffeine in the kitchen.  But there is more energy per person at Box than I’ve seen elsewhere.   Some of it comes from Aaron’s infectious energy.  He is loud and cheerful, and puts a smile on your face with his positive energy.   But there’s also a lot of energy flowing between teams.   Development and Operations sit close together.  Sales is banging on the gong.  Recruiting is hitting cowbells.  Site metrics show on the wall.  There is a lot going on, and that excitement fills the air, and makes everyone want to crank and deliver.
• Aaron gets tech:  Box’s CEO was a developer originally.  Sure, he’s handed in his checkin privs (I think), but he gets technology better than most CEOs, and he understands the massive value of a platform.  Unlike most companies, technology isn’t relegated to the basement, or the back of the office.  We aren’t excluded from strategic decisions.  Technology is a cruicial pillar of the company strategy.
• Marketing rocks:  It seems like every other week there is some knock-your-socks off news, and Box has clearly gotten into the mind of the tech media.  It is impressive to see how well the marketing team cranks on programs and really helps get the enthusiasm and high-energy of the company out there into the media.  Do we have relationships with every big tech rag?  I don’t know.   They all seem to cover Box though, and from my experience, that comes from spending time educating the analysts, the tech bloggers, the journalists.  I confess I don’t understand that side of the world as well as I’d like.  I’m a nerd, though I’m working with more marketing people at Box than I have before, and it is great.

It all adds up to a great culture at Box.

So, I’m having a blast at Box.  Yes, I am only 6 weeks into my employment here.  I’m sure there are (more) things I will spot that I think need improvement.  We’re already hard at work on several of them.   I’ll save some of them for later blog posts.  They are great challenges, and nothing that we can’t solve.  Until then, I’m learning a ton, and having a great time.  It has been an absolutely fantastic change for me.

What Guidewire does right about Agile

First off, Full disclosure: I used to work for Guidewire, and now I work for Box.  Both are fundamentally fantastic companies, with really smart people working at them.  If you’re an investor, you should feel lucky to have picked such an amazing team.    If you are interviewing with either for a development position, don’t be surprised if you get rejected.  They are both incredibly picky about who they hire, and rightfully so.  If you want high-performing teams, you have to make sure that not only are the people you hire smart, but that they fit culturally.  There is nothing worse than having that one person on the team that screws everything up and kills everyone else’s productivity.

But now that I am at Box, I can look back at what Guidewire’s own Agile development processes look like with a little bit more perspective.  In general Guidewire does a lot right.  More right than wrong.  But a blog post about what is perfect isn’t all that interesting.   So I propose here the 4 things I did wrong with Agile at Guidewire.

Take it with the proper grain of salt.  Most companies would be lucky to only have these 4 things wrong in their development processes.  Also note that I’m referring largely to the one team that I worked on.  Guidewire is big enough that different teams do agile differently.  Some use Kanban, others have decided they don’t do estimates at all.  Here’s the 4 things I’d change if I were still back at Guidewire, and I knew what I’ve learned just watching the teams I’ve ramped up on Agile at Box.

1. I would timebox sprints at 2 weeks.  Many team have moved to a Kanban rolling model that doesn’t force any endpoints.   It’s like a giant run-on sentence of a development cycle.  You just build and build and test and build and write more stuff, and ram in some extra features, and oh shit, we should do a retrospective sometime.  Sprints enforce discipline, and I don’t think I was forceful enough with the regular rhythm of all the rituals.  I just got sloppy.
2. I wasn’t disciplined about writing Stories with the team.  I’ve found the pattern:   As a <user>, I can < demonstrable thing>, so that <business value>  is a good forcing function.  INVEST is a good thing to think about as you’re writing stories.   My teams lost this discipline.  We suffered by having a lot of inter-related stories, and not being able to have any person jump on any work item.
3. I didn’t make the developers break down stories into tasks no bigger than a day.  One thing I’ve seen here at Box as we implement Scrum is that we have discipline to making the developer that chooses a story break it down into a bunch of 0.5 point, 1 point, and 2 point tasks.  OMG.  It makes a world of difference.  You can see actual progress every single day.   My sprint boards at Guidewire would sit with no changes for a week or more, because the “auto purge when Archiving” story was like 15 points, and the daily standup thus became rather meaningless.
4. I didn’t do a retrospective after every 2 weeks. That was a huge mistake too.  It almost sounds like I was just reproducing the Top 10 ways to screw up Scrum.

Okay, so I did a few things wrong.  Guidewire still manages to delver great software because the engineers have their hearts in the right place, and the company tries generally to do the right thing.   There’s a lot of adaptation going on, and I suspect that eventually the teams I was on there might adapt and figure out how to make these things happen that I wasn’t making happen.  Guys… I hope you at least try to put some of these processes in place.  I think your lives will be better for it.

I could go on for a while about what Guidewire does right as a company:

• Open environment
• egalitarian
• Great at testing / TDD
• Cares about every customer, deeply
• Super technical PM team

But Guidewire could be even better.    And yes, I take most of the blame for not seeing the problems with the agile process when I was at Guidewire.   I could have taken an agile seminar, or read one of the newer books on Agile, and made the realization that I needed to make the effort to push the team back to some of the core Scrum rituals.   But I didn’t.  20-20 hindsight is an amazing thing.

I’m happy to say that I’m not screwing these same things up now.   I’m probably screwing up different things that I’m not noticing.  The teams I’m coaching, and the team I’m the Product Owner for are actively pursuing all these Scrum rituals.  I am certain that some of the teams will make mistakes.  But I hope that I’m now more aware of how easy it is to fall away from these good practices, and I’ll help everyone be more vigilant.  It will be interesting to look back in 6 months and see if the teams at Box have fallen into some of the same Agile problems that I now see when I look back at my last 6 months at Guidewire.  I am hoping that we can avoid making the same mistakes.  We’ll make different ones.  I hope I have the wisdom to see them and course-correct.

Of course the good thing about Agile is that it accepts course-corrections.  Now’s the time Guidewire… think about pushing for some changes to get back the Agile discipline!  Get better.  Go Guidewire.

ID10t guide to Box API’s

Full disclosure: I’m working on the platform team here at Box.  As such, I figure it makes sense to post my own quick guide to using the Box API’s.  This is the most basic Idiots-guide type explanation, just to get you going and help you get your head around using the Box API’s.

To get started, go to http://developers.box.net .  Feel free to look around.  This is the developers documentation, not to be confused with the Developers Home page where Box runs developer contests.  It has links to the Developers Blog, and the Forum to ask questions on, as well as links to all the various API calls you can make.

The first thing you need is a Developer’s key from the Project Setup Page.  So head there and create your own “Application.”  Call it whatever you want.  My first one was called “PeterTest,”  because I’m so creative with names.  Cut and paste the API key that gets generated.   That’s yours.  It’s secret.  Don’t go sharing it with other people, as it will let them get into your Box Application and access your account.   But do copy and paste it into a text file somewhere handy at least for the next few minutes.  You’ll need it in the next  few steps.

If you are just gettting started, it helps to walk through the basic API call stack with just a browser window.   Click into the Get Ticket API Function page, and scroll down to the REST Request.   Copy and paste the https://www.box.net/api/&#8230;   line into a browser bar, and replace the ugly stuff after the equals sign with your API key that you have in your text file.  Load the page on your browser and you’ve got a response with an authentication ticket.  Depending on your browser, you may need to view source to see the XML that comes back.   Again, I recommend that you cut and paste the ticket part of the response into your text file.  I put mine on a separate line from my app_key.

Great.   Now you can move to the next step, and use that ticket and app_key to get an auth token.   Do the same basic steps:

1. Navigate to the API function you want to try (get_auth_token)
2. Copy and paste the https:// part out of the REST Request example
3. edit the request to put your own api_key, ticket, and any additional parameters you want to try
4. hit return and fetch the response

Once you have an auth_token, you can call any of the other API’s that you want to.  The pattern to do so is the same.   Just keep cutting and pasting, and changing the last parts of your URL calls.  I suggest you try the get_account_tree with the params[onelevel] set, after you’ve uploaded a few files into your Box account.  It is also good to try the get_comments, get_collaborators, as well as get_file_info.

After you do that, you’ll have a good idea of how you can start to write your own programs against the Box API’s.  Good luck!

Week one at Box

I thought I’d just remark on a couple things from my first week at Box.  These are just some initial impressions.  It is, after all, only my first week on the job here, so there is a lot going on around me that I have yet to grok.

The first thing I have to call out is the people here.   Everyone has just been fantastic.  From the guys on my team, who have been uber-helpful answering my barrage of annoying questions, to the folks I bumped into going to the Chase Corporate Challenge, to various BizDev and Sales folks that I’ve jumped into calls with or chatted with in the kitchen, the vibe is always one of excitement and intense purpose.   There is an air of get-shit-done everywhere.   And I’ve instantly felt like people listen to me, even though I’m mostly just the clueless new guy asking dumb questions.

The technology stack also looks very impressive.  There are a lot of well built dashboards, monitoring stats up on big screens, and good internal videos to explain the architecture.  It is a little intimidating and exciting to be trying to learn a new language, a new framework, poke around a lot more with git and gerrit, and learn all the dev processes at Box.  Of course many things are instantly familiar, (like Jira) but with some twists.  I need to dig in a lot more on how the whole promotion of code process works, as they’ve got a lot of gateways to slowly push releases out.  I haven’t worked at a company where the web site was the main business since my Della.com days, and thankfully the web has moved well past ASP and IIS since then.

I’m almost embarrassed how much a little technology makes my day every now and then.  After using the mac book Air 13 for a few days, moving this old laptop at home that I’m typing on feels heavy and clunky.  So does not having a 30″ screen, or that cool new Apple mouse that also works like a trackpad.  I do miss my standup desk, and Maria has already declared her love for my old one, so I have no hope of getting it back from her, and bringing it down to the Box office.  Doh!  maybe I shouldn’t have given it to her as I left Guidewire.

I ask guys on my team a lot of dumb questions,  including how to do some basic things on a Mac (can you believe I haven’t used a Mac for real work since my first Duo-dock back in the 90’s!).  I’ve also gotten some great advice from them (install Rapportive, so the company doesn’t need to maintain a “company directory” with everyone’s pictures in it)  Of course that only works because Box uses gmail as their corporate standard.  I’m also using screen, as well as vi a bunch more, since git and these (hmmm) dynamic languages seems to work well with really basic text editors.

It was great to hang out a bit with the Guidewire team at the Chase run Wednesday night.  I can tell that they miss me, but I’m glad everyone is very understanding and supportive of my move to new and exciting things.   I am quite sure that I’ll be working with Guidewire sooner, rather than later on a plugin to do ClaimCenter DMS on Box.   I’ll blog a bit about than when it actually comes to fruition.  Should be exciting.

Until then, I’ll keep trying to wrap my head around all the Box APIs, figure out how I can have the best impact at Box, and keep enjoying meeting lots of new folks, and working on new technologies.

Microsoft Copies Guidewire

Several months ago, Carson presented (yet again) at the JVM Language Summit.   Scott McKinney talked about our Open Types system, and Dana Lank also presented an example of that open type-system in action loading XML types on the fly, based on an XSD he created in front of the live audience.

The power of this technology was not lost on many in that audience.  It was certainly not lost on the Microsoft Language guru that was in attendance. Microsoft announced the availability of their own open type-system version of F# .   They call it by a slightly different name:  A Type Provider mechanism.   We think that this technology, first developed here at Guidewire is absolutely amazing.

For those of you that missed Dana’s presentation.  I’ll try to find a copy of the video of one of her demo’s somewhere and get it posted.   I don’t think Oracle filmed (or posted) the breakout sessions, so we’ll need to find one that Dana did internally at Guidewire.  The amazing thing is that there is no code generation, and the types are not evaluated dynamically.  You can very simply drop in an XSD into your classpath, and immediately, strongly typed have programmatic access to either parsing an XML based on that XSD’s elements and attributes, or you can create an XML construct that complies with that XSD.   It removes about 20 minutes of fiddling with installing CXF and code-generating a bunch of Java classes.   It is all just there.

So, it will be exciting to see what this technology does for F# as a language.  It may make it really into a Java killer of a language.  It will certainly boost F# developer’s productivity.