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.

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.

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/

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

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

• 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!

• 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

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

Register for a session now by clicking a time below:

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

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!

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!

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.

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

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 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

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!

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

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

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

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

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.

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:

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.

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.

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

• 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.

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.

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.

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!

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!

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.

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.

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?

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.

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!

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.

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.

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.

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

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.

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 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.

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


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


3. Studio gives you GreenHopper agile planning tools for free.


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


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


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


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


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


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


10. 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.

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

• 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 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.

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.

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!

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:

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.

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!

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.

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

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.

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

Taras Naumenko

Morgan Friberg

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.

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;
  }
 }
}

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.

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.

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.

REGISTER NOW: Thu, Jun 18, 2009 9:00 AM - 10:00 AM PDT

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.

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

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

• 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.

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:

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.