A Typical Developer DayPosted: January 30, 2008
Here’s a typical day from the perspective of a BillingCenter developer (link for LOLcat fans). Hopefully, it demonstrates some of my favorite things about the environment at Guidewire: emphasis on tests, Agile-style feedback, code branching, and an appetite for humility:
9:00: As I do each day before my commute, I pull code from the Stable branch to my team’s Active branch via a shell script. Every team has at least one Active branch on which they submit code changes and manage tests, and code from each of these Active branches is pushed to the Stable branch once a week. The Stable branch is our zero-test-break version of source code and a crown jewel of our company, with which we can release code to customers on a weekly basis… few non-Web2.0 companies can do this.
9:30-12:00: Since we completed our 2.0 feature cycle, we’ve shifted focus to refining existing functionality before we officially ship a more polished product. I am currently working on a story for refactoring the APIs for determining commission rates. This one comes from our Services professionals, who are a great driver of feature refinement. Reading through their correspondence, it looks like they had become confused by the half-dozen methods called
getCommissionRate() and about which method did what. This occasionally happens in large software projects, but frankly it’s embarrassing and definitely needs refactoring. I spend the rest of the morning thinking through the best way to organize a clean, refactored, and centralized method.
11:00-11:10: My full team stand for our daily sprint meeting, during which we briefly tell what we did the previous day and what we planned to do that day. At 10 devs, 3 PMs, 6 QA, and 1 documenter, my team has doubled since 1.0 development.
12:30-5:30: Having consulted with our Services people and my team lead, I’ve decided to push all commission rate-related logic into a configurable GScript method. This means that in addition to removing most of the Java implementations of
getCommissionRate(), I repackage logic from those Java methods to a file that is externally read-writable so that Services and customers will never again wonder which version of
getCommissionRate() does what.
Normally, QA is involved with the story from start to finish since there are tests to write before we consider ourselves done with the feature, but in the case of this refactor there were no new tests to write – thanks to TTD (test-driven development) and QA for test coverage.
5:30: I learn from our test harness, which had just completely a cycle, that I had broken a few tests with my most recent code check-in. From the snapshot stack traces, the fix looks fairly easy. Usually, I would quickly submit a fix before finishing my work day, but it’s time for our weekly Thirsty Thursday social hour. This is always a good time to catch up with coworkers and discuss what’s new with, say, GScript or Studio (internally developed IDE for GScript and webpage editing) – we tend to keep talking about software and Guidewire except over beers.