Roy Paterson can be credited for making our Eclipse integration as
great as it is. He's also a very fun guy, usually being one of the
masterminds behind the crazy antics around the office. When you hear
laughter in our cave, you can bet Roy's there. Whether he's juggling
with a wacky hat, or helping a customer with Code Collaborator, he's a
blast to have around!
What is your "Job Title"?
I think today I'll call myself "Lead Client Developer and Bear Suit Model"
Describe a typical day for you at the office.
I pick up Will at our carpool meetup at Barton Springs and then drive
to work. While my computer is starting up I fill my "Alien Crossing"
mug with water and fold the latest creation from my daily origami
tear-off calendar. I divide my day between writing new features,
fixing bugs, and helping customers. When I need a break I juggle a
bit. On slow days other hijinks ensue. Finally I switch my monitors
off and go home!
Where were you and what did you do before Smart Bear?
I graduated from school from the University of Texas at Austin, and
then worked for IBM for 5 long years.
How did you come to Smart Bear?
After years of job dissatisfaction and months of vacillating, I got
fed up with IBM and decided to look for another job. I found Smart
Bear within a week of searching Craigslist. Turns out you can find
all sorts of things on Craigslist...
What is your favorite thing about Smart Bear?
I love how close I am to our customers, and how quickly we turn around
fixes and feature requests. If there is a bug or a feature request I
get to hear it, and then I get to implement it and see it benefit our
customer very quickly. I love the fun atmosphere, coupled with a
successful company that solves a real need.
Any interesting stories during your time at Smart Bear?
In my job interview I promised that if hired I would juggle in the
bear suit at tradeshows. It turns out that I can't juggle in it
(can't see out of both eye-holes at the same time), but I love wearing the bear costume. It's really fun to show up as a ridiculous cartoon
character at dull tradeshows and rattle everybody up.
The best part is people assume I'm just some teenager we paid a couple
bucks to wear a costume, not one of the lead developers of the
product. Once I start talking to them and get technical they do a
double-take and exclaim "Wow, you *are* a smart bear!"
What are some of your favorite websites?
I read Austinist, XKCD, and Gizmodo. "There, I fixed it" is also great.
What are your favorite activities? Hobbies?
I've been sailing and juggling for many years. I'm very active in
Austin's local juggling community, and I travel and teach at juggling
festivals all over the US and in Europe.
Favorite music bands?
I'm an uncultured savage that doesn't like music.
Favorite spots in Austin?
My favorite spot is Barton Springs pool in the summer. I've spent many
a summer afternoon juggling and relaxing under the pecan trees, and
then taking a breath-taking dip in the cold water.
When a review is created (or new files are added to an existing review) from a Code Collaborator client tool, the client launches the user's browser to the review creation wizard (or review overview screen) where the real work is done. Browser launching varies from platform to platform. We use an open source library, BrowserLauncher2, to abstract away those platform dependencies. That worked great until a user emailed today to say, "I want to use Chrome on Linux as my browser, but Code Collaborator always launches Firefox". Time to dig in and get my hands dirty.
At its core, BrowserLauncher2 uses configuration files embedded in their jar to map from a browser name to a command line to invoke to launch it. Unfortunately, it does not appear to have a system property or other means of overriding (or augmenting) where it gets that configuration. If it did, we could just package up a new configuration file with our applications and be fine.*
I spent some time considering a patch that would enable overriding the defaults, but the project looks mostly dead, the HEAD of their CVS repository does not build cleanly, and their are no CVS tags for their releases, I decided it probably wasn't worth it. Instead I just repackaged the jar with the following extra configuration:
That's right, no explicit mention of Chrome. Linux already as at least three tools that allow users to configure their default browser. There was no need to add Chrome support directly. As an added benefit, we are future-proofed against new browsers making life inconvenient for our users.
If you want to have this functionality, you'll need Code Collaborator 5.0.5025 or newer (not available as of this writing) and run the following command (or variant):
ccollab set browser "GNOME open"
Make sure you have your chosen launcher configured to open the browser of your choice. We don't guarantee we'll support your browser, but if it works for you we won't try to stand in your way.
* Writing this, I realized that given the BrowserLauncher2 code is LGPL (including the properties files) and that any configuration we packaged would be derivative of those configuration, we would have to be careful how to package the configuration files so as to not encumber our entire application:
If your company is working to achieve CMMI level 3 or above, you probably already know that peer code reviews are required. They’re a really good idea anyway, but for CMMI (and a host of other environments, not to mention entire industries), you have to do them. And you have to provide proof that you did them, and then measure and continuously improve the results.
So how can you do peer code reviews without mountains of paperwork, tedious tracking, endless meetings, and other excruciating and inefficient tasks?
As a quick background for folks who aren’t doing the Capability Maturity Model Integration (CMMI) process models, they…
Require peer code reviews as a means to improve software products
Advocate the use of review data to improve the product creation process
Dictate that you measure and improve the return on investment (ROI) of reviews
Of course, the CMMI mandate to review code stands to reason: it’s much more efficient to find defects in the same cycle in which they are created, whether it’s requirements, design, coding, etc. And the Software Engineering Institute’s CMMI methodology is all about repeatable, measurable, efficient process that improves overall quality.
The necessary review process looks something like this:
Define a process and follow it consistently
Determine the process goals and decide what code review process you’re going to use
Assign roles to the participants
Conduct the reviews
Capture metrics about the review process
Conduct defect analysis, resolve defects, and resolve open issues
Document the review
Evaluate the review using the metrics you gathered, and use data to improve your overall software creation process.
Why on earth would you try to do all of these detailed tasks without software (like Code Collaborator, our code review tool) to help you automate the review creation, simplify communication, track results, and provide measurable data for reports?
A tool makes CMMI code reviews much easier and less painful than any other method:
You can configure the tool to collect the data so the engineers don’t have to be familiar with the CMMI peer review process, they just have to use the tools. The tool automatically enforces best practices and standardizes the process.
A tool gives direct proof that you’re following the prescribed process. Documented processes aren’t enough – tools provide a detailed audit trail to show that you actually did the work.
The tool automatically generates the measurements needed to continuously improve the process – details that are difficult to track manually like reviews conducted, defects found, and hours spent.
And of course, a tool like Code Collaborator automatically packages changed code for review, gives team members a quick way to communicate directly on the code itself, and lets you verify that bugs found are fixed… regardless of where team members are located.
Even if you’re not obligated to perform the rigorous CMMI requirements, you’ll still find a code review tool takes the pain out of code review and helps you improve software quality. Then your team can focus on something far more enjoyable… like writing code!
We have a varied work force here at Smart Bear. One of the developers grew up on a kibbutz. There are some jugglers and several soccer players. We even have a guy who is fluent in Esperanto.
And then there's Will. He's the kind of guy I refer to as an instigator. He's always game for anything. He is featured prominently in an entry on feeding the birds and was a key part of our success with water balloons.
It recently slipped out that he had taken on a new challenge: if someone presents him with edible food, he must eat it. So Brandon brought in a giant orange-colored donut and presented it to Will.
And, instigator that he is, Will proceeded to eat all of it. By himself, no less!
Not surprisingly, it took him all day to finish it. And we went out for sushi that day so he also had a full lunch.
But Will is a "can-do" kinda' guy, so he continued to work his way through it.
From the look on his face after finishing the final bite, however, I am wondering if he'll be as enthusiastic about the next food challenge that comes his way.
A question came in recently from a prospective customer that basically boiled down to this: "Is Code Collaborator a workgroup or enterprise code review tool?"
The answer is: you can use it either way, so it's both. ("It's a floor wax - it's a dessert topping! It's both! It's new Shimmer!" :-) )
Generally, though, we suggest that customers deploy as few Code Collaborator servers as necessary. The product scales well (some installations have 100s of simultaneous users) and fewer servers means fewer things to install and maintain.
Having a single server also makes it easier to do reporting across your entire organization.
As you add more teams to a server you increase the likelihood that two things will happen:
Not all teams will want to do code review in the same way. The differences can range from the specific data that are collected to the specific work flow rules that are used.
Not everyone is allowed to have access to all source code files that have been reviewed. Since Code Collaborator maintains a cache of all files that are reviewed, this becomes a potential security issue.
There are a whole host of features in Code Collaborator designed to help out.
Custom Fields are exactly what their name implies: custom data that you specify at both the review level and the defect level.
Role sets are used to define specific rights (e.g. "can mark defects fixed") and responsibilities (e.g. "must click Finished before a review is considered completed") for each review participant. Each user who is participating in a review is assigned a role for that review. We include a default set of roles with the product, but you can create multiple role sets and use them for different groups in your organization.
Review Templates are used to specify custom fields and a role set. When you create a review, you select the review template that Code Collaborator will use for that review, thereby controlling which custom fields are visible and which participant roles are available. We include a default review template with the product (which works well for many of our customers), so if you never create any additional templates then you won't have to select a template - Code Collaborator will just use the default template.
Groups are used to define subsets of the Code Collaborator users. You can use groups to model your organization's structure (e.g. "Bob works on the GUI team, Sam works on the firmware team") and/or project assignments (e.g. "Bob and Sam work on project XYZ, George works on project 123"). Groups can have sub-groups and each user can belong to more than one group. If you don't like the word "Group" you can specify a different string (e.g. "Project" or "Team" or whatever).
If you enable the Groups feature then each time a user creates a review, they'll have to specify which group to associate with the review (if a user only belongs to one group, then no option is given - that group is used by default).
There are several features for controlling access to the data in a review, but the most important is on the General settings screen in the administrative settings: Restrict Access to Review Content. There are four options.
Anyone - means just what it says, so essentially no access control
Group Based - only members of the group that is associated with the review can access its content
Participants - only the participants in the review can access its content
Participants and Group Based - to see the content of the review a user must be a participant in that review and a member of the group associated with that review.
So with the features listed above, you can install a single installation and then configure Code Collaborator to meet the needs of multiple development teams, even if they want to collect different data, or enforce different work flow rules. Using the Groups feature makes it easy to report on the reviews created by different teams and if security is an issue the access restrictions solve that problem.
Having said all that, there are situations where this is not enough. If you need a physical barrier, for example on a classified project where a team cannot share any network resources with other parts of the organization, then you'll need a separate Code Collaborator installation. You'll need to assign your licensed seats to the different Code Collaborator installations, but your account manager can help you with that.
Thanks to Lisa Wells, there is video instead of just audio! I super-imposed the slides over the recording, so it's sort of like being there. A few of the slides got munged a bit in the process, but they are mostly readable. One note: the video cuts off during the Q & A at the end - Lisa has the one hour Flip.
If you want to skip around, I've put together a table of contents:
Slide
Time
Topic
1
00:00
Alignment with Agile
35
18:43
Are the meetings necessary?
45
23:03
Code review without meetings
58
37:24
Efficient use of time
67
47:25
Social effects
78
55:15
Q & A
You might be wondering - what does this have to do with junior high school sex?
When I talk to software developers and the topic of pair programming is included, I always ask: "how many people here work in environments where at least 50% of the code is written in pairs?" The response is always less than 10%. Obie Fernandez, who I greatly respect, would not be surprised - he recently blogged about how pair programming is not for the masses.
And while I'm not an expert on pair programming, it seems to me that many more people talk about how great pair programming is than actually do pair programming.
Which is why during my presentation I commented that pair programming reminds me of junior high school gym class: all the boys in the locker room were talking about how great sex is but not many of them were actually having sex.
One of the members of the audience had a great response to that - it's pretty amusing so I put an excerpt of the video on YouTube:
Over the din of the lunch rush at EZ's we talked about, among other things, agile development, code review, and the constraints of working on large existing code bases. In the end he agreed that my presentation would make sense for an Agile Austin meeting, so I'm on the agenda for Tuesday evening, January 5, 2010.
It's a free event and if you arrive early enough there is usually pizza as well. :-)
The meeting starts at 6:00 PM and is in Microsoft's office on the second floor of:
Stonebridge Plaza One 9606 North Mopac Suite 200 Austin TX, 78759
I've been meaning to get to this for a while and finally had time this past weekend. Back in October Greg Wilson did an excellent presentation entitled: Bits of Evidence. The subtitle is: What We Actually Know About Software Development and Why We Believe It.
His central thesis is that in software engineering we tend to accept too much folklore as fact. We should instead insist on proof. And not just any proof - he argues for standards that match those of the rest of the scientific world.
One of his best examples is a quote from an article that Martin Fowler wrote for the July/August issue of IEEE Software:
[Using domain-specific languages] leads to two primary benefits. The first, and simplest, is improved programmer productivity.... The second... is... communication with domain experts.
Wilson points out that Fowler, who is one of the leading thinkers in software engineering, has made two significant claims without providing a single citation.
It's not that Wilson disputes the claims - he just wants to see the proof.
That's a reasonable request and Wilson goes on to provide several examples where proof is available to support or refute many of the ideas that developers take for granted about software engineering. His goal is to ultimately produce a book on the topic - more about that here.
The presentation slides are here. The audio (which has some rough spots) is here. Highly recommended.
