General


We recently wrapped up another hackathon. Like I did last summer, I spent my time in javascript. This time, I learned a few things about the key codes browsers send to javascript event handlers when non-alphanumeric keys are pressed.

First, in the modern browsers I tested (FF, Chrome, and (ick) IE9) the forward-slash key is registered as a key code of 191. This surprised me because the ASCII code is 47.

Along the same lines, the question mark key is registered as 191 with a shiftKey value of true. Again, I’d have expected the ASCII code of 63.

Here’s the curve ball in the whole thing. The one really random non-conforming browser is Firefox, which registers the question mark key as a key code of 0 (zero) with a shiftKey value of true. Shame on me for thinking IE would be the oddball.

Unlike the last time I spent time hackathoning in javascript, this project was handled all along with the intent of putting it into production. Keep an eye out for something cool involving the keyboard soon in Rally.

IntelliJ is an awesome IDE from JetBrains. jconsole is a powerful tool for examining the state of an executing JVM. When you’re debugging JVM code in IntelliJ, you might find that jconsole can’t connect to your JVM while you’re sitting on a breakpoint. This is because the default breakpoint behavior in IntelliJ is to stop the whole VM, not just the thread that’s sitting on the breakpoint. If you try to connect jconsole to the JVM in this state, it will time out.

This is easy to fix:
1. Right click on your breakpoint and choose “Properties”
2. Change the suspend policy from “All” to “Thread”

“…and you’re done kid.” Imagine I said that in a Boston accent.

You can now connect to the JVM while sitting on that breakpoint. Problem solved.

It’s that time again:  Hackathon.  During Hackathon, all the rules go out the window and we can work on whatever we personally believe to be beneficial to Rally. For example, one group is working on Rally Mobile, another is working on editable detail pages (which sounds like something Willy Wonka might concoct), and other teams are working on underground improvements to make the overall Rally experience better.


This December, Hackathon will be a little different:  instead of the normal 5 days, we’ll have from December 8th through holiday break.  With five days, a developer can build a decent proof of concept. But the gap between a proof of concept and something that can be released to production can be substantial; making it difficult for our ideas to be fully realized. Having around 12 working days on a project might mean that more of our code could be tested and ready to be placed into the product. We can come up with the right way to code, rather than the fastest way to get our ideas across. Our Hackathons could become more like Google’s ‘do a barrel roll’ or Google Labs, fun Easter eggs or helpful tools that impact the customer first hand.  The fact is, with so much time to work on our own projects at once, the company will benefit one way or another.

This Hackathon, Garston and I are continuing a project I started a couple weeks ago for the User Experience team. For the last month and a half I have been researching improvements to the infamous story splitting screen in Rally (#3 on Rally Ideas).  I have read comments and suggestions on improvements, met with agile coaches and technical account managers on how they recommend using the feature and what improvements they would make, conducted customer calls on the use of the feature, and created designs. My Hackathon idea is to build a lightweight app that I can use to validate with our users. If Garston and I make great progress, we may even have something fully tested and validated, and ready to replace the existing screen.
At the end of December or the beginning of January, our company will have its bi-weekly Engineering demo. My guess is that this demo will be one of the most attended of the year, because this demo will have an overview of what we have been working on for the last three weeks. People will be excited, because when you let creative people do what they want, they usually come up with some pretty bad-ass stuff. And maybe, just maybe, our own customers will get their “Christmas wish” from the work that Garston and I do this Hackathon.

Hi, I’m Tom; I’m an engineer at Rally.  In Raleigh.  (Say that out loud; you have no idea how much confusion it causes.)   Anyway, that makes me one of these exceptions.  As pointed out, our engineering process is optimized to take advantage of high-bandwidth communication.  This is implemented via a highly configurable shared physical space – which is great for a collocated team.  But, challenges arise when incorporating remote team members into this environment.

  • Conversations take place away from technology: When a thought occurs, not many people want to hold their tongue until they are next to a computer, have set up a call, got a mic plugged in, etc., etc…
  • Technology can be a pain in the rear: There’s not enough bandwidth.  The camera is crappy or isn’t configured correctly.   People aren’t logged in, or their contact info isn’t up to date.  Tech helps, but it’s annoying when it’s hard to use.
  • Decisions are reached offline: People are passionate about their work, and they’ll talk about it.  Opinions are formed, decisions are reached, collaboration is…collaborized?   Coming in late and getting the Reader’s Digest version is not the same.
  • Lower communication bandwidth: Not everyone can be on camera at the same time.   Remote attendees can miss things like body language, audience feedback, or obscene gestures.  Long pauses can mean you’ve somehow offended someone, or that the ice cream truck is outside and everyone took a break.
  • Time zone differences: The start of my workday is 2 hours before Boulder’s.  That gives us about 5-6 hours of quality time a day.

So why do we bother?  What does Rally gain from distributing teams?

  • Knowledge sharing: In my opinion, this is the big one.  Distributed teams help prevent knowledge silos.
  • Larger talent pool: There are some talented engineers that won’t or can’t move to Boulder.
  • Longer coverage window: The work hours for the engineers covers more of the day.
  • Compartmentalization of facilities impact: If a site needs to renovate – or there is a fire alarm – or a network outage – then all of engineering is not blocked.
  • Organizational maturity: Rally is growing fast.   We’re about to pass 300 employees – not yet a global empire, but we’re getting there.   We still hire in Boulder, but the competition for engineers is stepping up.  The office space on Walnut street is filling up.   Geographic scalability is not critical for us yet – but it will be.  We’re developing our capability to scale before we absolutely have to have it.

I agree with 99% of Ryan’s post regarding the shared engineering space.  For teams that have the luxury of collocation: get into the office!   It’s worth it.  The 1% I’d like to clarify may be academic: that the shared space is essential to the culture.   There is no disputing it requires more effort to participate through the thin pipe of a remote connection; but as the organization changes and it starts to make business sense to include remote members, the team has to either give up the culture (bad!) or find ways to make it work (good!).  I’ve been most pleased with Rally and its ability include me; it’s not without some rough edges (see the challenges above) but we’re committed to smoothing them out.

The important thing is that this is what we do.  We deliver enterprise Agile transformation, and we deliver it to organizations that are many times our size.  They have reached a size where geographic scalability is critical; they have to have distributed teams.  We strive to be the exemplar for our customers.   We demonstrate that Agile is effective for large organizations, and we practice what we preach.

Lately a few of us have been blogging about starting to work here, or having been here since pretty much day 0, and since I’ve just celebrated my first anniversary as a Rally employee I thought I’d pitch in my tuppence.

While I wouldn’t change things for a minute, in hindsight it was kind of a [ ballsy | foolhardy | bloody daft ** delete as applicable ] move to take the job here. You see, I hadn’t actually set foot in Colorado prior to moving, nor did I really know anyone who lived here. In fact I had lived and worked outside the States for the best part of twenty years. I hadn’t even met anyone from Rally in person prior to my first day on the job, although I did have a bunch of long phone/video calls during the interview cycle that give me a feel for what to expect. Saying that, I really had no grasp on what to expect from an American job and was frankly terrified on the first drive in to work. Normally I’d cycle to work, but I wanted to make sure I didn’t get lost, turn up sweaty, be late because of a bit of glass in my tire or who knows what… Unsurprisingly, the rules of irony applied and the route to work that day was gridlocked (in Boulder terms – comparable to a light traffic day in a normal city) and I ended up late. I thought that was a less than stellar first impression, but it seemed this company was genuinely different to those I’d worked for in the past. People actually understood things didn’t always go according to plan and it was only A Big Deal to me. They got me settled in and shown around, set me up with a mentor and I felt welcomed into a big circle of friends. I was already enamored with the Colorado climate after only a few days in country, so this job was looking like the icing on the cake.

Things were looking even better when I discovered that people really do have mad foosball skills and it wasn’t just a clever selling point in a job description. After being humbled a few times, and sampling the wares from the kegerator I started to relax and remember some of the techniques I had picked up in a misspent youth and was able to score the odd goal.

Those first few weeks are mainly a blur, however I very clearly remember being somewhat awed by the calibre of people I was working with. While I’ve had the pleasure of working with some _very_ smart cats in my career, I had never worked with so many all at the same time. It must be a similar feeling for a boxer stepping up a weight class, or a baseball player being called up to the majors. For a long time I felt like the most stupid person in the room. I still am impressed by the team, but I do feel part of it and I no longer worry that I’ll fall completely by the wayside like I did at the beginning. If nothing else, the team is great at helping people learn and better themselves so I can only get better at what I do.

Just as I suspected from my first day, I love my job. I have a hard time leaving work at a decent hour and am always struggling with the work/life balance that’s one of our core company values. Sometimes I’m staying to work on a problem with a browser test, or I’ve been in a plethora of meetings and want to make some headway on some tasks while the office is quiet, other times I’m shooting the breeze with a colleague who I haven’t had much time to talk to during normal working hours. But I think that the main reason I find it hard to leave is because I’ve got a job that I’m happy to do. It doesn’t feel like work; I get to hang out with a great crowd, have fun and solve problems that interest me. Sure, it’s not all sweetness & light, rainbows & unicorns. Of course there are some conflicts and debates, but we all are able to contribute and be heard.

tl;dr – zOMG!!!!!!!!111 Best. Job. Evar.

p.s. Wayne, thanks for the title.

It’s true. I’ve been working at Rally for over eight years. Yeah, I know. I should have posted something on the blog long ago, but there’s no better time to start than the present, right?

Rally took a pretty big gamble on me. When I was hired as a developer, I had just graduated from CU and had never written a line of production code. I had written code, but most of it was writing test automation in SQABasic (*shudder*), VB, and Java and at Rational Software. Luckily, I knew a couple of the members of the Rally (then F4Tech) engineering team at the time, and got my foot in the door by applying for an automated testing position. During the interview process, I was asked what I really wanted to do, and I replied that my true passion was in development. The rest, as they say, is history.

I had no choice but to learn fast. We were all learning and exploring various technologies, not to mention trying to figure out how to get good at agile software development. Still, I had to get up to speed on J2EE and web technologies in general. We were also using WebLogic Portal at the time, which had it’s own set of tools and conventions. The trial by fire approach worked well for me, and over time I increased my depth and mastery of web application development and testing.

Over the years, I’ve had the pleasure of working on all areas of the stack and on many features that our customers know and, well, mostly love. Most recently, I worked on the new menus that replaced the ones that I wrote years ago. And while it is a little humbling to see my some of my old code featured on some of our “what not to do” blog posts, I appreciate the opportunity to reflect on how far I’ve come in both skill and experience.

Rally has truly enabled me to create my own reality. From humble beginnings, I am now a development manager and work with others to both shape and realize the architectural vision of our products. All the while, I am still able to immerse myself in code on a regular basis and continue to create new and exciting features for our customers.

It has been an amazing eight years. Here’s to many more.

We’re changing to a new feed URL. If you subscribed to our RSS/Atom feed using a reader then you’ll need to drop the feed and resubscribe.

Apologies for the hassle and thank you for reading.