Planet Atlassian

Agile With A Remote Product Owner

2009-07-02T18:11:11+00:00

We Are From Mars

All agile methodologies stress the need of co-locating development with the customer's representative - the Product Owner - or at least, having them in close proximity - both in time and in space.

Our team seems to be the exact opposite of what "the agile way" requires - we are located on the other side of the planet (Gdansk, Poland) from the company headquarters (Sydney, Australia). This means we could just as well be located on Mars. Actually, one could argue that outside of the narrow communication windows (early morning and late at night), communication latency between Sydney and Mars is smaller than the one between us and our Product Owner. Yet - we still manage to work in an agile way.

Talking To Each Other

How do we do it? First of all, we utilise high-bandwidth communication opportunities as much as possible. We have a local Product Owner proxy (that would be me), who talks to the Product Owner regularly, at predefined times and at least once a week. Also, if the out-of-band need arises, ad-hoc meetings are scheduled. Skype (or some equivalent technology) is your friend here, as well as Instant Messaging systems, such as Jabber. I cannot stress this enough - talking to each other in real-time is the most important and most effective way to communicate. I do not think it would be possible for us to work without it.

Technology Helps

But that is not all. For us, the second most important communication method (and tool) is JIRA - and it does the job just fine in its plain, out-of-the-box form. We use pretty much a stock JIRA setup, with just two custom fields added (both reflecting standard Scrum practices) - one called "backlog order", used for prioritizing user stories (a fancy word for "new feature or improvement"), the other called "story points" - for estimating the "size" of the user story. That suffices all our needs for making sure both the PO and us know what has to be done and how much delivering the requested feature is going to cost (after all, the effort estimates translates almost linearly into monetary costs). We also use the GreenHopper JIRA plugin to provide "virtual story cards", instead of maintaining our user stories on pieces of paper, to make our life easier when it comes to copying the outcomes of our planning sessions to JIRA. But for day-to-day ticket management, we just use JIRA. Or more properly: one of us (that would be me again) is using JIRA, everybody else is just moving around the actual paper story cards on the cork board, which is a central part of our workspace.

What about the communication in the other direction? What if a Product Owner needs to describe some story to us, and words are not enough? Sometimes the Product Owner will want to draw a mockup of the user interface he has in mind. Here is where the Balsamiq Mockups tool is very helpful. It is a Confluence plugin, which lets you draw diagrams right there in the Confluence page, and share it with whoever you want to communicate with. We would typically edit the diagrams in-place and simply comment on them until everybody is satisfied with the resulting sketch of the user interface to be delivered.

Delivery

How does the Product Owner know we are doing what he wanted us to do?

First of all, just as the Scrum methodology requires, we have a proper (internal) release every two weeks. The official builds are published in an externally accessible place for everybody to download and try it out - this gives us a way to regularly demo our progress and provides a way for the Product Owner to correct our course (e.g. whenever we stray from what has been planned or whenever the plan needs to be changed due to external circumstances).

Second - our Bamboo-based automated build system lets the Product Owner download and use the snapshot of our work every day - the snapshot may be barely usable, but typically it is in a good enough shape to let the Product Owner try new features as they are delivered.

Remote Dogfooding

We regularly practice dogfooding, using our product regularly on a daily basis. Almost every nightly snapshot is taken and used by each team member every morning. So if we happen to have a bug, we are quite likely to intercept it before the official version of the product is released. Also, if some user interface elements are awkward to use, or somebody has a bright idea for improving it, we are able to try multiple solutions and pick the best one - simply because we use our own software for our day-to-day work.

But in order to get even better feedback, developers in the Sydney office should also dogfood our software and give us feedback. Achieving sufficient levels of internal adoption requires a bit of advertising from the Product Owner, and regular presentations of cool new features that the product provides, so that folks in Sydney have a reason to bother installing our stuff.

Separation Of Responsibilities

The last thing that is important for a remote team and the Product Owner working with it is a separation of responsibilities. In our case, the Product Owner is only responsible for prioritizing features and controlling if they are delivered as promised. Planning and implementation are left to us. Also - all bug reports are handled locally by the team, as a part of the Quality Assurance process - we are solely responsible for keeping the product in good shape and the Product Owner does not interfere with that.

Another important rule we follow, is that the team's effort estimations are final. The Product Owner (or anybody else) does not even attempt to question them, trusting our judgement - in true agile spirit.

Make Your Code Agile: Refactoring

2009-07-02T17:47:29+00:00

First, my definition of refactoring:

Refactoring is improving code without changing the features it implements.

That's all.

If you're refactoring, you're not fixing bugs, you're not improving performance and you not increasing robustness. Refactoring is simply improving the design of the code, while ensuring that it still works the same, warts and all.

Pointy haired bosses the world over froth at the mouth to hear such things. Veins pop out in their temples. You mean the business value of the software stays the same but the cost to the business goes up? I didn't say that.

If you measure business value only in terms of features you have today, then you can end up deep in technical debt; you can add features today in such a way that features tomorrow cost more and more. The value of refactoring is wholly contained in the future ability of programmers to comprehend and modify the code. It's called maintainability, but that's a boring word, so let's call it Agility. Mmmm, sexy. Well-factored code is agile code because it's better able to change.

In economic terms, refactoring is an investment, or the repayment of a debt. It's only worth doing over a time frame when the interest payments or repayments (in the form of ongoing productivity gains) compound to exceed the time invested. Fingers crossed the business or project sponsor is also planning over such time frames.

The term refactoring comes from mathematics. You may remember your high school algebra:

2x² + 10x

Stay with me! No glazing over! If you refactor the expression, extracting the common factor, 2x, you get:

2x . (x+5)

Sometimes it's hard to spot the common factors, in both mathematics and programming, and it can certainly be done poorly. More on that later.

Like most powerful techniques in software development, the purpose of refactoring is controlling complexity.

Complexity is bad, mmmkay. Complexity is evil.

I was fortunate enough to be chatting about project complexity with the legendary Dave Thomas (OTI, Eclipse) at JAOO Sydney in May. He nailed it: "kLOC kills". Complexity and scale in codebases is a major contributor to schedule blowouts, poor velocity and excessive development cost. Complexity is a kitten killer from way back.

Fred Brooks discusses two categories of complexity. Essential complexity and accidental complexity.

Essential complexity is the complexity of the domain. In NASA software, there's no escaping rocket science. You can isolate and divide essential complexity but you can never remove it. Essential complexity belongs to the problem. By contrast, accidental complexity is an artefact of the systems, languages, frameworks you're using. In principle it can be reduced by changing the system. Accidental complexity belongs to the solution. Refactoring reduces accidental complexity.

If you don't have much experience with it and you're looking for some concrete tutorials on refactoring, I suggest you start with Martin Fowler's seminal book Refactoring. Fowler also maintains a catalog of refactoring recipes with an Object Oriented flavour.

One of the most basic techniques is Extract Method which all decent IDEs can do automatically. You know you need Extract Method if you have a multi-page method with a sequence of of comment blocks which look like this: Now that we have the InductionActuator, look up the FluxCapacitor.... Doing it manually means snipping out a logical sequence of code and pasting it into a new, small, well-named method, stitching the local variables used from the originating context into parameters to the method. If this is hard due to sloppy scoping or too many variables, you may consider Introducing a Field from a local variable.

The inner loop of agile development should go like this: Red, Green, Refactor. Red means you have a test which is not passing. Getting the test to pass is the next step. Green means you are passing all tests. Refactor means... refactor.

Even if you're a good agile developer, doing things as simply as possible, complexity and duplication of common factors creeps in while you're trying to pass tests. Everybody hacks. Everyone copies and pastes. This is fine as long as you go back and refactor when you've got the green bar. Sometimes you may need to avoid mentioning this to PHBs, for their own good. Shhh!

Unit tests are really important for refactoring. If you're not doing unit testing you've got a long way to go. A good unit test suite is a necessary precondition for confident, aggressive refactoring. And IMHO a good test system is a necessary precondition for confident, aggressive, automated refactoring. These preconditions can present a quandary for some developers. Legacy systems often have no effective automated tests. And since they're often composed entirely of spaghetti, they need to be refactored. It's a chicken and egg situation, where do you start? All I can say here is you start small.

Refactoritis

Can you have too much refactoring? Absolutely. If you're somewhere around middle-stage zealotry for this refactoring stuff, you may not be in danger of copy+pasting your way to a big ball of mud, but you may fall prone to exceed the safe working abstraction load of your language or go too far beyond the idioms of your team's codebase or comfort.

Every language has limits imposed by its design and implementation. In Java and C#, for example, the limits are seen by many in the dynamic languages camps to be too much to bear. For example, say you're refactoring some Java or C# code. You might create a new interface with a few alternate concrete implementations and, whereas before you had two methods on a concrete class and a few big if-else blocks, after refactoring you might have three files and more actual lines of source code. It can be somewhat subjective but sometimes you may have more complexity even though you've removed duplication!

If this happens you have fallen asleep on the refactoring train and missed your station. Often you should just roll back the code and go write a feature. Some duplication is easy to see and cope with, especially if it can fit on one screen and any reader can see the pattern. In other languages, Lisp comes to mind, there are constructs (like macros) which allow you to encapsulate expressions that cannot be elegantly factored in, say, Java. Disclaimer: IANALN; I Am Not A Lisp Nerd.

So the expressiveness of the language can constrain refactorability. Another way of saying this is that the language contains accidental complexity and only factoring out the language can remove that complexity. I should say here that I have recently found Groovy to be a great candidate for doing this on Java projects.

As a more concrete example, lexical closures are a great way of implementing things like the new for loop (for each) introduced in Java 1.5 and functor frameworks that employ anonymous inner classes in Java for similar purposes (e.g. composable transformers, ad hoc iterator delegators instead of explicit looping) often feel too cumbersome compared to most closure implementations. So you just have to suffer the duplication and code bulk.

So in summary, Red, Green, Refactor, don't go overboard and be aware when your language makes capturing factors you see in your system worse. Kill complexity before it kills you.

If you're interested I'll be telling war stories and going into some side issues over on my personal blog.

Democracy at work

2009-07-02T01:30:40+00:00

As some of you may know, I grew up in Birmingham, Alabama. Alabama is a pretty conservative state, and it's liquour laws have always matched that reputation. There are still some dry counties, hard liquor is regulated, taxed and distributed by the Alabama Beverage Commission, and for my entire lifetime, no beer over 6% alcohol could be sold inside the state. Now, it's no Utah, but this restriction meant that there was a lot of great beer I never had the opportunity try until I left Alabama: Chimay, Delirium Tremens, Duvel, Orval, lots of Double IPAs and bocks, some North Coast Beers, some Rogue Ales, and hundreds more.

For the last five years, an organization called Free the Hops has been working to pass legislation to change the beer limitations. And after half a decade of hard work, they got the the bill through Alabama's dysfunctional legislature this Spring. And on May 22, 2009, Gov. Bob Riley signed the bill into law.

Within days, gourmet beer was appearing all over Birmingham. (I know, because I was following the Free the Hops Twitter feed). It was amazing to watch: "Duvel, Orval, and Delerium Tremens have been confirmed." "Huge shipment of new beers expected tomorrow at Western." "Every Piggly Wiggly in metro Birmingham will be stocked with new good beer tomorrow." It was like that episode in the Simpsons when they repealed prohibition in Springfield and the trucks started rolling in minutes later. It was almost that fast.

Sure, some might say gourmet beer is a trivial example, but I learned two lessons from this. First, it was so gratifying to watch a group of citizen activists bootstrap their organization, garner support, and then fully achieve their goal. They knew how to work inside the system, the collected the right set of sponsors, and they kept their constituency informed, motivated and active using modern social technology.

Second, I'm not sure I've ever seen a more direct and immediate response to regulatory change. And it impressed on me again that government policies like these matter, whether at the local, state or federal level. There are tons of them and they're complicated, but they have concrete and meaningful effects on how we live our lives. The "government is the problem", "regulations are burdensome", "stay out of my business" knee-jerk response (besides often being hypocritical) is the wrong one. Regulations and taxes are the tools of government. The struggle is to make sure they exert their influence for good, not ill.

But anyone, for once, the good guys won. And I'll raise a pint of delicious beer in their honor next time I visit Alabama. Cheers!

Help us Integrate Confluence with Alfresco

2009-07-02T01:10:58+00:00

At Atlassian we're always looking for ways to expand the utility and functionality of our products. Sometimes this means we develop that code ourselves, and sometimes it means our community fills in the blanks. Such is the case with a new integration we've been working on with Alfresco, an open-source content management company, and Sourcesense, a mutual partner of Atlassian's and Alfresco's. In a nutshell, we're integrating Alfresco with Confluence to bring OpenSearch to Confluence wiki pages and to embed Alfresco-stored documents into Confluence, among other things.

One of the best things about this integration is that it speaks to both the power of Alfresco's open-source code and Atlassian's open APIs: the integration was started without any formal communication between the three companies. All the more reason to add another party to the mix: YOU!

While the integration is still a bit rough around the edges, we're inviting you to get involved and take the integration in the directions that you'd like to see. We're basing the initial integration on the new CMIS (Content Management Interoperability Services) standard, which means that not only can we build a range of new functionalities on top of the baseline integration, but we can also extend the integration to a diverse range of different technologies.

We've Accomplished So Much Already

The current Alfresco Plugin for Confluence provides a set of custom macros that enable Confluence wiki pages to display or embed Alfresco documents or document metadata through ID reference, Path reference or CMIS Search Query. The expectation is that we can provide a seamless experience to users of both platforms:

Search integration within Alfresco: By adding OpenSearch capabilities to Confluence, Alfresco is now able to aggregate search results from Confluence wiki pages and the Alfresco repository. So, for example, a user logged into Alfresco will be able to retrieve data from documents hosted in an Alfresco repository and any Confluence page she's got access to. This is a good example of what open standards and extensible systems can offer.

New macros for Confluence, providing wiki users with the ability to interact with an Alfresco repository in a number of ways, such as:
- Browse an Alfresco repository
- Reference (link) and embed (display directly) documents stored in Alfresco
- Build custom reports (such as listing documents that match specified criteria) by running queries against the Alfresco repositories

Use Web Scripts or CMIS: As an added bonus, macros are implemented using either Alfresco-specific technologies such as Web Scripts or a pure standard-based approach (CMIS). The Web Scripts technology is very, very cool and opens the door to do some interesting new capabilities for Confluence.

This is only the beginning

Even as I type this, an email has hit my inbox noting that new features, like the ability to pull Alfresco Share (Alfresco's collaboration application) site activities into Confluence via an Atom feed, have been added. We'd love to have you help us figure out where to take this integration, and to fill in pieces you think are missing. That's the benefit of open standards and open source: Confluence can be even more than Atlassian envisions.

We're hosting the project on Google Code: http://code.google.com/p/confluence-alfresco/. Please stop by and get involved.

UPDATE
You can also get SSO w/ Crowd for your Alfresco install:
http://code.google.com/p/alfresco-crowd-security/

Agile Project Management With Virtual Index Cards

2009-06-30T16:26:23+00:00

Index Cards have become an indispensable tool for a software development team practicing agile. There are a host of good sites with information on strategies for and benefits of utilizing index cards.

Agile teams use Index Cards for a variety of reasons, including:

helping with iteration planning
assigning tasks and then tracking developer assignments
recording task estimates
as one component of the team's Information Radiator.
reminders of the conversations between customers and developers around the definition of user stories.

The cards are an excellent visual representation of the health of the iteration. A majority of cards still in the "to do" with the end of an iteration pending usually means the team is behind schedule. A scarcity of cards means the developers will soon run out of tasks and so the backlog had better be up to date. Cards also work well as a great tool for facilitating the assigning of work (more specifically, allowing developers to assign themselves individual tasks). On the JIRA Studio team at Atlassian, back in "Ye Olden Days" (circa 2008) we used to use actual physical index cards, stuck to the team white board with blu tack. The use of physical index cards does have drawbacks:

Duplication of effort
Data from cards and issue tracker being out of synch
Bad handwriting leading to incorrect implementations
Tons of old index cards lying around

We now use virtual index cards, thanks to the magic of Greenhopper, an agile planning tool that is now bundled free with JIRA Studio:

Greenhopper is key to being able to do agile project management. We use the virtual cards for the traditional tasks of iteration planning, capturing requirements, and capturing acceptance criteria. The use of virtual cards allows for all of the functionality and advantages of physical cards, with the added advantage of better communication, and instant updates. Developers still "pick" their cards off the task board, track work on the cards, and place them in the "done" column when complete.

The JIRA Studio team was not a distributed team when we made the change to using the Greenhopper plugin exclusively. But now that one member is on another continent, the benefit of virtual cards to help with communication has grown even greater. Our Information Radiator is created with the virtual card wall displayed on a large monitor which also shows the current build status. Everyone on the local team can glance at the monitor for a visual representation of the health of the build and of the iteration, while the remote team member can view the exact same information in his web browser.

The synchronization of data is by far and away the biggest advantage of virtual cards, as an instant update of all information occurs whenever a card is updated. No more does a task get ignored due to a stray mark on the card. No longer does a developer waste time entering the same data onto the card and into JIRA. And the Team Lead no longer spends 30 minutes transcribing cards into JIRA issues or copying JIRA tasks onto cards in his chicken-scratch handwriting.

Greenhopper is integrated with JIRA Studio (and available as a plug-in for JIRA), so changes to a card are reflected in the JIRA issue, and vice versa. Moving the card to a new iteration, or new column on the board is reflected in the JIRA Issue. Changing the JIRA issue status to Assigned or Resolved immediately moves the card into the correct column on the Information Radiator. Almost as valuable is the ability to have multiple views of the information, without having to continually move physical cards. The cards can be viewed as a task board or a planning board, and sorted by priority, assignee, or a host of metrics.

Last, but definitely not least, the use of virtual cards mitigates a few of the dangers of agile.

Watch Ted talk about Virtual Index Cards with GreenHopper

Watch more videos on agile software development inside Atlassian

FishEye 2 and Crucible 2 released!

2009-06-30T15:03:04+00:00

I am very excited to announce the release of FishEye 2 and Crucible 2. Both of these products have undergone a complete UI makeover with improved usability and productivity features focused on agile development. FishEye and Crucible help you explore your source code and conduct code reviews that actually work.

After announcing the betas of both products at Atlassian Summit about a month ago, we had several hundred people download and try it, many of which provided us with valuable feedback. Check out the new features below and download the latest version to upgrade or try a free 30-day evaluation.

FishEye 2: Explore your source

FishEye, our source code repository browser, has add a whole new dimension for looking at the activity in your repository by focusing on the people that contribute to your code and letting you follow what they are doing.

View all activity - Keep tabs on the people and source code you care about.
Follow people that matter - Follow any user or committer within your source code repository.
Explore your source - Search, navigate and report on your source code from any browser.
Collaborate with your team - Share source code with your team. Add code insight to your existing tools, like JIRA and Crucible.

Crucible 2: Code review that works!

Crucible, our peer code review tool, has also taken a major leap forward introducing the concept of "iterative code review". Your development environment is constantly changing, and that should not to get in the way of an effective review process.

Productive code review - Simple, fast review creation. Keyboard navigation, display preferences, inline comments.
Fit your review process - Post-commit reviews from Subversion, Perforce, CVS, Git and ClearCase. Pre-commit from anything.
Iterative reviews - Code. Review. Code. Review ... review is usually not the last step.
Integrate with your toolset - Plays well with others. FishEye, JIRA, Eclipse, IntelliJ or roll your own with REST API or plugin framework.

Join us for a webinar

If you would like to learn more, please join us for a product webinar on July 15, 2009. There will be two session both covering the following:

Review latest features of FishEye
Review latest features of Crucible
Provide demo of both products
Answer any questions you have

Wed, July 15, 2009 8:00 AM - 9:00 AM PST
Wed, July 15, 2009 4:00 PM - 5:00 PM PST

Star Trek

2009-06-30T06:34:32+00:00

In an effort to keep my geek credentials in good standing, I saw the new Star Trek movie on Friday. (My license was almost revoked when I failed to see either Wolverine or Watchmen this spring.) Short review: Star Trek was excellent and I'll probably see it again in the theater if I can. I can say without reservation that, no matter who you are and what your previously level of commitment to Star Trek might be, you should absolutely go see it if you haven't done so already.

I've always been what I would call a mild Star Trek fan. As a kid, I found the original series too cheesy to take seriously. I enjoyed the Next Generation when it was on TV. I found Deep Space 9 too obscure and inconsistent to follow, and found the cast of Voyager insufferable. I though Enterprise (apart from the god awful theme-song) was better than most people gave it credit for. But I am totally, 100% sold on this new universe, though. Here are some reasons why: (Spoilers follow, so consider yourself warned.)

Things that were awesome

The beginning

The first six minutes of the movie were just unbelievable. In it's pure, emotional impact, it reminded me of the intro to the premiere episode of Lost or some of the best of Joss Whedon's writing. The movie grabs you and does not let go.

The cast

Much has been written about this already, but I'll just say that every single actor is perfect, and absolutely nails his or her character. Beyond the obvious rightness of Kirk and Spock, Scotty is hilarious, Karl Urban does an jaw-droppingly good McCoy. I can't wait to see more of these guys.

Spock

Spock it the obvious heart of this movie, as well as the connection to all that has come before. I think it may be some mild revisionism to claim that this has always been the case -- but Leonard Nimoy has managed to shepherd Star Trek nobly through four decades and all of the variations. Shatner just became ridiculous after a while.

The new Spock is far more human than we see him in the series. He may pursue the benefits of logic, but he still contains all of the emotions of his human side, all thr more potent for their repression. He's much more powerful, more emotional, and more dangerous than the Spock of the original series. He portrays humor, anger, violence and sexuality as well as the continuous struggle to overcome all of these through discipline.

Kirk

This Kirk is way more engaging than the original. The new Kirk's chief talent seems to be the ability to take a beating and keep going. How many times did Kirk get the crap kicked out of him in this movie? But it totally works -- like Indiana Jones, the continuous beating humanizes Kirk, and makes him a much more attractive character. Similarly, they've taken Kirk's womanizing and, by shooting him down a few times, made it endearing rather than lecherous.

Surprises

The team behind this movie did an incredible job keeping some important things quiet. Two things in particular: going in to the movie I had no inkling of the relationship that would develop between Spock and Uhuru, and I had no idea that Vulcan was the planet we saw destroyed in the trailer.

In fact, I couldn't believe how sneaky they had managed to be with the trailer. It strongly, but deceptively, implies that there's a relationship between Uhuru and Kirk. It uses the history of the characters to misdirect us, all the while setting up for a payoff that had my grinning from ear to ear. And I watched Vulcan being destroyed a dozen times on TV without knowing what I was seeing. And this, when the real moment came, I was floored.

This, then, is what they mean when they take about raising the dramatic stakes. It delivered a punch to the gut just like the destruction of the colonies in the Battlestar Galactica miniseries did. And I can only imagine how the idea of Spock and the Vulcans as refugees might continue to play out over future films.

Laughs

The writers worked in a ton of really, genuinely funny moments -- and not just the surefire lines. We know McCoy has to say "Damnit, I'm a Doctor!" They get those moments in with a minimum of artificiality. But there's real humor in the movie. I laughed out loud far more times than I expected.

Things that were slightly less awesome

The ship

I was a little disappointed that we didn't get to see more of the Enterprise. There was really only one great action scene (dodging the debris of the other Federation ships), and a brief moment at the end when it swoops in to save the day.

The new ship design is great: it respects the original series, yet still manages to look cool. And I am enormously pleased that they seem to have changed the way the weapons work in the Star Trek universe: more than one weapon can fire at the same time! And how cool was it to see the crewmen actually loading photon torpedoes?

Design elements

Which brings up another point: I liked that we got to see people doing their jobs in parts of the ship beyond the bridge. The weapons crewmen, or Uhuru down in some science bay, hard at work.

The new bridge does, on the other hand, look pretty darn cool. But I have to ask, why do they need those stupid desk lamps everywhere? And I can't explain the scene that had Kirk and Scotty running through what appeared to be a brewery in the belly of the ship.

Martial arts?

It was a great idea to give Sulu a sword fight in the movie, but why must all movie sword combat involve leaping and tumbling all over the bloody place? Hong-king-style martial arts have becomes way too common -- they just don't belong in Star Trek.

Go see it

In the end, I loved almost every second of this movie. There are ten more favorite moments I could list (like Eric Bana appearing on the view screen and just saying "hi!"). But I'll leave it for now with a final reminder: get to the theater.

Bonus links

The Sexualization of Spock
The decently entertaining comic book prequel to the prequel
Star Trek is now Star Wars
The Science of the new Star Trek Movie
Star Trek as Progressive Mythology or
Star Trek as Capitalist Fantasy

Drinking Boston

2009-06-30T06:33:49+00:00

I was in Boston last week for Enterprise 2.0, and Jenn and I made good use of the evenings by working our way through some of Boston's finer drinking establishments. Just as last year, I used Lauren Clark's inimitable Drink Boston as our travel guide, and her Best Bars list as our itinerary. This year, we explored:

No. 9 Park, Boston Common

No. 9 Park, on the other hand, exceeded every possible expectation. The staff are knowledgeable, friendly, helpful and snappily dressed. My favorite cocktail at this place was made with gin, lime and mint. It sounds simply, but it was sublime. In all seriousness, I think I've never had a cocktail I've enjoyed more. I wish I could remember the name of it. I've googled for it, but I've only turned up the Palmyra, which sounds similar but is made with Vodka. And unfortunately, though the restaurant publishes all their other menus, the cocktail menu is missing from the website. In any case, if we're back in Boston next year, No. 9 Park is the first bar on our list.

Craigie on Main, Central Square

Craigie on Main is a lovely restaurant, but I found the cocktail list a little uninspiring. All new creations (I think) and no classics. I tried a St.-Pierre, which was good and well-made. Though, as the waiter warned me, I found the rhum agricole a little harsh. The highlight of our night at Craigie, however, was sitting at the bar and watching the kitchen staff work. It gave me a whole new appreciation of just how stressful a high-end kitchen is, especially under a demanding chef.

Drink, Fort Point

The forthrightly named Drink is a new bar this year, opened by the owners of No. 9 Park (and other establishments). I'm happy to say that it holds to the same high standards as its sibling. Although the website won't tell you much about the place, it's terrific. It's in an otherwise desolate neighborhood, and well hidden. In fact, we went into the wrong bar (the only other one on the street) because we'd walked right by the signless Drink.

Luckily, one bad vodka tonic later, we were back on the out on the street, and I finally noticed the low bulbs burning in the windows of a below ground room. Through the door, down the stairs, and we found ourselves in a long, narrow room with a twisting bar. The bartenders are the real stars at this place. They're encyclopedic. Best of all, there's no cocktail list, so the bartenders will take the time to discuss a selection with you. Tell them what you like, and they'll suggest something twice as good.

Eastern Standard, Kenmore Square

Our last adventure found us at Eastern Standard. I'd been to this bar last summer, and was mildly disappointed to find the cocktail menu unchanged. Nonetheless, they've got a terrific selection and a smart variation of styles: classic, modern, champagne, long, etc. We stuck mostly with our favorite classics at Eastern Standard, but each one was delicious and made with care.

If you find yourself in Boston, I would highly recommend each of these bars. With quality and variety like this, the Boston cocktail scene can vie for the very best in the country. And I know we're looking forward to further exploring the Best Bars in Boston list next year.

(Cartoon) Follow me NOT

2009-06-30T00:07:17+00:00

We created a special piece of collateral to hand out at our booth at last week's Enterprise 2.0 conference. Confluence 3.0 has some great, new social features, but rather than tell the story through a typical sales datasheet, we invented Bill and John, two cartoon characters trying to overcome a few coworker TMI issues — too much information. Fortunately, Confluence-man comes to the rescue.

Let us know what you think! Excelsior!

Keep your documentation website backwards compatible

2009-06-29T22:08:39+00:00

Most engineers know that you should at least try to keep your software and hardware backward compatible.
If it is not excessively expensive, the new version of your program should read data files created with previous versions, your newest 10Gbit switch should talk to the 100Mbit legacy one etc.

People seem to forget that this should also apply to your website with product documentation.

I have a nice Cerberus Pentagram P6381-0 wireless router that usually works perfectly. Today, however, I had a power glitch that left the router in unusable state.
I managed to get to the vendor's site with documentation, but the closest model I could get the PDF for was P6381-2 (can you spot the difference? ;-))
I managed to reset the router to factory settings using that doco - but surprise, surprise: the default password does not work.

Almost an hour later I googled for the exact model number and I found the right manual on the very same site - it just was not linked in the support links section. If it was, it would have spared me 2 hours of looking for the problem.

And yes, the default passwords are different for P6381-0 and P6381-2 models.

Lesson learned: keep the documentation for older releases easily findable for as long as you have people using it.
This applies esp to products that are not likely to be upgraded as soon as you release the new version: either because it is a piece of hardware or when upgrade costs money or significant effort.

Hamcrest saves your soul - Now with less suffering!

2009-06-29T18:31:45+00:00

In a previous post I described how Hamcrest can save your soul. After writing that, it was pointed out that you probably don't need to suffer so much boiler-plate to save your soul.

With that thought I set out to write the deeplyIsEqual matcher. The result is the DeepIsEqual Matcher. Using it is pretty easy. In that previous post I described the Matcher for comparing lightsabers, LightsaberIsEqual. We no longer need that. Now we can simply do

    assertThat(anakinsLightsaber, is(deeplyEqualTo(lukesFirstLightsaber));

No extra boilerplate is needed and we still get all the benefits of only seeing the fields that didn't match in the error messages. Oh, and the reported expected value is built using reflection too, so you don't need to worry about whether the type of objects you're comparing implement toString or how they implement it.

After going through the initial implementation I started switching over the OAuth tests to use this new matcher. Everything was going great until I hit a case where PublicKey or PrivateKey objects were being compared. The problem was, one was a generated key and the other was converted from an encoded string value. Apparently, depending on which way you create Key objects, the internal fields can be slightly different. So, comparing them recursively was failing. I struggled with what to do - I could add the Key to the internal, hardcoded types that are compared by simply using equals(), or I could add the ability for testers to specify how they wanted certain types to be compared using a MatcherFactory. This being 20% time and me seeing other places where specifying custom matchers for certain types would be very useful, I went with the second option.

So, if we wanted to match Hilts in a very specific way we could that pretty simply.

    public static Matcher<? super Lightsaber> equalTo(Lightsaber lightsaber)
    {
        return deeplyEqualTo(lightsaber, extraTypeMatchers);
    }

I wrapped the deeplyEqualTo call in a convience method, because the creation of the extraTypeMatchers can be a bit gnarly and makes the tests a bit harder to read. As a simple example, let's say we want to compare {{Hilt}}s using their equals() and don't care if the subtypes are different. To accomplish that we could use the following extraTypeMatchers.

import static com.atlassian.hamcrest.ClassMatchers.isAssignableTo;
import static com.atlassian.hamcrest.DeepIsEqual.deeplyEqualTo;
import static com.atlassian.hamcrest.MatcherFactories.isEqual;
    Map<Matcher<Class<?>>, MatcherFactory> extraTypeMatchers = new HashMap<Matcher<Class<?>>, MatcherFactory>()
    {{
        put(isAssignableTo(Hilt.class), isEqual());
    }};

That's not very pretty, but by wrapping it up our test can go back to simply being

    assertThat(anakinsLightsaber, is(equalTo(lukesFirstLightsaber));

and we get all the benefits we had before, plus we are matching Hilts in the desired way.

The biggest thing left to tackle is how to handle object graphs that have cycles in them. We have some ideas about how to do it, such as tracking the objects visited and if we find one that we've already visited just stop recursion and assume it will be true, relying on all the other matching to prove otherwise. I'm not 100% sure this will work. The main problem being, what happens if a field in expected value has a reference to, for example, the first object in the graph. But, the actual value doesn't have a cyclic reference but does have a reference to an object that should be considered "equal" to the same object as the expected value (I know, it's probably not entirely clear what I mean but I'm having a problem figuring out how to phrase it more better as my brain keeps breaking when I think too hard about it). I'm thinking for now, being able to specify custom matchers for types should be enough. If there is some part of the object graph that we expect to have a cycle, then just specify a custom matcher for it and move on.

To play with this you can checkout the code from the labs project, or you can get from our public maven repository. If you find any problems with it report them in JIRA.

Thanks, and enjoy testing again!

Confluence Customer wins 'Open Enterprise Innovation' Award at Enterprise 2.0

2009-06-26T21:58:40+00:00

A huge congratulations goes out to Walton Smith and team at Booz Allen Hamilton for their winning the Open Enterprise Innovation Award at the Enterprise 2.0 conference in Boston this week.

Booz Allen's Hamilton is a 90-year-old consulting firm with over 20K employees. Walton helped create Hello.bah.com, a platform combining 'best of breed enterprise 2.0 tools' including Confluence. It's a great example of a large, mature firm can innovate with new ways to communicate, collaborate and share knowledge.

Stephen Walling at ReadWriteWeb also gives a great summary of Walton's Enterprise 2.0 presentation in Boston on Thursday. If you missed it, Walton also presented hello.bah in our March Voice of the Customer webinar which you can watch on Atlassian.com/tv.

Video: Plugin of the Month with Go2Group and 3 Plugins

2009-06-26T00:25:49+00:00

Wil, Mike, and Doug gave a great presentation today on 3 of there plugins for our Plugin of the Month webinar:

1) Go2Group JaM Plugin - integrates JIRA and HP Quality Center, allowing developers in JIRA to display a list of available QC test cases/defects within a JIRA issue.
2) Go2Group CRM Plugin - integration between Atlassian JIRA and Salesforce or SugarCRM, providing tighter collaboration between support teams and sales teams.
3) Go2Group synapseRT Plugin - provides a dashboard within JIRA which displays requirements based on projects and releases, providing a comprehensive view into your entire development environment.

For past webinars, please hop on over to Atlassian TV where you can now sort videos by products and categories. For upcoming webinars, please visit our events page. If you would like to be in our webinar series, please contact us.
Also, don't forget about following us on

How to determine the context your macro is being rendered in

2009-06-25T20:16:32+00:00

For Confluence 2.10 (remember that?), we converted the display of the Jira Issues Macro from using a static HTML table to using a table infused with jQuery goodness. Now we could add features that wouldn't have been possible without JavaScript, like the ability to sort issues in the page without even reloading. That was pretty cool, but it also meant we had a new problem to deal with: macros can be rendered in places that can't render JavaScript, such as in a feed reader or an email notification. In those cases, our beautifully redesigned macro would look something like a puddle of goo.

We thought about how to get around this new problem, and decided the best approach would be to make it possible for macros to find out if they are being rendered in an email or a feed, so they can display themselves appropriately. It was already possible for macros to find out if they are being rendered in a PDF document or several other contexts. In Confluence 2.10, we made it possible for macros to find out that they were being displayed in an email or feed, an addition to the previously defined contexts. Previously, macros being viewed in an email or feed reader would have just had the render type "display", which is the default.

Now the Jira Issues Macro is able to render itself differently in display versus feed modes:

Okay, so how can you find out the current render context from within your macro? When creating a plugin that includes a macro module, you return the HTML that the macro will display from the execute() method of the macro class. One of the parameters to the execute() method, the one with type RenderContext, can be used to determine how the macro is being rendered.

Here's a sample execute method from a macro that prints out the current render context type:

public String execute(Map parameters, String body, RenderContext renderContext)
{
 if(RenderContext.FEED.equals(renderContext.getOutputType()))
 return "FEED render type";
 else if(RenderContext.EMAIL.equals(renderContext.getOutputType()))
 return "EMAIL render type";
 else if(RenderContext.HTML_EXPORT.equals(renderContext.getOutputType()))
 return "HTML_EXPORT render type";
 else if(RenderContext.PREVIEW.equals(renderContext.getOutputType()))
 return "PREVIEW render type";
 else if(RenderContext.DISPLAY.equals(renderContext.getOutputType()))
 return "DISPLAY render type";
 else if(RenderContext.PDF.equals(renderContext.getOutputType()))
 return "PDF render type";
 else if(RenderContext.WORD.equals(renderContext.getOutputType()))
 return "WORD render type";
 else
 return "some other render type";
}

If you used this sample macro on a page you were editing (by first installing the plugin that contains it), you could visit the preview tab to see it output "PREVIEW render type". In the case of a more complex macro, you could, say, disable some UI elements when the RenderContext.PREVIEW.equals(renderContext.getOutputType()) check is true. Using these checks is exactly how the Jira Issues Macro decides whether to render itself using JavaScript or just stick with a basic HTML version.

Pair Programming is Kryptonite!

2009-06-25T16:59:17+00:00

Pair programming is easily the most controversial agile development practice and in my experience the most frequently avoided. It makes some people pretty uncomfortable.

Just so we're all on the same page, pair programming means two programmers working together on one computer. Yes really. Normally one codes while the other thinks ahead and around. Or, one drives and the other navigates, swapping regularly. The motivation is higher quality output from the outset.

Pair programming requires working much closer with team mates than most developers are accustomed to. This is both its power and it's greatest weakness.

Working so closely with others can bring otherwise hidden personal issues to the surface. My experience in previous jobs has shown me that pair programming can be so personally challenging for some people that the practice is infeasible for that team. Doing it takes courage and maturity, it requires a healthy environment where mutual respect, humour and humility are all expected. Not to mention minimum standards of personal hygiene! This is quite different from the stand-offish formalism characteristic of many alternatives and this humanistic style sets the bar too high for some. Cowboys, incompetent introverts, control freaks and superhero programmers all resist pair programming. It's like their kryptonite.

Like culture shocked westerners first visiting Tokyo, unused to the dramatic reduction in personal space one can expect, say, on a commuter train, for some, getting used to the personal invasion that is pair programming is a self-imposed barrier they just need to break through.

Pairing up with different people makes this personal contact a dynamic challenge. There are several axes of individual difference which demand different behaviour. For example there's the novice-expert axis and the introvert-extrovert axis and people have different natural working styles and favoured problem solving strategies. For example I can often be willing to explore unconventional solution paths which make methodical people a little unsettled. Being aware of that helps me communicate appropriately and change my behaviour where necessary.

Pairing requires bilateral adaptability and the art of compromise.

There are many common anti-patterns that lead to ineffective pair programming. These things are fairly well documented, for example see Pair Programming Illuminated by Laurie Williams and Robert Kessler. It's worth tackling these problems actively because ineffective pair programming is worse than no pair programming and it's obvious even to would-be starry-eyed XP fans.

One of the reasons I've been thinking a lot about pair programming recently is because I haven't been doing it for a change. (gasp!)

Apart from some time on support and fixing a pile of trivial bugs (not pairing), I've been working solo on a front-end feature for JIRA 4.0. Solo because our team has an odd number of people right now (wanna job?). It has actually put me in a great position to evaluate the practice of pair programming somewhat objectively.

First the good stuff about not pairing. I have some great new headphones and with the right music I can get into the zone and stay there for hours without needing to coordinate with anyone. I do not have to continually exert effort listening or thinking of ways to express my questions or ideas. I just think and do. That's refreshing.

But I'm not ashamed to admit it's a little isolating. Hey, I'm a people person.

The negatives of not pair programming are especially visible when you are accustomed to doing it. While not pairing recently I have become curiously suspicious of the quality of my work.

I think it's good, Is it really good? I'm not gold-plating am I? Maybe this is absolutely the wrong approach. Is there something obvious that I'm missing? I'd better get someone to review this.

All those thoughts are plaguing me in my "step back moments" when the tests pass and I get to wonder about the next move. This wouldn't happen if I was pairing. I would be in dialogue with my partner; we would have common mind (just imagine Yoda saying that last bit).

Pair programming can really help in making a team gel. Spending time together - not just in pair programming but in other activities like sharing a meal or social event during work time help teams to gel.

So while there are many reasons to practice pair programming, it's not the only way to get these benefits. Code review is an obvious alternative for many of the same benefits. Marketing may want to break my arms if I don't mention Crucible at this point.

So if you're not improving the quality of your code with pair programming, then I'd hope you are doing code reviews because there really isn't much disagreement in the industry that this is a very well known and effective method of ensuring quality software development.

Atlassian development teams do either one or the other, or sometimes, like in JIRA some of both.

Using a tool like Crucible for code reviews has some advantages over pair programming, such as record-keeping and working across distributed teams and time zones. Pair programming has some advantages over code review such as swapping keyboard shortcuts and shell one-liners and helping a team to gel.

So if you have a business case for better quality software then remember: two heads are better than one!

Learn about agile software development inside Atlassian

Writing a guest blog post

2009-06-25T07:22:19+00:00

Scott Nesbitt has asked a number of technical writers, and I’m one of the privileged, if we’d like to write a guest post on the DMN Communications blog. So I did: What makes a technical writer tick?

Writing for someone else’s blog is fun! It’s also interesting.

What’s different

You suddenly have all sorts of new considerations. You don’t know exactly when your post will be published. Potentially, you don’t know your audience as well as when writing on your own blog. You’re not sure how much editing the blog owner will do on your post after you’ve submitted it. You don’t have hands-on control of the formatting and you can’t make final tweaks just before publication.

Publication date arrives

I waited with bated breath. Seeing my post appear: Fun — almost as if reading it for first time. Surprise — the format is unfamiliar. Even though I’ve visited DMN Communications often before, it was still odd to see my words up there in that format. When writing on your own blog, you write in a WYSIWYG editor. You craft the appearance along with the words.

Hmmm. That’s the way most of us operate in our day jobs too. This made me think again about the trend towards content reuse and single sourcing, such as via DITA, where you need to write format-agnostic content. It’s difficult!

From the point of view of the blog host

On the subject of inviting guests to blog on your site, Scott has written some interesting notes from his perspective.

Scott added some headings into my post. That was a good editorial decision. He also let me know that he had done it before he published the post. He added the image at the top, and then added my fish image at the bottom when I emailed it to him later. Awesome to-ing and fro-ing. Scott also let me know how much extra traffic my post had generated. That was cool. Thanks Scott!

Comments from readers

I’m thoroughly enjoying the comments other technical writers are leaving on the post. Who can resist the “fish called Rhonda“? Bring on the puns, guys and gals! And if you want to add more serious stuff, well, that’s OK too

Writing a guest blog post

Technical writers are simply the best. Better than all the rest. With another bow to Douglas Adams: It is a bizarrely improbable coincidence that anything so mind-bogglingly useful could have evolved purely by chance.

Confluence Macros - Do the Evolution!

2009-06-24T22:00:00+00:00

Last week my colleague Matt wrote a piece explaining the history of macros, and how they have evolved over time. He showed how they were powerful ways to add content to your wiki but historically out-of-reach to the average user. Today, we want to shed some light on exactly how much has changed since day one and how easy Confluence 3.0 makes it for mere mortals to use macros.

As the video below shows, no longer do users need to concern themselves with typing inside of curly brackets and figuring out what parameters need to be set. All that's needed is an idea of what content you'd like to show and Confluence takes care of the rest. Matt showed you the old way of doing things. This video shows how much simpler it is today in Confluence 3.0.

The evolution of macros is, in a way, a reflection of Atlassian's own growth as a company. Atlassian has evolved from a highly technical team, mainly of developers, to a diverse range of departments. Teams such as Marketing, Customer Service, and Talent that did not exist before are now essential parts of Atlassian. Like many business users, our non-technical departments are thrilled to be able to embed task lists, charts, RSS feeds and other dynamic content into their wiki pages.

The future is bright for the Macro Browser. Plugins 2.0 and Atlassian Plugin Exchange set the foundation for building and discovering new plugins, while the Macro Browser makes the magic accessible to all users.

What are you doing still reading this post? Download Confluence 3.0 and see for yourself already!

(Marketing) 7 lessons learned in publishing video to our website

2009-06-24T20:00:31+00:00

More than a year ago, we launched AtlassianTV, a section on our website dedicated to videos about products, customers, plugins, partners, and all-things Atlassian. When we first launched the site, it was a barely structured, small group of videos. Since then, the site has become more sophisticated, the number of videos grows weekly, and the audience has grown at a nice click.

Graphs that go up and to the right are usually a good thing. That's the result, but of course there were some mistakes made and lessons learned along the way. Herewith are a few key takeaways:

1. Think about your audience first
2. Determine how you're going to measure success early on
3. YouTube is awesome, but is it the right tool for what you need to accomplish?
4. Get into a rhythm
5. Have fun
6. Even B2B companies can use ads
7. Got content? It should be organized

radiowalker

2009-06-24T19:03:28+00:00

Although I rarely re-blog Atlassian news, I can’t help myself this time. This deserves more exposure. Why? Three compelling reasons:

1. The LincVolt project is the coolest clean technology car project. Its mission is to get a 1959 Lincoln Continental to try to break a 100 mile-per-gallon barrier. This car weighs 2.5 tons. I would be satisfied just sitting in a ‘59 Lincoln, let alone getting 100 mpg. This is simply a fantastic, ambitious project using a gorgeous battleship of a car.

2. The car runs Atlassian JIRA, our bug and issue tracker, right on the console. Yes, folks, you can create your issues and track them while you drive. The geographically-dispersed development team relies on JIRA to track their project.

3. Neil Young owns the car and uses JIRA. This is a personal project of Neil’s to inspire people by creating a clean automobile propulsion technology. I am flabbergasted the guy uses JIRA. I am a long-time fan, I have been to several of his Bridge School concerts and I’m practically a neighbor of Neil’s, but the fact that he is using JIRA is awesome.

Check this video out of the LincVolt project…

One last reason I love this project: it trumps my wife’s Toyota Prius, which I think she would leave me for. Prius owners are so smug, but this car is THE BOMB.

I have been known to play “Pink Cadillac” but now in homage to Neil, I need to write a tune about a wicked-cool ‘59 Lincoln.

Wikis wikis wikis - usergroups in Dutch and Strine

2009-06-24T02:52:08+00:00

Confluence 3 Launch Party in Vianen, The Netherlands - 25th June
E-id is organising in cooperation with Atlassian an event for new and existing users to the use of the new enterprise wiki, an even stronger platform for online collaboration and social interaction within organisations. The event is designed for anyone online collaboration within their organisation to improve using Web 2.0 software such as a wiki.
There will be presentations covering what's new in Confluence 3.0 and practical issues when migrating to Confluence 3.0
There are limited places available so register quickly to secure a place. Registration is by sending an email to events@e-id.nl.

Wiki Wednesday in Sydney, Australia - 1st July
Every few months in Sydney, a group of developers, bloggers, entrepreneurs, consultants, educationalists, accountants in practice, or anyone interested in wikis, social software, and web 2.0 get together to share their experiences. Everybody is welcome. Pizza will be provided and you'll get to have a sneak peek inside Atlassian's Sydney offices. If you are interested in attending or giving a presentation, we're going Pecha Kucha style this time, please sign up here.

If you can't make it all the way to The Netherlands or down to Sydney, then you can always check out this quick video about what's new in Confluence 3.0

Get (task) focused with the Atlassian Connector for Eclipse

2009-06-24T02:00:00+00:00

Today is a big day for the Eclipse community with the release of "Galileo", also known as Eclipse 3.5.

Atlassian is joining the fun with the latest version of our Atlassian Connector for Eclipse.

This Eclipse plugin allows developers to quickly access JIRA issues, Bamboo builds, Crucible code reviews and FishEye SCM insights without context-switching from the IDE. The Atlassian Connector supports the newly-released Eclipse 3.5 (Galileo) as well as earlier 3.3 and 3.4 versions.

The latest release of the Atlassian Connector for Eclipse was created in partnership with Tasktop Technologies, creators of the widely adopted task-focused Mylyn interface for Eclipse. Developers working on JIRA issues and Crucible code reviews are far more productive thanks to Mylyn's innovative context-based presentation which shows them only the source code files and information needed for the task at hand.

The Atlassian Connector for Eclipse allows developers to easily and efficiently:

Configure JIRA, Bamboo, Crucible and FishEye servers as Mylyn task repositories
Receive notifications of changes to JIRA issues, Crucible code reviews, and Bamboo build status directly in Eclipse, eliminating context switches
Create, update, and manage JIRA issues throughout their life cycle.
Launch Bamboo builds and create JIRA issues to address failed Bamboo builds
Create and conduct Crucible code reviews right in the source code editor
Access FishEye SCM insights at the project, package, file, or line of code level

Please note: some users have encountered errors when installing the Atlassian Connector for Eclipse. This is due to a problem with the distribution of Eclipse 3.5 to the various mirroring sites.

If you encounter one of the following error messages during installation, please try the following troubleshooting steps. If these solutions do not fix the error, we recommend attempting to re-download the 3.5 distribution from a different mirror site.

"Cannot find a solution satisfying the following requirements"
Click here to view solution

"Error while collecting items to be installed"
Click here to view solution

Check out the Atlassian Connector for Eclipse in action (2:36):

Long agile banner

2009-06-23T23:43:50+00:00

Back in another day and time, I wrote a blog post about transparency in marketing. This post today is about authenticity, and how Atlassian created a campaign that focuses on the user experience rather than the marketing message.

One of the several announcements Atlassian made at its first ever worldwide user conference was the launch of a new minisite, Agile @ Atlassian. While we were not Agile subject-matter experts, we could provide some important insights into our own understanding of Agile. That’s an important distinction, because it guided our decision on how to produce a campaign. There’s an excellent TED talk by Joseph Pine on creating an authentic voice in marketing. Our campaign was based on creating this type of authentic talk based on our experiences rather than on marketing messages.

A site is born.

Atlassian’s developers have been doing agile for 7 years, and many of our customers do as well using our developer tools. “Agile” in this context relates to how software developers engineer products. The Agile Manifesto and hundreds (thousands?) of agile evangelists are spreading the gospel that there’s an “enlightened” way to code.

Many people don’t know how to take advantage of Atlassian tools for agile software development. In fact, there’s a whole lot of agile developers that are searching for better ways and tools to make their team agile. Atlassian’s software was engineered more broadly to be used by any type of development, but they can be used for agile software development, and the mini-site provided a glimpse into how we take advantage of our own tools for agile.

Thus, Agile @ Atlassian was born. The campaign breaks down as follows:

We spent a grand total of $1000 on the campaign and minisite — the money was spent on a professional videographer to tape our developers talking about how they do their jobs.
The mini-site was designed and produced by our in-house design and web teams. The videos were edited and pimped out by an endlessly talented and creative developer on the marketing team.
We included previously recorded customer webinars with S1 Corp and Replicate Tech that discuss how customers user our products for agile.
Atlassian developers have been blogging about agile@atlassian, and an RSS feed of their blogs is included on the mini-site.
New product descriptions were written to emphasize how our products can be used in an agile environment.
To tie up all the loose pieces — videos, blogs, webinars — we design a brand for the agile@atlassian series that appears in the the blogs and anywhere agile is found on our website.
We used the campaign as a platform to announce our latest agile project management offering, GreenHopper.

One Twitterer wrote:

“Listening to agile@Atlassian while working. I’m a huge Atlassian fan and this is a nice peak into their world.“

Since launching, the minisite has seen over 6,000 visits, with the average person viewing 5.63 pages on the site/visit. This is a short recap of the effort we put into the site, and I think it’s a very good template for other B2B marketers for creating similar campaigns, esp. those who dare to go from a marketing voice to an authentic one.

Posted in Atlassian, Marketing Tagged: marketing campaign, minisite, website marketing

Webinar: 3 Plugins with Go2Group

2009-06-23T21:57:00+00:00

This month's Plugin of the Month webinar will feature Wil Anderson and crew of Go2Group. They plan on showing off 3 fantastic plugins:

1) Go2Group JaM Plugin - integrates JIRA and HP Quality Center, allowing developers in JIRA to display a list of available QC test cases/defects within a JIRA issue.
2) Go2Group CRM Plugin - integration between Atlassian JIRA and Salesforce or SugarCRM, providing tighter collaboration between support teams and sales teams.
3) Go2Group synapseRT Plugin - provides a dashboard within JIRA which displays requirements based on projects and releases, providing a comprehensive view into your entire development environment.

Update: View video here.

Check out our video of the LincVolt car!

2009-06-22T23:14:22+00:00

As I mentioned in a previous post, the LincVolt is a project pioneered by Neil Young. It's his goal to turn his 1959 Lincoln Continental into a green car. They're converting it to an electric vehicle with the goal of getting it to 100mpg. The coolest part of this (for Atlassian) is that the LincVolt project is using JIRA to manage all of this!

Check out this video Mark and I shot when we were down at JavaOne earlier this month, explaining the car, its history and how it uses JIRA:

On the iPhone App Store’s Prohibition of Emulators

2009-06-21T23:24:52+00:00

Recently in the news, a Commodore 64 emulator with a bunch of legally licensed games was rejected from the iPhone App Store. Normally this would be a simple case of “didn’t you read the license agreement?” except that apparently they had previously run the idea past Apple Europe to positive response.

I was chatting to a developer from a competing phone company at JavaOne, and he was telling me how annoying the competition found Apple's ability to turn the negatives of their platforms into positives.

The example he gave me was security. Other phone manufacturers have to go to great lengths to sandbox third-party applications, building a complex security model to defend against malware. Apple instead said ‘screw that’ and moved the security model up a level into the app store. I'm sure it's possible to get a malicious app approved, but it would involve registering as a developer and writing a potentially commercially viable app that would pass Apple's quality control, and Apple could throw the kill switch on it the moment they discovered it was malware.

This is the root of the ‘no emulators’ provision. Apple needs to control the code running on the iPhone. Emulators open the door to unapproved code. Hence emulators can not be approved.

It is likely a C64 emulator would itself protect the iPhone from malicious apps, since emulated apps already run in the sandbox of emulated hardware. Sure, Apple wants to control the content on the phone, but given the new capabilities of iPhone 3.0, how are downloadable games different from any other kind of in-app purchasable content pack? This is what happens to rules once they are written down and removed from the reasoning behind them.

Certainly, Apple could go the extra mile and build a better application sandbox for the iPhone. But this just turns into the classic software development scheduling problem: ‘Sure, we can do that. We can do anything you want. Just tell me which three features I should cut from the next release to get it done.’

Interestingly enough on the same trip I ran into a developer who was dipping his toe in Android development. He told me his second biggest frustration¹ was the hardware. He was developing some cool graphical/physics demos, but even being sure that they could run smoothly on arbitrary Android phones, or even run without crashing, was turning out to be far too much work.

Once more, it's turning a weakness into a strength. Apple controls the iPhone hardware and the software that runs on it, against all the ‘hey, didn’t the open PC platform win?’ logic of the industry. Turns out that's the same logic that attracts games developers to the predictable hardware and software of consoles, despite the license hassles and limited hardware, over trying to tame the beast of PC gaming.

Originally a reddit comment

¹ The first, apparently, being the primitive implementation of the Java Virtual Machine. These performance tips read like the sort of advice you'd give a 1990’s era Java developer, which makes sense once you discover the VM lacks a JIT compiler.

Videos: Fireball - The Collaboration Appliance by Appfire

2009-06-19T19:48:08+00:00

Mat Gauvin, COO of Appfire, recently showcased Fireball, the collaboration appliance built for our software. Fireball provides a cost-effective solution for organizations of any size looking to collaborate, fast.

You will not want to miss the following videos if you are interested in Fireball. In the first video, you will see a webinar complete with an excellent Q&A session. The second video documents the unboxing of Fireball, proving the slogan 'From Cardboard to Dashboard in under 10 minutes.' Lastly, the third video is a great, professionally produced, overview of Fireball.

Fireball Webinar with Mat Gauvin (29:15)

Fireball Unboxing (6:18)

Meet Fireball (4:14)

Meet Fireball - The turnkey Collaboration Appliance built for Atlassian software! from Appfire Technologies on Vimeo.

FishEye 2 Beta Insight (part 3) - Usability

2009-06-19T12:12:10+00:00

So far, I have talked about the new People and Personalisation features in the FishEye 2 beta. And these are just the tip of the iceberg.. FishEye 2 has gone through a complete UI transformation to ensure that performance and usability is unparalleled. Working with Subversion, CVS, and Perforce (and soon Git!) has never been easier.

FishEye 2: Faster and easier than ever

While all of the great features that you have come to know and love FishEye 1.x for still exist, we have improved upon many things to make using FishEye 2 feel almost like a client GUI. Here's just a few things you'll love:

Performance - First and foremost, you'll notice the performance of FishEye 2 is faster than ever.

Tree browser - When navigating through the source tab, the tree browser is lightning fast with new Ajaxy goodness. The path at the top ensures you never lose your context.

File Explorer - See all revisions for any file in your repository with commit details and easy access to diffs. You can also see all activities and users involved with the file, view reports or drill into the raw or annotated source.

Favourites - Adding a star next to any file, revision, branch, repository or changeset will do two things, 1) bookmark it to your favourites menu, and 2) add all related activity to your personal dashboard.

Activity streams - Generate RSS feeds from any type of activity stream including cross repository streams, project streams, user and committer streams, or your personal dashboard stream.

Emails - You can also place watches on any browse or changelog page and receive email notifications.

Annotated source - You'll never look at code the same way with annotations in the gutter providing author and revision information.

Ad hoc reporting - When looking at any file, branch, or repository you can click the reports tab to get detailed historical charts. You can slice and dice the data with a variety of chart types, options and data constraints.

Plugable reports - You can even create your own customised reports using the FishEye index and show them in the query tab with our overhauled plugin architecture.

Side bar tabs - As you move around in FishEye, the side bar tabs are contextual based on what you are looking at. This let you quickly switch between left-hand panels or collapse them all together for a full-screen view.

Search - Use the query tab from anywhere to construct detailed queries and share links with teammates or export results as CSV.

EyeQL - FishEye has it's own query language, called EyeQL, which lets you structure sophisticated queries to find exactly what you are looking for.

Quick Navigation - The search box in the top right now includes Quicknav which auto-completes as you type.

And there's plenty more in FishEye 2, so I encourage you to take a closer look..

Give us your feedback

Download the public beta of FishEye 2 and check out the FishEye 2 Beta Release Notes for more information.

You can also check out these updated public instances:

http://fisheye1.atlassian.com - SourceForge CVS repositories
http://fisheye6.atlassian.com - Apache Subversion Repositories

Kick the tires yourself and let us know what you think.

IntelliJ + Atlassian now means even higher productivity!

2009-06-19T02:00:00+00:00

We're excited to announce the release of the latest version of the Atlassian Connector for IntelliJ IDEA!

This IntelliJ plugin is freely available to everyone, and allows you to access JIRA issues, Bamboo builds, Crucible code reviews and FishEye SCM insights without switching tools.

The latest version, 2.1, introduced a bunch of awesome features that make common activities easier and faster. Our own developers have been 'dogfooding' with the plugin for a couple of weeks now, and I've heard nothing but great things about the new functionality.

The new active issue toolbar remembers the JIRA issue you are working on, tracks time spent on the issue, and automatically updates the issue status to 'in progress'.

Keyboard shortcuts bring your JIRA issues within a few keystrokes:
- Press Shift-Alt-J to see your recently viewed issues.
- Press Shift-Alt-S to do a quick search for an issue.
- Click an issue key in the IDEA editor to open the issue.

Creating pre-commit Crucible code reviews is quick and easy, and doesn't require the creation of a patch.

You can now create a review while committing your files. A Crucible review is automatically started for the changeset.

There are a bunch more new features that are going to make working with JIRA, Bamboo, Crucible and FishEye even easier for IntelliJ users. You can get the full details in the release notes.

Want to see the Atlassian Connector for IntelliJ in action? Check out this three-minute video that shows how you can easily work with JIRA issues, Bamboo builds, Crucible code reviews and FishEye SCM insights as you work on source files.

GreenHopper for JIRA: Not Just for Agile Developers Webinar

2009-06-18T18:42:17+00:00

Atlassian recently hosted a webinar entitled "Greenhopper for JIRA: Not Just for Agile Developers." The webinar featured demos from Jean Christophe Huet, the father of GreenHopper, and Cody Burleson, founder and President of Burleson Technology Group. In addition, the webinar included over 45 minutes of questions!

JC showed how GreenHopper can be used by pretty much any JIRA user and informed the audience that GreenHopper's two main goals are to provide a simple and interactive interface and increase visibility and traceability of JIRA projects. He demonstrated how GreenHopper can help you: update issues quickly, prioritize issues, manage subtasks, manage versions, schedule issues, and update statuses quickly.

Then Cody Burleson took the stage and expanded on his GreenHopper blog series by describing what he does and how he uses GreenHopper and JIRA. He is new to GreenHopper (his 30-day trial expired two days before the webinar), but he already finds the plugin extremely helpful. Referring to GreenHopper, Cody commented: "only once in a while does a product come around that really delights you, and when I find something like that it's exciting!"

After Cody finished his demo, JC and Cody spent the next 45 minutes answering questions from people watching the webinar. Topics included the burndown chart, custom fields, custom issue types, test integration, etc. Unfortunately, a technical difficulty cut off about 20 minutes of the Q&A, so the recorded version of the webinar is missing the last few questions.

Hopefully the webinar will help you learn more about GreenHopper and JIRA!
Check out the webinar:

So far, several attendees have downloaded or bought GreenHopper. Join them!

Crucible 2 Beta Insight (part 3) - JIRA Integration

2009-06-18T12:45:11+00:00

In the first two parts of my little blog series on the Crucible 2 beta, I covered iterative reviews and the new usability improvements. One of the most requested features from existing customers was better JIRA integration and I'm excited to let you know that we have improved this greatly.

JIRA + Crucible 2: Better together!

For developers using JIRA to manage issues and tasks, Crucible adds a very valuable quality assurance step to your development processes by making it quick and easy for teammates to complete code reviews.

Here are some of the key integration features:

Suggested issues - When creating new reviews, Crucible automatically suggests potentially related JIRA issues based the commit messages or the review title. You can link them to your review with a single click.

Access review details in JIRA - Review comments are automatically incorporated into the comments of the linked JIRA issue. There is also a Crucible tab which includes all of the review details.

Link comments as subtasks - When adding comments to a review, you can also create a corresponding subtask in the related JIRA issue with just one click.

Resolve subtasks from Crucible - Once a comment and subtasks are linked, you can resolve them from either Crucible or JIRA and they'll be updated in the other system as well. This means you don't have to leave Crucible to update the status of your issues in JIRA.

Hover details - Just move your mouse over any JIRA issue key to get a hover box with essential issue details including title, status, reporter, and assignee. Click to expand and get even more details like the full description, issue type, project, created and modified dates.

Managing your JIRA issues and Crucible code reviews has never been easier!

Give us your feedback

Download the public beta of Crucible 2 and check out the Crucible 2 Beta Release Notes for more information.

You can also check out these updated public instances:

http://fisheye1.atlassian.com - SourceForge CVS repositories
http://fisheye6.atlassian.com - Apache Subversion Repositories

Kick the tires yourself and let us know what you think.

new Liverpool blog

2009-06-17T19:37:19+00:00

So between Twitter and Facebook, I find myself having less and less to particularly blog about on Chatterwocky. I never really liked talking about myself anyway, and my brief forays into talking about work have been uncomfortable at best, as pretty much only my friends and family read my blog, and there’s not much chance [...]

You Can Do That! Part 1 of 3

2009-06-17T19:29:15+00:00

Although this may not seem obvious at first, there are some important parallels between Apple's iPhone and Confluence 3.0. "How can this be?!?" you might ask. After all, the iPhone is a piece of hardware developed by one of the world's oldest and most admired technology companies. Confluence, on the other hand, is this intangible thing called a "wiki" created by a young Australian company.

Despite these differences, they share some fundamental characteristics. To create the iPhone, Apple took the ordinary cell phone and built tons of functionality on top of it to develop a new device that can be used for almost anything. Atlassian has done something similar with Confluence. It took a basic collaboration tool and added a bunch of capabilities that expanded the wiki's use beyond simple collaboration.

To highlight these similarities, we made a few short videos modeled after Apple's recent advertising campaign for the iPhone. Here's one video that shows how the Macro Browser intuitively broadens the range of tasks that Confluence can be used to accomplish.

We'll publish the remaining two videos in subsequent blog posts.

Getting Started With Agile - Daily Standup Meetings

2009-06-17T16:10:13+00:00

Becoming agile. The first baby-step

There are many ways to become agile. And many ways to fail horribly while trying! Purists say that you are not really agile until you do everything in a truly agile fashion. That might be true. But beware - don't try to start everything at the same time. That's a recipe for disaster. To make the transition to agile go smoothly, this blog post focuses on a simple way to get started with agile: perform daily standup-meetings.

Why start with stand-ups? Because they work perfectly in any environment, including traditional waterfall environments. So you can get started without even telling your boss about your agile intentions, and achieve good results even if you ultimately decide to remain non-agile. Daily stand-ups will still save you money and keep you focussed.

How does it work?

Daily standup-meetings are as simple as they sound.

You gather the team in the same spot each day, stand in a circle, and then everyone takes turns in answering three simple questions: What did I work on yesterday, what will I work on today, and is there is anything that is blocking me? Each person gets one minute on average (sometimes more, sometimes less), and overall it shouldn't take more than 10 minutes. That's it. In a way this is so old-fashioned that I wouldn't be surprised if ancient Greeks did this...

But beware! Daily standup-meetings are also a bit harder than they sound. After the "new" effect wears off, and before the long-term gains start to be fully understood, people might find it tempting to slack. So let's have a look at the long term benefits outside of having a nice team chat...

How does it help?

Introducing a quick daily standup-meeting is the cheapest most astonishing improvement I can think of for any project and one of the fundamental aspects of communication with an agile team.

It helps your team avoid duplication: if Steve plans to work on a problem that was already solved two months ago by Sam, then you can bet that Sam (or someone else) will tell Steve before he even starts wasting time;
Clear roadblocks: if someone is blocked by something particular, this is the perfect time to check who could help: "I have been working on bug X, with little progress. Has anyone seen X happening? Let's chat after the standup meeting";
Detect roadblocks: if John tells the same story for the fifth time in a row, everyone else will realise that he is severely stuck and needs a hand. Catch him right after the meeting and get him some help;
Boost team coherence and commitment: team coherence and commitment is increased when everyone speaks to everyone else on a regular basis. Especially when you don't all work in the same room, or when different members of the team work on different aspects of the same project;
Increase project manager accountability: daily standup-meetings even make the project manager more accountable. When your manager comes to ask your status, would you dare ask him his? Probably not. But in a daily standup-meeting the manager is reporting his status to everyone else;
Increase team member accountability: daily standup-meetings make each team member more accountable as well. A manager might not notice that Sal is over-engineering her solution just for the fun of it - but the rest of the team will;
Spread transparency: if you are the project manager, then the project is probably transparent to you already. But there is immense value in team-wide transparency too. People are not machines, and love knowing what's happening. This is the place\!

What are the costs and risks?

Admittedly, the daily standup-meeting does take time. And some people don't like speaking in front of others. And at times the meeting can distract people from doing important work. These are all valid points. But you need to compare them to the costs that arise by not having this meeting. How much work would be lost by double work, or by people not realising they are stuck? How important is staff retention to you - and what better ways of open communication can you get at a price tag this small? As long as you apply common sense and accept that some people occasionally may miss a meeting, and that others may not be great at speaking (but do attend and listen), there is little to worry about.

A bigger risk are people who like to hear themselves talking. The stand-up meeting is not for story-telling. You need to be strict about the time-limit. If someone exceeds the standard 60 seconds, usually a smile combined with the "Time-out sign" will help. A common problem is that the boss feels inclined to turn his 60 seconds of fame into a 5 minute speech, to ensure he looks more important than everyone else. Someone needs to have the guts and speak up - in a friendly way, and depending on the kind of boss it may make sense to do this after the meeting, to come across less confronting. The same applies to discussions. Stand-up meetings are not for discussions. They should encourage discussions, but after the standup-meeting, and with just the people who really care. If someone frequently starts discussing what someone else said, take them aside and explain that the discussion is great, but it needs to happen after the meeting.

It will help to nominate one person to become the 'Standup-Champion' who will make sure that the meeting remains focused and finishes quickly and on-time. This person also makes sure the meeting happens in the first place, so the person should not be too shy to shout out "It is STANDUP time now, guys and girls!")

So what's agile about it?

You can start stand-ups without turning agile. But the impact is bigger than "just" efficiency, transparency and team building. The standup-meeting quickly turns into the catalyst meeting of the day. It regularly spawns discussions about things that were not considered in the "big plan". It helps you address problems earlier. It helps you reshuffle your road-map because you learn about good and bad news early. It encourages people to wrap up tasks more frequently, and to tackle tasks in smaller increments, because no one likes to tell (or hear) the same report every day. Standup-meetings don't make you agile, but it would be harder to become agile if you didn't have them. So they are a great first step on your long winding road to agility.

Q&A

When is a good time to get started?

As with any change, you need to be careful. People are often hesitant about change, especially if they have been subjected to frequent random change before that didn't help. So don't introduce this when the tension is high already, or when you are new and don't have any credibility yet. In software development terms, how about waiting until the current version of your software has been shipped, and everyone had a great time at the post-launch party. As with every change, first make the proposal, discuss it with the team and with relevant stakeholders, and take on their feedback before you actually get started. You may even want to try it out with a subset of people who are more keen on trying new things out. Just make sure to keep everyone in the informed.

Is it necessary all the time? Can we just have standup-meetings in times of crisis?

Standup-meetings are awesome during times of stress and crisis. They keep you focused and help avoid unnecessary work. But ask yourself: How can you avoid stress and crisis in the first place? How about avoiding straying, and how about avoiding unnecessary work in the first place? Standup-meetings are no silver bullets, but they can help avert crisis by catching problems early.

How about just doing it once a week then? That should save us some time?

The opposite will be true: People will talk for longer. People will prepare more (if they only get to talk once a week, they will want to shine\!). There will be less focus on the week ahead. If someone did double work, it will be too late to save time. If someone was stuck, she will have been stuck for a while now. And so on. Weekly meetings also have their place, but they should be dealing with larger issues, like planning and discussing the work ahead, and they should only have the people involved who are actually needed for that discussion.

Can we sit down? Standing is uncomfortable...

You are missing the point. It should be uncomfortable! You have to keep the meeting short. If everyone sits in a comfy chair and sips on great coffee, what are the chances of the meeting being short? Don't even dare to lean on that table - HTFU mate!

Is my team big enough to justify this?

At my previous job, I thought stand-ups would not be necessary for a team of just five. After all, we were sitting in the same room already, had plenty of discussions, and I talked to the individual developers quite frequently already. We started only when we ramped up to 8 and then 10 developers. Only when we did so, I realised how much I had missed what the original 5 developers had been doing (and what they had not been doing..). And of course the transparency improvement for my colleagues was even bigger than for me. Stand-up meetings even with just three people make sense, after all double work needs to be avoided all the time, and with just three people on the team you should be done in 3 to 5 minutes anyway.

Is my team too big to justify the costs?

If 16 people spend 15 minutes a day, that adds up to 4h per day, and a whopping 20h per week. This is of course still just 3% of each person's time, and a team will need to communicate anyway, so 3% is not too bad. But indeed, if your team is so large that people start complaining about the duration, or you see people dozing off, then you need to reconsider. On the Confluence team, we decided to split the big standup into two meetings when we reached 18 people. Our team consists of four sub-teams, and we do a rotation now. During one fortnight the sub-teams A and B meet at 9:45, and sub-teams C&D meet at 10:00. The next fortnight sub-teams A and C meet at 9:45, and subteams B and D meet at 10:00. And so on. Obviously you will have a little less knowledge-sharing because some people will only meet every two weeks. But of course there are so many other ways to share information too. Wiki-pages, wiki-blog posts, wiki-discussions and (sometimes) good old email don't get replaced by stand-ups after all.

When is a good meeting-time?

It really depends on your team. If you all start working at the same time in the morning, then that time is ideal. But if people trickle in between 8:00 AM and 10:30AM, then any time is a bad time, because it will distract the people who came in early, or exclude the people who come in late. You may want to consider a time just before everyone goes to lunch (this can actually help you get everyone to go for lunch at the same time). Or you just go with 10:30. Just make sure that you let the team decide, and make sure to review your decision frequently. Maybe 8:00AM seemed like a good idea at first, but once people realise that their transport is less reliable than they thought, you may want to reschedule. Tell everyone that the time will be reviewed after, say, 4 weeks.

Learn about other agile practices

That was an interesting introduction - where can I learn more?

Try Martin Fowler for plenty of stand-up patterns and anti-patterns. I also recommend seeing how Atlassian practices agile development.

Tell your best build story and win a Bamboo license!

2009-06-17T02:06:01+00:00

Our friend The Build Doctor just launched an awesome contest!

Submit your your best or worst build and/or deployment experience. This could be:

That project you pulled from the brink;

The project you didn't

The home grown build system that was written in a polyglot of Perl and Visual Basic. That's right, the one that would only run on a Pentium with the floating point bug.

The grand prize is a license of Bamboo Standard Edition (current Bamboo customers get a 1-year maintenance renewal).

Ten second prize winners will get a cheeky Bamboo T-Shirt:

Submit your entry to the contest today!

hmmm

2009-06-16T23:00:13+00:00

What a weird day - it's pouring, teeming rain while clear blue sky reigns in the distance. A rainbow made a brief appearance outside my window and yet apparently the rest of Australia is clear and cloudless!?

Nice day to be at home playing my new ukulele. Hmmm.

After WWDC

2009-06-16T21:43:53+00:00

I spent most of last week at Apple’s Worldwide Developers Conference. WWDC one of those things I do every couple of years and the first question I always get when I mention this is ‘Why?’ As a Java developer whose only Mac coding is spare-time hobbyist playing around, what's the value to me of going to an Apple developer conference?¹

The obvious answer is ‘because I learn stuff’. I can't tell you exactly what because of the blanket NDA that covers everything after the Keynote address, but I can give some idea of where I'm coming from. I've always felt that attending was valuable to my education as a general purpose nerd, but I think the reason only really became clear to me in the [Redacted] session when Bertrand Serlet described how Apple [Redacted].

I'm not going to mention any particular companies or products here, but one thing that seems to happen far too often at major keynote tech conferences is The New Direction. Some great new programming language, environment or set of APIs are unveiled as the great new way that you are going to write software in the future, but it quickly becomes obvious that the people selling you this technology simply aren't using it themselves for anything important.

One of the cool things about WWDC is that for the most part, the libraries and APIs that are unveiled to developers are the stuff that Apple has been using to develop the software that runs, and runs on the next version of Mac OS X, and now feels are mature enough to make available to third party developers. The talks are littered with examples of how a new API allowed some team to delete this much boilerplate code, or allowed them to implement one of the new features showcased in the keynote this much faster.

It makes a refreshing change. It's far more interesting for me to sit in a session about Grand Central Dispatch and learn how it has already made some application I use every day substantially more efficient, than it is to learn that some new API is conceptually better, works really well in this demo, but the vendor haven’t themselves written any shipping code that makes use of it.

So one thing WWDC provides me is a showcase of ways in which a company that controls a suite of applications, the OS those applications run on and the developer tools used to develop those applications solves some pretty substantial engineering problems, and how it turns those solutions into publicly consumable APIs.

Which, I think, is pretty damned useful.

¹ Beyond simple fanboyism, which I must admit still plays a non-trivial part in my decision to attend, and the fact that I seem to be in San Francisco at around that time on other business anyway.

SDTimes hat trick

2009-06-16T18:51:57+00:00

Atlassian was named to the 2009 SDTimes 100 list in the Application Lifecycle Management category. It's our third SDTimes 100 award, and it feels pretty durn good to be included as a company that helped to lead "... the way to this new software world through [our] ideas, inventions and new implementations."

The complete ALM category description reads as follows:

No two developers--or development tools providers--will ever agree about what's included within application life-cycle management. How much does ALM focus on an individual developer's productivity? The team? The organization? The lack of a clear definition hasn't stopped some of the industry's most innovative companies from offering tool suites that encompass the entire application life cycle. In some cases, these organizations have demonstrated leadership by creating innovative ALM solutions from the ground up. In other cases, they have led by integrating once-distinct products.

See all the 2009 winners at SDTimes 100.

Agile Context Switching with "The Disturbed"

2009-06-16T02:27:15+00:00

Possibly the best way to cripple the productivity of any development team is to bombard them with distractions. This was best brought home to me by DeMarco and Lister's seminal book Peopleware: Productive Projects and Teams.

Programmers, the authors proposed, are at their most efficient when they reach a state of 'flow' in which they are able to concentrate fully on a single problem. Any developer will tell you how satisfying it is to be in this state, how productive it is... and how easy it is to be pulled out of it by the smallest interruption. What's worse, since it takes at least fifteen minutes to reach this level of concentration, any interruption no matter how small can cost you a quarter hour's productivity. A constant stream of small interruptions, say a phone near your desk that rings just twice an hour, can make a developer unproductive (and miserable) for most of the day.¹

Still, distractions are inevitable, and problems that need a developer to help solve them will come up every day. A production system may run into trouble, another developer may need help with a hairy problem, a member of another team may want to know how your product solves a particular problem, and so on. At Atlassian, we try to manage these interruptions in two ways:

1. Asynchronous Communication

Atlassian runs a Jabber server for staff, and during the day all developers are logged on to instant messaging. The advantage of instant messaging over other forms of intra-office communication is that it is so easily ignored. A developer who doesn't mind being interrupted can monitor their messages and respond as they come in. A developer who is busy working on some tricky problem can minimise the window and respond to messages at his or her leisure.

For this reason, developers will often use IM to talk to a colleague, even when the other person is sitting only a few feet away.

The other form of asynchronous communication popular in Atlassian is blogging: writing a blog post on our internal wiki is a great way to get feedback from the rest of the company about an idea without walking around interrupting people to ask them their opinion.

2. The Disturbed

Asynchronous communication introduces its own inefficiencies. It turns out there are still enough problems that need to be solved now, not at the convenience of the developer, to constitute a steady stream of interruptions to the development teams. Our solution, pioneered by the Bamboo team, was to designate a single developer to be "The Disturbed"; taking a two week stint to act as a magnet for all the questions, requests and distractions that would otherwise be distributed across the whole team.

For Confluence, the name of the current Disturbed is prominently displayed on a whiteboard just outside the team's office space. The Bamboo Disturbed has a flag on his or her monitor.

The downside of this approach, of course, is that for two weeks the Disturbed gets very little work done on whatever feature track they are nominally committed to. On the other hand, because the Disturbed isn't expecting (or expected) to get much of that work done while being disturbed, it is far less frustrating for the developer and far more predictable in terms of scheduling and estimation for the team as a whole.

To learn more about how we develop software at, visit the Agile at Atlassian site.

¹ DeMarco and Lister use this to argue that each developer should be given a private office with a door, a practice enthusiastically embraced by Microsoft in the 1980s and more recently by New York software firm Fog Creek. Atlassian remains defiantly open plan: an office layout that encourages collaboration and communication at the expense of pure efficiency.

Crucible 2 Beta Insight (part 2) - Iterative code review

2009-06-15T23:04:40+00:00

With a sweet new UI designed to make code review as easy as email, the new beta of Crucible 2 is packed with great features. The most revolutionary of which is the idea of iterative code review.

Crucible 2 - Iterative code review

Most code review processes are naturally iterative. First you write some code, then one of your peers reviews it only find some way to improve it, and then you code it up again, and repeat as necessary.

Although this process may take just a few minutes, it's not unusual for reviews to include 2 or 3 revisions. That's why Crucible 2 has made it simple to manage reviews throughout this iterative process:

Outdated files - Any Gmail users out there will be familiar with the little pop-up message appearing whenever someone has added to the conversation.
Similarly, Crucible will let you know when a new revision is available and let you include it in the review with a single click.

Tracking as you go - As you move through a review, Crucible automatically tracks which files and comments you have already read or reviewed. This will reset as new revisions or comments are added.

Revision slider - One of the most obvious things you notice when reviewing source is the revision slider. Not to be confused with the London Tube map, this slider shows you the number of revision included in the review along with the number of comments made for each.

Comparing revisions - If you want to compare different verions of a file, simply move the end-points of the slider. The diffs will automatically reload with comments inline.

Comments follow revision - Comments made to any lines that move or get removed in a future revision will be annotated in the gutter for easy reference.

Filter files to speed up reviews - By filtering for new content "since last completed review", you only see new changes and comments for revised files.

Iterative code review makes it simple for teams to collaborate around code changes in order to ensure the highest code quality. Next time, I'll cover more the details of Crucible 2's new JIRA integration.

Give us your feedback

Download the public beta of Crucible 2 and check out the Crucible 2 Beta Release Notes for more information.

You can also check out these updated public instances:

http://fisheye1.atlassian.com - SourceForge CVS repositories
http://fisheye6.atlassian.com - Apache Subversion Repositories

Kick the tires yourself and let us know what you think.

Atlassian Goodies in our Gear Store

2009-06-15T22:29:30+00:00

Atlassian t-shirts are a hot commodity. We've had customers email us for extras and pick them up at trade shows and wear them with pride. In fact, we were voted as having one of the coolest t-shirts at JavaOne this year. Check this out:

While that t-shirt isn't for sale, you don't have to wait for an upcoming trade show to get one of our t-shirts; they're all available in the Atlassian Gear Store. Each product has its own cool statement that will undoubtedly make you the coolest cat in town -- or at least the envy of geeks in your area.

10 things you didn't know about JIRA Studio

2009-06-15T21:01:45+00:00

Studio now only $25 user for Developers (users with Source access), $10/user for Issues/Wiki users (Collaborators).

Hosted Subversion is included, with a whopping 15/gb per user.

Studio gives you GreenHopper agile planning tools for free.

Studio includes full enterprise versions of JIRA, Confluence, FishEye and Crucible.

Comment or close a JIRA issue with code commit using SVN Commit Commands.

Work on issues and code reviews from your IDE using the Atlassian IDE Connector

Track visits to your Studio instance with AWStats, bundled for free!

JIRA Studio comes pre-configured with a wide variety of popular plugins, and new ones are being added all the time.

Studio works out of the box in 5 minutes from signup.

Using Trac? We can import your Trac source/issues/wiki. We also will import Subversion, JIRA (or other bug tracker) issues, Confluence pages, and more.

With 30-day no-risk evaluations now available, there's never been a better time to try Studio.

FishEye 2 Beta Insight (part 2) - Personalisation

2009-06-14T18:49:49+00:00

Last time, I talked about how FishEye 2 focuses on People and Teams by raising the importance of developers and their activities within your development environment. Let's not forget that the most important person on your team is YOU! That's why FishEye 2 offers many ways for you to control this seemingly endless amount of data in order to provide you with meaningful information at all times.

Personalisation in FishEye 2

Here is an overview on some of the key personalisation features with FishEye 2:

Dashboards - Every FishEye user has their own dashboard with custom activity streams and personalised reports.
- Activity streams - An aggregated feed shows activity within your SCM related to the people and source code you care about (more on "favourites" below..). In addition to seeing who commits what changsets, you also see related activity for any JIRA issues or Crucible reviews. All this is also available via RSS.
- Reports - FishEye shows you personalised, consolidated reports with Line History and Commit Activity.
- Starred items - Direct access to your favourite people and source.
- Multiple committers - If you commit using several different usernames or in multiple repositories, FishEye maps all of your identities into one profile.
Favourites - Marking objects in FishEye as a favourite will add them to your personal activity stream and save them to the shortcut menu at top of every page. You can follow activity for the follow items: people, committers, projects, repositories, branches, source files, even specific revisions and changesets/commits.
Projects - Projects allow you to group one or more branches for multiple repositories for consolidated reporting and navigation within FishEye.
Watches - You can enable email notifications directly from any browse or changelog page.
Display settings - Configurable display settings and email notifications let you control the flow of information you get.
Atlassian IDE Connectors - With integration to both Eclipse and IntelliJ, you are never more than a single click away from FishEye goodness. Just right-click on any file in your IDE to view it in FishEye.

In my next post, I plan to cover many of the new usability improvements in FishEye 2.

Give us your feedback

Download the public beta of FishEye 2 and check out the FishEye 2 Beta Release Notes for more information.

You can also check out these updated public instances:

http://fisheye1.atlassian.com - SourceForge CVS repositories
http://fisheye6.atlassian.com - Apache Subversion Repositories

Kick the tires yourself and let us know what you think.

(video) Summit 2009 Redux

2009-06-12T22:31:37+00:00

Video and slides from Summit 2009 are now available for all to see.

Hear the product updates as they were announced: Confluence 3.0, JIRA 4.0, FishEye 2.0, Crucible 2.0, GreenHopper, and more.
Learn how Atlassian customers are using our tools.
Download dozens of presentations.

See the videos and presentations here.

It was a high-octane event, we can't wait to do it again next year.

Confluence Macros - It's Evolution Baby!

2009-06-12T04:39:42+00:00

One of most powerful things about Confluence is the rich ecosystem of plugins that users have at their disposal. Whether it be embedding a PowerPoint presentation on a page, creating a live dashboard with real-time metrics, or showing off your favourite Flickr slideshow, Confluence can handle all that! Confluence really is more than a wiki. But, in order to create all this cool content, previously you had to know the syntax for the macros required. With hundreds of plugins, each with their own set of macros, this proved to be quite difficult! Let's not forget how difficult it was for Confluence admins to manage all of the additional plugins. Well, we recognised that and did something about it. Let Boots and I take you on a journey of the evolution of Confluence Macros.

Where did they come from?

Veteran Confluence Architect, Charles Miller, did some digging for me and highlighted that what is now the Confluence plugin system, was originally the Confluence macro system. See below:

Now from what we remember, the first macro ever written was the original tasklist macro by our co-founder Mike Cannon-Brookes, to demonstrate how the macro system worked. It has since evolved into the super useful Dynamic Tasklist 2 plugin. You may be wondering what's all this business between macros and plugins? Well, macros became plugins in Confluence 1.3 because we wanted a way to easily add themes themes into Confluence, the same way you could with macros.

With each subsequent release we exposed more and more Confluence functionality to plugins, basically because our awesome plugin authors were becoming more ambitious with what their plugins were trying to do. In Confluence 1.4 we made it possible to install plugins and use them straight away without the need to restart Confluence.

What we were still lacking was the ability to install plugins via the Confluence Admin interface. Alas, that came in Confluence 2.3 which shipped with Adaptivist's Plugin Repository Client giving admins a directory of plugins they could install dynamically over the web:

What's coming next for plugin management for Confluence? Well, really it's not just for Confluence, but for all our products. The Plugin Exchange Manager is on its way.

Oh how they've grown!

The chart below illustrates the growth in the total number of plugins ever written for Confluence:

Note: These numbers are for all plugins ever written. We've since eliminated a lot of obsolete plugins during the migration to the Atlassian Plugin Exchange, dropping us down to about 300 actively maintained plugins.

I'm more popular than you

So, what are the top 3 most popular plugins for Confluence, you may ask? Well, thanks to the awesomeness that is the Atlassian Plugin Exchange we can now track the number of downloads to give us a rough idea, and the winners are...

1. The Calendar Plugin which puts a dynamically updated calendar into any page.

2. The Theme Builder Plugin which allows you to completely customise the look and feel of Confluence.

3. The WebDAV Plugin which allows you to use Confluence like a network drive with drag and drop file operations.

These plugins are all FREE! But, let's not forget that Confluence ships with a huge amount of bundled plugins that provide some really kick ass functionality. Some highlights are:

1. The Office Connector which brings Confluence to the masses, and lets anyone participate in creating and editing pages using Microsoft Word, embed Office documents and PDF files on a page and even import Word documents into Confluence.

2. The Widget Connector which allows you to embed content from across the web in your Confluence pages.

3. The Chart Plugin which can generate sexy charts in a Confluence page using data from a table on a page or external sources, via SQL queries.

I remember how we...

The growth of plugins chart displayed earlier in this post was actually created in Confluence so I've created a short video that relives the painfulness of creating a chart on a Confluence page in the old days. Check it out below:

What's changed?

I'd love to tell you but you will have to wait for Boots' second part of this series....coming to you soon!

You haven't heard the last from the Summit Sponsors

2009-06-12T04:32:25+00:00

Our 17 sponsors were a keystone of Atlassian Summit. Without their help, the conference would not have happened. There were heaps of announcements from the sponsors and starting soon, we will feature the Platinum and Gold sponsors in upcoming webinars (keep your eyes on our events page for details).

Thanks again, Sponsors!

Platinum:
Gold:
Silver:
Bronze:

Stewart Mader, "the wiki whisperer", visits Atlassian SF

2009-06-11T23:12:39+00:00

I was pleasantly surprised to find Stewart Mader visiting Atlassian's offices today and chatting with our Confluence Marketing Dude, Bill Arconati.

As some of you may remember, Stewart was our very own wiki evangelist before going out on his own and starting his full time consulting practice, Future Changes.

He's doing really well and blogs regularly over at futurechanges.org

I sat down to catch up with Stewart and chat about what he sees going on and the future of wikis.

Here's what he had to say:

How's the wiki adoption consulting business?

Business is good. We're into the mode that businesses that know they're going to survive the recession are starting to work and invest on strategic projects that are going to make their businesses healthier.

How should new businesses think about wikis?

The right way for a business to think about a wiki is not as an esoteric, experimental tool, but as an indispensable part of their daily work. Just like email. That's the baseline key to good adoption.

Wikis aren't a fad. The average knowledge worker should think of email and the wiki as their two core tools: one for communication and the other for collaboration.

What's a healthy form of wiki adoption?

Wiki adoption should be steady. When it becomes too rapid, you've lost control of making sure people are using it in consistent ways. And that's an issue for a 10,000 person company because you don't want 10,000 people doing things in 10,000 different ways.

You want everyone to start from a set of consistent starting points and best practices to help the wiki flourish. The key is giving users a set of practices to start with, then letting them tweak and refine them to best fit their specific business processes.

Thanks Stewart!

To learn more about healthy patterns of wiki adoption and growth, check out wikipatterns.com

Stewart recently published a new report entitled, "Why Business Don't Collaborate". This report explores how people plan meetings and get group input on project materials, and how the tools they use affect the quality and efficiency of their output, and their sense of accomplishment. For more information click here.

Crucible 2 Beta Insight - Pain free code review

2009-06-11T08:30:26+00:00

I blogged about some of the high-level features of the FishEye 2 and Crucible 2 beta releases last week, but I barely scratched the surface.. now it's time to dig a little deeper into Crucible 2, Atlassian's peer code review tool.

I'll be breaking this up into a series of posts over the next few days, so stay tuned...

Crucible 2: Pain free code review.. easy as email!

I think very few people will argue with the fact that peer code review is a good thing. Unfortunately for most developers, their first experience with code review consists of painfully long meetings in crowded conference rooms staring at eco-unfriendly printouts while ego maniacal peers debate totally irrelevant topics from ideological soapboxes. Ok, maybe it's not that bad, but likely some of those pains are associated with the poor code review processes..

Thankfully, those days should be long gone. Most successful agile development teams have implemented tools like Crucible to make code review a lightweight, asynchronous, and iterative process.

With Crucible 2, we overhauled the UI pretty significantly in order to make code review take no more time out of your day than checking your Gmail account. Check out the new features you'll soon come to love when doing code review with Crucible 2:

Creating reviews - Creating a blank review will automatically present you with recent changesets for the review. You can also browse or search your SCM for files or upload a patch. If you are using JIRA or FishEye, reviews can be created with single click.

Suggested reviewers - Once files are in your review, Crucible 2 will suggest likely candidates for reviewing the code based on the revision history of the particular files and the current workload of potential reviewers.

Reviewing changes - As a reviewer, you can easily step through files using the top-level buttons or the tree nav while Crucible 2 remembers exactly where you've been. You can set personal display preferences in order view source, comments, and diffs the way you like it.

Adding comments - Just highlight the lines of code in question and start typing. Defects can be flagged and linked to sub-tasks in JIRA with a single click.

Reviewing comments - As a developer or moderator, you can easily step through comments one-by-one and reply in line. Filter settings help display just the content you really need to care about while Crucible 2 will automatically mark comments "read" as you step through them. Resolving defects will automatically close linked sub-tasks in JIRA.

Iterative reviews - Development never halts while files are under review. Also, it's not unusual for reviews to lead to further code changes and refactoring. So, whenever this happens, Crucible 2 will detect the new revision and allow you to add it to the review. (I'll cover this in greater detail in the next post)

Keyboard shortcuts - The best part about all these UI improvements is that we have add keyboard shortcuts for nearly every action making it a snap to step through all your reviews in just a few minutes a day (just like Gmail!!).

Trust me, there's much, much more in there as well. Next time, I'll talk more about iterative code review and why it's such a game-changer!

Give us your feedback

In the meantime, download the public beta of Crucible 2 and check out the Crucible 2 Beta Release Notes for more information.

You can also check out these updated public instances:

http://fisheye1.atlassian.com - SourceForge CVS repositories
http://fisheye6.atlassian.com - Apache Subversion Repositories

Kick the tires yourself and let us know what you think.

FishEye 2 Beta Insight - People and Teams

2009-06-11T08:12:38+00:00

With all of the announcements and activity surrounding Atlassian Summit last week, it's easy to lose track of all the details. I did manage to blog about some of the high-level features of FishEye 2 and Crucible 2, but now it's time to dig a little deeper and provide you with some insight into the seemingly never-ending list of new functionality in both products.

I'll be breaking this up into a series of posts over the next few days, so stay tuned...

FishEye 2: People & Teams

One of the most significant new elements of FishEye 2 is the human element. FishEye has always been a great tool for gaining insight into the activity (commits, changesets, file revisions, etc) in your source control management (SCM) system, but the key protagonists were merely a footnote. We realise that most of you don't code alone and knowing what the people on your team are up to is vital.

With FishEye 2, one of the first things you'll notice is the new People tab. So let me tell you a bit more about what you'll find there:

People tab - This page shows an overview of all users that contribute to your code base. You can see commit history at a glance and sort users by last activity, total lines of code (LoC), number of commits, etc.

Charlietars - You'll notice that each user has a unique avatar, or "Charlietar", which is dynamically generated. You can also upload your own image or link to your Gravatar.

User hovers - Mousing over any user in FishEye 2 will show more details and actions (should be familiar to any Confluence 3 users out there..). You can quickly get contact information and see the aggregated committer mappings for the user.

Follow your team - You can star any user to follow their activity on your personal dashboard. This will also add them to the Favourites menu at the top of every FishEye 2 page.

User pages - Every user has their own page showing a feed of all their activity and detailed reports. Even if you commit with different usernames in the same or multiple repositories, FishEye 2 will roll it all up into a single destination. Similar pages are also available for each committer.

User activity streams - Streams show a user's activity in your SCM along with all related activities in JIRA, Bamboo, and Crucible. Drilling into any changeset lets you view diffs, fully annotated source, and file history. RSS feeds allow you to display this information in your preferred reader or in other places like Confluence.

With all these features focused on the people driving your development, it's easy to stay up to date with everything going on within your team. Next time, I'll cover personalising your FishEye to make the most out of all this valuable information.

Give us your feedback

Download the public beta of FishEye 2 and check out the FishEye 2 Beta Release Notes for more information.

You can also check out these updated public instances:

http://fisheye1.atlassian.com - SourceForge CVS repositories
http://fisheye6.atlassian.com - Apache Subversion Repositories

Kick the tires yourself and let us know what you think.

jay

2009-06-11T02:54:49+00:00

One of the great things here at Atlassian is we have some wonderful musicians. Here’s a window into this side of Atlassian life.

Matt Ryall, Soren Harner, and Jed Wesley-Smith playing in Sydney

Soren Harner runs all our software development. He also runs marathons. Somehow he finds time to be an incredible guitarist and what really pisses me off is he has a voice that makes women rip their clothes off. I have not actually seen women do this. I have, however, seen women consider it. Soren also makes playing music seem so natural and easy. He is one of those guys who knows 325 songs and can start singing one standing on his head. Or perhaps under pressure, with a gun held to his head for example (and with a woman ripping her clothes off). You get the point: this guy is talented.

We have considered shipping Soren MP3s with some of our new product releases, but you know the famous Software Company Problem: not enough time to do all the new feature requests. So his fans must wait. I am one of those fans.

Boots Wang

Boots Wang is in Technical Sales and is clearly the coolest musician at Atlassian. Being cool might be easy to do around a bunch of nerdy engineers who clip their nails at their desk in Sydney, but it’s not so easy to do in San Francisco. Boots wears hats you wish you owned. Boots name is even cool. Boots is in bands with cool names: “Nobody Beats” was one. Boots reeks Cool-dom, Coolness, Coolio-Feng-Shui.

To make matters even more cool, she is a drummer. When I went to music school, all the women played flutes or sang arias and danced in the moonlight. They were pussies. Boots, however, throws down. She hits stuff. She is our only drummer, and I bow down to Her Wicked, Bitchin’ Coolness.

Matt Ryall

Matt Ryall is a Confluence developer and a guitarist. Matt plays acoustic mostly and is the kind of guy who sings folks songs to women to get his way with them. I suspect he is extremely successful. You know: an Emo-kind-of-guy. The kind of guy that writes poems.

Matt is also one of those people who has natural musical abilities. My guess is he never practices. But somehow he whips out some John Mayer song and sounds great. He also lends me his guitar when I am in Sydney, which is terrific of him. Natural software engineer, natural musician.

Jed Wesley-Smith and me

Jed Wesley-Smith is a JIRA developer and a bass player. You non-musicians may not realize how essential it is to have a bass player. I can’t tell you how many bands are searching for bass players. That’s because only weird people play bass. Bass players are famous for lacking social skills. The bass is the Supreme Understated Instrument. It’s takes a certain Zen quality. Type-A, ADD, Hyper-active people like me cannot play bass. Mellow Dudes play bass, and Jed is an extremely mellow guy.

Jed is also a phenomenal musican. While some of us have played professionally, Jed has played concerts where people scream and dance until they have heart attacks or over-dose on something. Jed is also one of those rare white guys who can spell FUNK. Jed is a seriously funky player. Playing music with Jed is a pure joy.

Taras Naumenko

Taras Naumenko is on the Customer Service team in San Francisco. He’s in another league from the rest of us musicians because he not only went to music school, but he plays Classical guitar. The rest of play music to drink by. Taras plays serious shit. Taras, however, is full of surprises.

One day we were jamming in the office, and Taras starts playing “Californication” by the Red Hot Chili Peppers. Now I bet Yo-Yo Ma never played that. How many classical musicians play music from a band that shoots heroin? Anyway, Taras taught it to me, so he’s a real Stand-up Guy.

Morgan Friberg

Morgan Friberg is on our marketing team in S.F. and is the one Real Professional musician in the company. Morgan gigs regularly. In fact, his band, Arcadio has a website, they record regularly, and they even have Arcadio beer cozies, for Godssake. Morgan also plays multiple instruments: guitar, mandolin, ukele, and I suspect more.

Some day I’m going to come to work, and Morgan won’t be there because he was discovered and he hit the Big Time. I will buy every CD. I will even jump in the mosh pit.

Most of us Atlassian musicians are mere mortals. Then there is Jay Simons. Jay runs our marketing. He runs marathons. He does triathalons. He races in serious bike races for laughs. Jay does everything Full-Tilt. He is a spectacular piano player and has an incredible voice. In Jay’s case I am certain women rip their clothes off when he sings. Men might, for that matter. Jay is so talented, his dog is talented. Jay is also very funny and almost as funny as me.

Jay Simons

If software ceased to exist as a profession, some of us could go be professional musicians. But we would be end up playing in bars where people drink too much and have fights. Jay, on the other hand, would be playing cocktail piano at the fanciest hotel in town, dressed in a tuxedo, sipping a martini while women ripped their clothes off. Jay is Pro all the way.

For those musicians out there with some Software Chops, you might want to someday consider joining Atlassian. We need a bass player in S.F. badly, a drummer in Sydney, horn players, perhaps a great conga player… Oh, you get the point.

Selenium Testing with Windows Integrated Auth

2009-06-11T01:29:25+00:00

Automated web testing generally has problems testing sites using Windows Integrated Authentication. This is because the nature of integrated auth is to supply the credentials of the logged-on user - which in the general case is going to be the user running the tests. This may work in some cases, but at the very least it's likely you want to test using both an admin and non-admin user. This can be done with Selenium, but requires some work to get it set up (I'm assuming we're using Selenium Server here).

The goal here is to get the browser running as a specific user (I'm not aware of a way to make the browser authenticate using other credentials). The problem is that your browser is spawned by the Selenium Server, so naturally inherits the logon credentials which started the server. Therefore there are two possible paths to take here - fool Selenium into starting the browser under another user or start Selenium itself under another user. I picked the latter option, although I expect it would be possible to do the former (possibly by replacing the browser executable with a custom script before each test?).

Selenium is fairly quick to start up - certainly in comparison to the speed at which it executes tests, so can be started at the beginning of each test without too much impact on overall testing time. (It would also be possible to maintain state and only respawn if the user changes - but this may not be simple to close on the final test - is there a hook for this?) For our testing (which tests using integrated auth), all Selenium tests create their own Selenium Server instance in a SetUp() method from a base test class (note that the tests are C#/NUnit), and close it in the TearDown() method. The C# code is below which uses the .NET API to start the process under another user - this would be marginally more complex in Java, but could be achieved by invoking the runas command to spawn Selenium.

public class SeleniumContainer
{
 private readonly Process process = new Process();
 private bool started;
 
 public SeleniumContainer(bool asAdmin)
 {
  process.StartInfo.FileName = "java";
  process.StartInfo.Arguments = "-jar lib/selenium-server.jar";
  process.StartInfo.CreateNoWindow = false;
  process.StartInfo.WindowStyle = ProcessWindowStyle.Normal;
  process.StartInfo.UseShellExecute = false;
  string[] domainAndUser = Config[asAdmin ? ConfigProps.AdminUser : ConfigProps.NonAdminUser].Split('\\');
  string password = Config[asAdmin ? ConfigProps.AdminPassword : ConfigProps.NonAdminPassword];
  
  process.StartInfo.UserName = domainAndUser[1];
  
  SecureString pw = new SecureString();
  
  foreach (char c in password)
  pw.AppendChar(c);
  
  process.StartInfo.Password = pw;
  
  DirectoryInfo currentDir = new DirectoryInfo(Environment.CurrentDirectory);
  
  process.StartInfo.WorkingDirectory = currentDir.Parent.Parent.Parent.Parent.FullName;
  
  if (Config.Exists(ConfigProps.SeleniumFirefoxProfile))
  {
   process.StartInfo.Arguments += (" -firefoxProfileTemplate " + Config[ConfigProps.SeleniumFirefoxProfile]);
  }
 }
 
 public void Start()
 {
  lock (this)
  {
   if (started)
   throw new InvalidOperationException("Selenium already started");
   if (!process.Start())
   throw new Exception("Failed to start Selenium process");
   
   started = true;
  }
  
  //give it half a second to start up
  Thread.Sleep(500);
 }
 
 public void Stop()
 {
  lock (this)
  {
   if (!started)
   throw new InvalidOperationException("Selenium not running");
   
   try
   {
    process.CloseMainWindow();
   }
   catch
   {
    //Ignore
   }
   
   //give Selenium 5sec to close before we kill it
   if (!process.WaitForExit(5000))
   process.Kill();
   
   started = false;
  }
 }
}

Testing using Firefox

Firefox in general does not send integrated auth credentials, but can be told to. To do this go to the firefox about:config screen and search for ntlm - there should be three options, two of which need changing.
network.ntlm.send-lm-response: enable this (set to true)
network.automatic-ntlm-auth.trusted-uris: set this to a string representing your host (it's a URL pattern)
Once this is working for firefox you will need to save the profile directory and pass it to Selenium when it starts so that it can use your modified firefox profile (by default it uses it's own). This is done using the -firefoxProfileTemplate parameter, as you can see in the above code. Oh, and you'll need at least version 1.0-beta-2 of Selenium if you want to use firefox 3.

Confluence Case Study: Mambo Foundation

2009-06-10T21:00:51+00:00

As I mentioned in an earlier blog post, we have a variety of customers using our products in interesting and different ways. One such example is the Mambo Foundation.

Mambo is an open source full-featured content management system that can be used for everything from simple websites to complex corporate applications.

Lynne Pope, has been the core developer for Mambo since 2006 and is currently president of the Mambo Foundation, Inc.

Tell us a bit about your organization:

The Mambo Foundation is a non-profit incorporation that governs the Mambo open source content management system project. Mambo is a multi-award-winning, free, CMS that has been around since 2000 and open source under the GNU General Public License since 2001. It has been downloaded over 9 million times.

The Foundation, like the project, is manned by unpaid volunteers. It is charged with protecting the intellectual property, facilitating development by providing the infrastructure, and always keeping Mambo free under an approved open source license.

How do you use Confluence?

Mambo, while having a nominal home, is a virtual organisation with the teams distributed globally. As the years passed we found that knowledge was becoming too distributed and was not being kept readily available to new and future team members. We were using a wiki for user documentation and wanted to extend this to developer documentation, team notes, collaboration on planning, etc.

Confluence allows us to have different spaces with access controls so that each team is able to have their own area, including areas for private discussion. Unlike traditional wiki's, it also allows us to have private work areas where we can each work on our own projects while preparing them for submission to the team.

Combined with the ability to have comments and forums, Confluence has become a key factor in facilitating communication while also keeping the discussions, notes, etc available for future team members.

How has Confluence helped?

Mambo had no developer documentation and now has a growing collection. It is the most visited space on the wiki. While we did not measure specifically, as visitor traffic to the wiki increases we are seeing a corresponding decrease in traffic to the support forums. The decrease in support questions allows the Mambo team to concentrate more on the code, which brings a benefit to everyone using Mambo.

Atlassian's free open source license and the generosity of Adaptavist in hosting our wiki has enabled Mambo to provide documentation resources to thousands of people and has directly facilitated the development of Mambo itself.

Atlassian has given over $10 million in free licenses to open source projects and non-profits. To apply for a free community license or learn more, click here.

Meet Fireball - The Collaboration Appliance built for Atlassian Software!

2009-06-10T20:01:49+00:00

Please join us for our first Summit sponsor webinar.

Mat Gauvin, COO of Appfire, will showcase Fireball, the collaboration appliance built for our software. Fireball provides a cost-effective solution for organizations of any size looking to collaborate, fast.

Atlassian Agile Process Revisited

2009-06-10T18:04:42+00:00

In 2007 I did a series of surprisingly popular blog posts on Atlassian's Agile Process. As part of our renewed push to share our own agile story, I wanted to post an update to my earlier posts. Last time I enumerated the XP practices and mapped them to Atlassian's. I won't be repeating myself (D.R.Y.), so if you're interested in the origins of Atlassian's Agile Process, here are parts one, two, three and four.

Today in the Engineering division, we still have an agile process in each of the development teams defined for and by that team, that is as true now as it was in 2007.

The things that have changed are mostly in the category of second order effects.

Proliferation

The biggest difference in Atlassian's agile process in the last two years is that now it's not just a process for engineering work. Every department is getting agility. Top books on Agile practices are handed around, stacked available on common bookshelves and regularly seen on the tops of busy desks, scruffy yellow sticky notes protruding.

And now I'm even beginning to think that people are reading them.

Another sign of mass agile process adoption was about a year ago when middle management (which was at that time brand-new at Atlassian) started doing stand-ups. After that it seemed as though a critical mass had been reached and the practice of stand-up meetings became ubiquitous. It seems there is a culture of minimalism in meetings, not just at Atlassian, but amongst all smart people who want to get things done.

It's not just Stand-up Meetings either. User stories, You Aren't Going to Need It, Do The Simplest Thing That Could Possibly Work, Don't Repeat Yourself as well as some of the foundation thinking such as kaizen are all now part of the Atlassian lexicon.

I attribute this adoption to three things:

1. People have seen it work.
2. Leaders like it.
3. This stuff isn't new-fangled, it fits in with much established wisdom.

Scaling

Atlassian has grown quickly over its six year history, both in staff and in the number of offices. Processes have had to scale and over long distances and time zones. A good example of the growing pains is JIRA's automated test suite. It's an awesome beast. There are a growing number of unit tests (junit), functional tests (jwebunit) , web browser driver tests (selenium) and there is now a QA department who reviews and improves all aspects of our quality assurance regime which includes testing.

JIRA supports multiple operating systems, JDKs, application servers, databases, and versions thereof. And it comes in three editions (Standard, Professional and Enterprise) with different feature sets. Each edition comes in different distributions including EAR/WAR, Standalone which includes Tomcat as an application server and there is a Windows installer executable. As if that wasn't enough, it works in multiple versions of different web browsers.

So that's a lot of combinations to test! We really wish we could automatically test every combination! Currently our full functional test suite takes more than two hours to run. Multiply that by every combination and it would probably take several days of CPU time to complete. Of course Unit Tests run comparatively quickly and their green bar gives fairly good confidence, but if we want to be sure we haven't broken something in the JIRA user interface when we refactor the code, we have to wait at least two hours.

Running many thousands of functional tests is what is known as an embarrasingly parallel workload and accordingly, I am embarrassed to say we have not completed the work to properly "parallelify" it.

But now that Bamboo supports agents running in the EC2 cloud, we can crank up the compute resources available for continuous integration and we should be able to bring our functional test latency down under 20 mins without too much trouble. Fingers crossed.

Code Review

"Pair programming is the ultimate code review" goes the "agilist" line. I can see this. I can see how it works and I have felt code-review benefits from pairing. I'll be blogging about pair programming specifically in the coming weeks, so I won't exhaust this side of the argument here, however I have to say that code review is the single most effective quality assurance measure on top of a traditional agile process that I know.

There are many advantages of code review over pairing as well. Of course, these are not reasons to abandon pairing, because pairing provides much more than code review. If you are using a web-based code review tool like, ahem, oh look here, it seems we have a product I can pimp here... Crucible... the main advantages are the most obvious ones. You can scale up the number of reviewers and they can act from different locations and time zones. You also get a permanent record.

The JIRA team is probably an average adopter of code review as a practice where it remains a discretionary thing. This suits us because it lets us always use the Agile advised dosage: Just Enough.

Virtual Index Cards with GreenHopper

While we really like the simplicity of paper cards for tracking tasks in the small, the electronic version can be better in some respects. Not only for distributed teams. Of course we use JIRA for tracking large numbers of bugs and feature requests, but it was not until the GreenHopper plug-in that we have felt that JIRA was fully capable of giving us the immediate feedback and visibility that cards can give a co-located team. It also makes burndown charts which are increasingly to be found on big LCD screens around the offices.

So that's it. We like our agile process. It suits Atlassian.

JIRA Rocks the LincVolt!

2009-06-10T17:59:06+00:00

Last week I spent a fair amount of time running between JavaOne and Summit, and on one of those runs I had the good fortune to meet Paul Perrone, head of Perrone Robotics and Project Manager on the LincVolt.

The LincVolt is a project pioneered by Neil Young and it's his goal to turn his 1959 Lincoln Continental into a green car. They're converting it to an electric vehicle, have thrown a bunch of technology into the car (some part of it are now powered by Java) and the goal is to get it to 100mpg. Currently it's at 85 mpg.

Well, interestingly enough, they are doing all the project management for the vehicle using JIRA and Paul came over to tell me that Neil Young uses JIRA all the time and loves it (I think my jaw fell on the floor at this point).

Anyhow, Mark and I ended up shooting some great footage of the car as well as interviewing Paul. You've just got to see how cool this car is and I promise we'll get that up on Atlassian TV before long.

Neil Young loves JIRA, whodda thunk it?

But that got me thinking. If LincVolt is using JIRA in this totally awesome, eco friendly way, what are our other customer doing with our products? We already know that EarthHour has been using Confluence to coordinate their staff to get over 1 billion people to turn off their lights. Surely there are other great stories out there.

That's where you come in.

I'd love to hear your stories, what interesting things you may be up to with any of the Atlassian products. Maybe you're not making a green car, but perhaps you use one of our dev tools on a cool open source project or use JIRA to manage your son's little league team. I'll be posting those stories here on our News Blog as they roll in and will even throw in some cool Atlassian shwag for the first 25 people to participate.

Email me with all your great stories at lkhalil [at] atlassian [dot] com

The Final Countdown

2009-06-10T12:05:00+00:00

At a certain point in every program, you start to count down the number of days left until the inevitable collision with that big, immovable deadline. It's a scary and exciting time. Months of work by many different teams are about to culminate in a single, pivotal moment - say, for example, in the form of live demos during the CEO's keynote speech at your company's first major user conference.

Interesting things happen during the final countdown. Teams move into hyperdrive - fueled by caffeine, pizza and cupcakes - and show how fast they really can sprint. Project managers start deploying special weapons and tactics to protect their teams from the onslaught of last-minute "oh just one more thing" requests. Program managers turn into pale, hovering, nail-biting wrecks, trying very hard not to interfere in absolutely everything.

There are hundreds of things we will need to do better next time (such as having more realistic expectations of velocity, learning curves, scope changes & dependencies; improving our inter-team and inter-contintental communications; introducing less than 14 new & unproven technologies into the cornerstone project; setting up the demo machines way earlier), but the one thing I wouldn't change is the amazing collaboration that happens when a whole company focuses on a single goal. We try to do this all the time, of course, but inevitably each team and department has different objectives throughout the year and it's easy to get siloed.

The last four weeks have been chaotic, stressful and exhausting, but it all came together on the day and we're pretty happy with the outcome. Watching 200 talented and dedicated people reach that goal together was awe-inspiring. Listening to customers talk about how they're going to use those new features to make their jobs easier was instantly rewarding. Now we're conducting post-mortems and coming up with those long, long lists of things to improve. This is the part of program management that I normally find kind of discouraging, but this time I can't wait to harness all those lessons learned into a bigger and better Phase 2.

Atlassian does the Agile Enterprise Acid Test

2009-06-10T00:28:53+00:00

As you may know, we are getting a little more serious about sharing our agile development stories with the world. Well, a little while back, at our Dev team leads' weekly Agile Book Club meeting, we decided to assess ourselves against Dean Leffingwell's Agile Enterprise Acid Test. The test consists of 9 questions, grouped into 3 elements - see the full definitions below.

The purpose of the discussion was not to compare teams; it was a subjective self-assessment of the different products' development processes, to help identify areas for improvement within teams. We also discussed some key characteristics of each team, like team size, codebase age, and something we politely refer to as "Founder involvement", to see if there was any correlation with Acid Test results (there wasn't, so I've left these out).

The results

The discussion

The Confluence team has monthly process meetings which provide a means of "empowerment" and allows them to "reflect & adapt". Issues from the retrospectives are voted on by the team, and high-ranking issues are added to the project backlog. Per (team lead) "smoke tests" the user stories from Adnan (product manager) for completeness and clarity, before passing them on to the developers.
The JIRA team conducts laptop demos for founders at monthly reviews. Feedback is not as continuous as other teams - milestones are less frequent but release cycles are longer. Process champions and tech leads are in place.
The Studio team has not been tested on "accountable for results", as they have not stuffed up a release (yet). The team hasn't asked for many process changes after "reflecting" (apart from requesting the use of real hours for estimating, rather than story points).
Generally the team leads felt frustrated at their ability to remove all impediments, particularly IT infrastructure issues. Luckily we now have an unsuspecting new IT Manager on board to help out with these.
The FishEye/Crucible and Clover teams have had slippages. They are starting to reflect and adapt.
It's difficult to update our internal Crowd instance for dogfooding without disrupting IT. Need to work on a better system for this.
The Poland team holds structured retrospectives and follows up. They work well around the remote location issues.
UI Design - need to feed this into our agile processes more effectively, and in parallel with the Product Managers' conceptual phase for the next release.
Need to include the San Francisco team next time (they were busy actually working when we did this test).

Dean's definitions

Variable scope. Fixed quality.
1. Can the teams vary scope? - Does the team have the authority to vary scope even as the release deadline draws closer?
2. Is quality acceptable and fixed? - You can't go fast building on crappy code. Agile accomplishes little without the requisite code quality which must be built into the process through TTD, continuous integration, test automation, coding standards and the like. If you see your teams iterating or sprinting with a primary objective of working down code-level defects, then you are not truly agile.

Incremental Value Delivery
3. Is software delivered incrementally? - If your teams are sprinting but there is no feedback until the final delivery (one form of "waterscrumming") then you are not achieving agility as there is no meaningful feedback to drive the solution to an acceptable outcome
4. Is it valued and evaluated? - Demos are great, but you need real value delivery to assure fitness for intended use and early and continuous ROI. If the incremental code is not being actually used, you are not very likely to get the results you seek.
5. Is feedback continuous? - In addition to customer feedback, product owners, product managers and other stakeholders have a responsibility to continually assess the current result. This is achieved through story-level acceptance and iteration-level demos.

Empowerment and Accountability
6. Are the teams empowered? - Are the teams truly empowered and able to modify and improve their own software processes? Do they self organize and self-manage? Are resources routinely moved to the most critical bottlenecks?
7. Are they accountable for results? Empowerment and accountability are two sides of the same agile coin. Are the teams delivering reliable quality code in incremental fashion? Do you they commit to iteration and release objectives, subject to responsible scope management?
8. Do they regularly reflect and adapt? - Do the teams adhere to Agile Manifesto Principle #12? - At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
9. Does management eliminate impediments? - Is management also engaged in continuous improvement? Are impediments routinely surfaced, addressed and eliminated.

The follow-up

We came up with a few actions, including more dogfooding of pre-release milestones, and following up more on the issues identified in team retrospectives. In a couple of months we'll be conducting the Agile Enterprise Acid Test again, to see how we're progressing. This time we'll survey developers, product managers, and the Founders (in addition to the team leads), just to check we're not making stuff up :-).

Clarifications re JavaOne "Web on OSGi" slides

2009-06-09T05:53:23+00:00

It has been interesting watching the reactions to my JavaOne "Web on OSGi: Here's How" slides. A couple of bits of additional information you don't see in just reading the slides:

Very little of the talk was actually about how Atlassian uses OSGi, as it was more general than that. In fact, slideshare seems to not respect hidden slides, so several hidden slides about Atlassian Plugins are shown that a) are confusing without additional information (which is why they were hidden in the first place) and b) make it seem like Atlassian Plugins was more the point of the talk, which it wasn't.
Peter Kriens, the Technical Director of OSGi and a pretty nice bloke I chatted with at the OSGi BOF later that day, made the good point that I should have clarified that our classloader issues were not because OSGi was faulty, but because the third-party libraries just weren't written for modularity. Looking back, the vast majority of our issues with OSGi have been because of a poorly written (from a modularity perspective) library whether it was Jersey, Rome, JAXB, or even JAXP. Unfortunately, the average developer probably doesn't care who's fault it was - just that it worked before, and now it doesn't. I'm hoping Peter's excellent work in JSR-294 and the like will convince developers to put a higher priority on modularity in library design.
Atlassian Plugins is the plugin framework for Atlassian applications that has been around for over 5 years now, so this wasn't something that was cooked up just to hide OSGi. In it, we did have a simple classloader-per-plugin model that just wasn't powerful enough, prompting our investigation into OSGi. As I also mentioned in the talk, though it isn't reflected in the slides, our plugin developers were used to writing plugins a certain way using things like dependency injection, atlassian-plugin.xml as the sole configuration file, bundling jars inside the plugin jar, etc., so a lot of the details about how OSGi was fit into it are done in such a way to keep that feature set and development experience.

I guess this means I'll have to do a proper writeup/talk/both on how and why Atlassian uses OSGi in Atlassian Plugins, so again, if that is what you were looking for, you won't find a satisfying answer in just these slides. The takeaway that I was going for was not that OSGi is just too hard, but that make sure you go into with both eyes open.

We (Atlassian) had some hard problems that OSGi solved, and I've been very happy with it. OSGi has let us write big features in a portable, modular way across products, and has dramatically sped up the development process via its hot deployment capability. Along the way, we've had some issues, particularly with libraries that don't play well in modular environment, but they certainly haven't outweighed the benefit IMO; OSGi certainly does rock.

Atlassian Clover wins Duke's Choice Award at JavaOne 2009

2009-06-08T21:06:57+00:00

Last week at JavaOne 2009, Atlassian Clover received the Duke's Choice Award for Java Technology Tools. Clover was hand picked by the Father of Java himself, James Gosling, for it's revolutionary Test Optimization capabilities which can significantly speed up development.

Here is write-up from JavaOne:

Clover is a Java software code coverage tool with test-level insight, instant IDE feedback, interactive reports and test optimization. Clover allows the Java Code Coverage tool to be superior over other coverage tools. More than just a coverage percentage, Clover provides insight into user testing by identifying project risks and quick wins. Clover identifies specific tests that cover various lines of code and automatically identifies which tests need to be run to cover any particular changes. And because of the IDE integration, all the power of Clover test insight can be harnessed without ever leaving your workbench.

The Duke award was presented to Brendan Humphreys, Chief Code Poet and Technical Lead of the Clover development team as part of James' Java Toy Show at JavaOne 2009. Principle developers also include Slawek Ginter, Nick Pellow, and Michael Studman.

Congratulations to the entire Clover team!! Learn more at http://www.atlassian.com/clover.

Check out the video:

Charlie Award winners

2009-06-08T17:42:09+00:00

We announced the Charlie Award winners at Summit 2009. Amid some fancy schmancy animations that had a passing resemblance to the Oscar graphic treatments (see Charlie's graphic right) our own Hugh Jackman Jay Simons took the stage to announce the winners of this year's awards.

THANKS TO EVERYONE THAT SUBMITTED AN ENTRY!
We were blown away by the good submissions, the fascinating uses of our products in so many different industries, and it was hard to pick just one winner for each of the categories.

With that, the winners are...

The "Not just another wiki" Award: Best use of Confluence
SUN Microsystems, Peter Reiser
What they did: SunSpace is a complete enterprise social platform, serving 25,000 SUN employees (and maybe soon 75,000 Oracle ones), completely built on Confluence, with the help of Adaptavist Community Bubbles.

The "Bugs, what Bugs" Award: Best use of JIRA
Regal-Beloit, Tom Digate
What they did: "Growth Deck", a sales opportunity classification system. Plan to combine with Confluence to build a mini-CRM. Used by the CEO, COO and P&L teams.

Menage a trois Award: Best use of 3 or more Atlassian Tools
Attivio, Rik Tamm-Daniels
What they did: agile platform combining Confluence, JIRA, and Bamboo. Automatically build javadoc wiki space by scanning JavaDoc; fancy issue assignment in JIRA to create different parallel backlogs for business and tech; ant-based system/installation test infrastructure powered by Bamboo.

The X-files Award: Wackiest use of an Atlassian tool
Cisco, Kyle Korner
What they did: iZone, a Confluence-based idea management system, complete with "idea challenges". Uses seven plugins, including Scaffold, linking, add-label, rate and more.

Hacker Award: Best use of a plugin(s)
No entrants for this award... maybe next year!

Only one of the award winners above was present at the time the awards were handed out, so we have some trophies to mail out to the other winners.

We will announce the awards again next year on this blog.

Twitter as a medium for release notes

2009-06-08T02:04:27+00:00

In the last couple of weeks, I’ve been trying an experiment — using Twitter as a medium for release notes. It’s been interesting, so I thought you’d like to read about it. We could use Twitter in other ways related to technical documentation too, such as hints and tips or FAQs. Let me know if you’ve done that already!

I’m going to start with a short introduction to Twitter, mentioning particularly the aspects that I found useful when tweeting release notes. If you’re already a twitterologist, you may want to skip that bit. Then I’ll describe how we’ve used Twitter as a method of communicating the highlights of our release notes.

An introduction to Twitter

Twitter is a service that allows you to send short messages to anyone who is interested in reading them. You can sign up for a free account at http://twitter.com. Then just type in your message where Twitter asks somewhat abruptly “What are you doing?” and click “Update”. Bob’s your uncle, you’ve tweeted.

Tweets

“Short” messages? Oh yes, very short, especially in technical writing terms The maximum length of each message, or tweet as they’re called, is 140 characters. There’s an art to saying something meaningful in such a short message. Especially when the message is a release note highlight. So be warned, you may spend quite a bit of time tailoring your tweet.

The tweet below illustrates a number of conventions tweeters use to make as much as possible of those 140 characters. I’ll tell you more about the conventions later, and how we can use some of them in our tweeted release notes.

Twitter as medium for release notes

Followers

According to some reports, there are approximately 10 million people using Twitter, and its growth rate is around 1,382 (more than a thousand) percent per year. (See Web Strategy blog.) That’s an awful lot of tweets to read. So what you do is “follow” people. Twitter will send you the tweets of the people that you are following. Similarly, other people will follow you so that they can read your tweets.

You can restrict the visibility of your tweets to only people you’ve allowed to see them. You can also block specific people from following you.

RT (retweet)

What I’ve found extremely interesting in Twitter is the conventions that have sprung up as people start using it for wider and more specific purposes. “Retweeting” is one of those conventions. If you like what someone said and want to spread the word while attributing the goodness to the original tweeter, you can “retweet” their message. Simply add the letters “RT” into your message, copy the original text, and tweet away. What’s more, there are Twitter clients that do this for you automatically. I’ve mentioned some clients later in this blog post.

In the tweet illustrated above, Alister Scott has retweeted one of my tweets. Thank you Alister

@ replies

When you want to reply to someone, or refer to them in such a way that they’ll know you’re doing it, include an “@” and the person’s Twitter username. For example, “@sarahmaddox”. Many clients provide a “reply” option that does this for you. Clients also have a separate column or tab showing the @ replies directed to you, so that they don’t get lost in the main stream of tweets.

#-tags and search

Another very useful convention is the #-tag. Let’s say you are sending a message about a particular subject, and you think other people would like to read and to send tweets about that subject on an ongoing basis. This may be for fun or for a more serious purpose. Just think up a keyword, prefix it with a “#”, and include it in your message.

In the tweet illustrated above, I used “#googlewave”.

Here are the realtime results for a Twitter search on “googlewave”. And here’s what people are saying right now about “funnywords”.

Other people will start using your keyword, and they will also search Twitter for other messages that contain the same keyword. Many Twitter clients will do the search for you. Twitter search returns results from all tweets sent by anyone in the whole wide world, not just the tweets sent by people you are following.

Combined with the #-tag, this makes a very interesting combination for our tweeted release notes.

Short URLs

A URL can be very long, consuming far too many of those valuable 140 characters. Luckily there are a few services on the web that will shorten your URL for you. The service gives you a short string that you can include in your tweet (or in an email, or a blog post, etc). When other people click the short string, they are bounced back to the service’s URL and then forwarded on to your original URL. Examples of such a service are TinyURL.com, bit.ly and tr.im.

In the tweet illustrated above, I used TinyURL.com.

Twitter clients

One of the most magical aspects of Twitter is that you don’t have to go to Twitter.com to use it. There are a number of Twitter clients that add useful functionality to your desktop and make it possible to tweet from your phone too.

The clients have built in extra functionality as the Twitter culture evolves:

The use of a #-tag triggers an auto-link. If you click the link, it launches a Twitter search.
The use of “@username”, e.g. “@sarahmaddox”, links to the user’s Twitter profile e.g. mine.
Clients like TweetDeck provide sophisticated search functionality. You can define search criteria using AND, OR, quotes, etc and build a “permanent” search that notifies you whenever a new tweet arrives matching your criteria. The matching tweets can be from anyone, so they’re not restricted to your friends.
Clients supply an easy way of shortening URLs. Some clients do it automatically, via a specific URL-shortening service like TinyURL.com, bit.ly or tr.im. Other clients offer you a range of services to choose from.

I have TweetDeck running on my Windows XP desktop and on my Windows Vista laptop. It’s built on Adobe Air and has a lot of useful features including a sophisticated search capability. Here’s what it looks like. In the left-hand column are some tweets from people I’m following. Next are replies sent to me (via “@sarahmaddox”). The two right-hand columns are specific searches I have set up. All this is configurable, including the order of the columns:

Twitter as medium for release notes

TweetDeck gives a handy notification when new tweets arrive from people you are following, or as replies to you, or that match your search criteria:

Twitter as a medium for release notes

Want to read and send tweets from your phone? Well, you can. On my iPhone, I have both Twitterific and TwitterFon. I prefer TwitterFon — see screenshot further down this blog post.

You can also send tweets to Twitter via SMS. That’s what I did before I got the iPhone. So at least you can tell people what you’re having for dinner, even if you can’t read what they’re having until you get back to your computer

Tweeting our release notes

So, how can we make use of all the above features and conventions to use Twitter as a medium for our release notes?

Aim

To emit a tweet per major highlighted point in the release notes, to include a link to the release notes and to provide a way for tweet consumers to see a collection of such related tweets.

A consideration

In general, people read only the last few minutes’ worth of tweets. It’s not like email, where people make an effort to at least scan their inbox when they’ve been out of touch for a few hours or days. We need to make sure our design catches as many people as possible, and shows them where to go for more information if they want it.

What we did

Here’s the plan of action:

Use Atlassian’s corporate Twitter account, rather than a personal account. Release notes are in a weird place, partly technical documentation and partly marketing information. People follow Atlassian’s Twitter ID and know what to expect from it i.e. company news. So they’re not dismayed to receive marketing-type information.
Use a #-tag to tie the tweets together. This is the most exciting bit. It provides a way for tweet consumers at any time to see a collection of such related tweets. A collection of release highlights is… the release notes. Ta da ♪ ♫
Use a shortened URL (e.g. TinyURL.com, bit.ly or tr.im) to link to the release notes themselves, so that people can read the full details if they want to.
Don’t send out all the tweets at once. This would spam people, and a number of other people would miss out on your news because they’re not reading their tweets at the time. Instead, send out two tweets a day, the second about four hours after the first, for two or three days.
Try it out for three or four product releases, then assess feedback and decide whether to continue.

The results

So far, I’ve tweeted about two of our product releases: the Atlassian Eclipse Connector 1.0 and Confluence 3.0.

For the Eclipse Connector 1.0, I used a tag of “#EclipseConnector10″. (#-tags are not case sensitive, because the Twitter search is case agnostic.) Here’s a screenshot of the resulting search on the Twitter.com web UI, at a particular point in time:

Twitter as a medium for release notes

In the above screenshot, you can see the format we’re using for each tweet: the text of a highlight from the release notes, plus the #-tag (”#EclipseConnector10″) plus the short URL (”http://bit.ly/4mTLf”). Here’s the full content of one of the tweets:

Manage your Crucible code reviews via Eclipse Mylyn’s task-focused interface #EclipseConnector10 http://bit.ly/4mTLf

Of course, the search may or may not show something quite different if you click it now.

What’s interesting is that I tweeted using the Atlassian account (the tweets with the dark blue icon of a dude holding up slice of the globe) and other people retweeted or just repeated the tweets. ‘Coz they liked them. Those are the entries with “RT” in the above screenshot.

For the Confluence 3.0 tweets, I used the tag “#Confluence30″. Here’s a screenshot of the resulting search on the Twitter.com web UI, at a particular point in time:

Twitter as a medium for release notes

And here’s a screenshot showing the resulting search via TwitterFon on the iPhone:

Twitter as a medium for release notes

And you can check what the search yields now.

Nothing can go wrong go wrong go wrong

Heh heh. Take a close look at the two screenshots above. One person “hijacked” our #Confluence30 tag to communicate a problem he had when upgrading to the new version of Confluence, and the workaround for the problem

Of course, it was totally foreseeable that people would tweet problems as well as praise, and would include “our” #-tag in their tweets. Nothing is sacred on Twitter. We decided it would be interesting to go ahead and see the sort of response we get. After all, people are saying all sorts of things about us all the time, on and off Twitter.

The iPhone screenshot above shows the same person’s problem tweet, plus another person who was letting people know about a particular feature in the Confluence release (Twitter-like status updates).

It’s been a fun and interesting experiment.

Other uses of Twitter

People are getting very creative with Twitter. Wikipedia lists some of the unusual situations where Twitter has proved useful.

As technical writers we can probably think up a gazillion ways to use Twitter. We could tweet hints and tips, or even FAQs if we’re super wordsmiths, using the #-tags and shortened URLs much as I’ve shown above. Have you tried this or anything similar?