Questioning your source code

We're prototyping a mess of amazing new FishEye features designed to make it easy for you to ask meaningful questions of your source code (and get straight answers quickly!)  So here are the first few I'm focusing on.  What do you think?  Would you want to ask something else?  Would you find it handy if you could ask your source these kinds of questions?
  1. What did my project look like at milestone X?  And let me diff it against milestone Y?
  2. What other contributors to the project are there (across time)?  (something along the lines of GitHub's Network Graph - only better, of course!)   
  3. What changes are out there in other repos that haven't yet been merged to trunk?
  4. When was this code introduced? 
  5. Select any line of code and say, "Show me all the changes to this line"
  6. Show me a simple source code tree and show the source view for any file that I click.  Then let me have a durable URL to that very line of code that I can email or IM or whatever.

Comments [1]

Google Sydney I/O Talk

Last week I had an opportunity to speak at Google Sydney I/O, essentially a press event to give the local media an insight into some of the material presented already at the “real” Google I/O.  I was asked to speak for 10-15 minutes on “something related to developing for the web…” which is always a fun assignment - “talk about, you know, your products, our products, whatever.”  Unfortunately, 10 minutes is about enough time to introduce yourself and make one point, so that one point had better be interesting.  While I can’t vouch for the quality of the talk, I can tell you a bit about the one point that I made.

In short, I proposed that developers are better at developing as a result of using the applications that they develop for the cloud today.  Clear?  perhaps a bit less short…The process of creating software is social, and benefits from the very social technologies that we are building as developers.    

Unless you’re developing an application by yourself, you interact with others - other developers or QA or PMs or the like.  And even if you are by yourself, you’ve hopefully got users.  So the process of building software involves a chaotic social interaction where an idea becomes code which produces feedback or other issues which produce more code and different ideas.  All of those interactions take time - but time equals waiting and waiting equals losing.  So how do we minimize the time between the steps?  Putting everyone in the same room is ideal - I can just say to a colleague, “hey, take a look at this code” or “what do you think of this UI?” - but that’s clearly not going to happen.  I’ve got one team in Sydney, one in Eastern Europe, I’ve got a guy who works out of his house in Denver.  We’ve got different OS’s, different time zones, different security access protocols, etc.

So how could some of those challenges be overcome using some of the cloud based applications that we have today?  Well, you could use JIRA Studio, for example, plus (oh, I don’t know…) Google Apps.  JIRA Studio is a hosted environment for all of your development needs; source control, issue tracking, agile planning, code review and more.  Google apps, of course, gives you Docs, Gmail and Calendar, Talk, and other services.  So combining them provides the tools to manage the social interactions among the team plus the development tools your team needs to go from concept to launch.  Nothing too revolutionary there, but it does give you three important things that are really important if you're trying to build the next big thing...

  1. Speed - You can start developing in minutes.  There’s no software to download or install or configure.  The JIRA Studio & Google Apps integration is all there.
  2. Minimal Initial Capital - You don’t need to purchase expensive hardware or software to get going.  You can make a minimal investment and then let the solution scale as your needs increase.
  3. Productivity - All of the APIs and frameworks that are available make it a lot faster to get the app up and running.  Much of the complex but un-innovative work such as user management and database access is abstracted.
Since you have all these tools in the cloud, you can build the next generation of cool applications more quickly - which in turn, we assume, will be used to make the generation after that even more quickly than that!

So that was it.  Ten minutes to say “the solutions that we build for the web today make us better at making tomorrow’s solutions for the web.”  Polite applause.

Next up, I’ll be at Atlassian Summit in San Francisco next week to actually show how all of our products accomplish this; and I think they'll give me more than ten minutes!  Hope to see some of you there!

Comments [0]

Code conversations...way beyond pastebins with Crucible 2.3

I’ve used pastebin type services for years as a quick way to share a bit of code.  What generally happens is that I paste some code, copy the URL and IM it to a colleague.  She might be available to take a look at that moment and we might have a quick chat about the code.  Or, she might be out to lunch and I need to remember to ask again later.  Either way the conversation about my code is lost to posterity.

Enter the super stealth “Snippet Review” feature in Crucible 2.3  (and see http://www.atlassian.com/software/crucible/whats-new.jsp

You paste in your code and share the URL with colleagues, just like with any other pastebin.  But with Crucible, a whole threaded discussion can be recorded on the snippet.  Highlight a line or block of the code (which Crucible will nicely sytax highlight for you) and you’ll get to attach a comment to which your colleagues can respond.  Under the covers its’s the same powerful code review system that powers formal peer code reviews in Crucible.  But as a Snippet, it’s less about code review and more about communication about your code.  Reviews as conversation if you will.  


So try Crucible 2.3 for free and see how you can make your development more social!

Tim

Comments [0]

IDE Connectors feedback

JIRA and FishEye and Crucible and most of the other Atlassian tools use a web browser to deliver their user interface.  But as developers writing code all day, much of your time is spent in an IDE.  The Atlassian IDE Connectors http://www.atlassian.com/software/ideconnector/ let you have access to JIRA, Bamboo, FishEye  and Crucible from within Eclipse, IntelliJ, and Visual Studio.  You can create, update, and manage JIRA issues, conduct code reviews, launch builds and more without ever needing to leave the code view and launch a browser.  Best of all, they're free.

Unfortunately we don't have a very good sense right now of how valuable these connectors are to our community.  Some here sense that they're pretty useful and that we could take them much further if we spent some time thinking about how developers work from code view.  But others feel that opening a browser is easy enough and there's not too much value in taking the connectors beyond the basic functionality that they currently provide.

So, I'd love to hear from any Atlassian customers who currently use them.  What's good or bad?  And anyone who tried them, but didn't adopt; what happened?  If you've never used them, was it because you didn't see a compelling need - or were you simply not aware that they were available?

Comments [1]

An app in the cloud does not a cloud app make!

I don't expect that there are many software companies who are not considering some sort of cloud strategy these days.  If Ballmer is "all in" (http://techcrunch.com/2010/03/04/steve-ballmer-microsoft-cloud/), then we know it must be mainstream!  So we have a vast army of vendors whose per-cpu or per seat priced behind-the-firewall (BTF) server products are being “re-imagined” as cloud offerings.  But what does that mean?  What is a cloud version of an existing product?  How does it differ from its BTF predecessors?  Well, what I can say for certain is that just sticking an existing product on Rackspace doesn't make it a cloud application!

 

The cloud itself is really just an enabling technology; a bunch of resources used as a service over the internet.  If a user today accesses an application by pointing her browser at a web app, she doesn’t care whether the database and app server are located in her company’s data center or in EC2.  What she cares about is what the application does.   The IT manager might care where it runs (there are certainly installation, configuration, maintenance, etc. benefits from running an application in a cloud-hosted VM), but the user doesn’t.  So if I, as a Product Manager, say that my company’s cloud strategy is to simply offer a cloud-hosted version of my existing product, I had better be certain that the IT installation/configuration/maintenance challenges that my customers face are grave enough that solving them alone will deliver competitive separation.  I certainly hope that that’s not the case in most instances (although many of us can still benefit from a bit more attention to our users’ initial experience with our products)!

 

Instead, we need to ask what the cloud enables our products to do that would have been difficult or impossible to do BTF.   Consider the transition from mainframe/minicomputer UIs to the GUIs of the client/server days.  Sure, the emergence of LANs, increased power and lower price of 386 microprocessors and microprocessor based hardware made it possible. But as dumb terminals were replaced by networked workstations and servers and PCs in the 80’s, the change in user experience was far more important than the change in architecture.  The same old text based UI didn’t simply move over to a network workstation; the GUI emerged, and users benefitted from a dramatically improved experience with their applications.

 

So as we “re-imagine” our products for the cloud, we need to be searching for the GUI equivalent of today.  What is the quantum leap in experience that we will offer our users in the cloud versions of our solutions?  I’ll argue that it hasn’t been fully realized yet, but here are two areas that I’ve been thinking about lately:

 

1. Vastly increased computing power through elasticity – (warning, this example isn’t very environmentally friendly, but I think it's valid) … If we all had our own electrical generators in our back yard, we would have a very difficult time handling the variable consumption of power.  When we were at work, the electricity being created would go unused, and when we came home at night and tried to watch TV, cook, and do some laundry all at once, we would quickly exceed our capacity.  We would all need to size our generator for the absolute highest peak we would ever need – and that would be far too expensive.  But by hooking up to the grid, we can have all of these appliances because we don’t all use them at the same time (hopefully!).  Elastic consumption is much more efficient when pooled.  Likewise, there are things that we would never propose our products do on the desktop simply because they would take too much time or be too processor intensive.  All of our users would need incredibly powerful workstations instead of the ultralight laptops that they prefer.  But the cloud employs a similar utility model as the electrical grid.  So now we, as software designers, can dream up tasks that are not bound by the limitations of each backyard generator (the local machine), but by the full power of the grid (the cloud).  What are you going to do with that power?  Well, that’s the question! What would your product look like if you could kick off huge complex tasks in the background as your user interacted with the system, for example?  Liberating, huh?   

 

2. Different pricing models – The cloud forces us to rethink the way that we’ve traditionally priced software.  Since the user doesn’t install the software BTF, the old per-CPU model is completely useless.  Currently, vendors are using a mixture of options; per user, per hour, bandwidth consumption based, disk space based, etc.  It’s a great opportunity for us to explore innovative pricing concepts and new business models.  Interestingly, github is trying to do the opposite; go from the cloud to the data-center with their fi product and its “traditional” per-user license and support model.  Are they telling us that there’s no money to be made in the cloud?  Unlikely!  So our challenge as PMs (or anyone who is creating cloud solutions) is to think about how to define the value that we offer our users and to charge appropriately for it. Perhaps it ends up being value based not on usage or consumption, but on outcome.  Interesting topic for another day…

 

The attributes that separate our cloud solutions from our existing BTF solutions are still emerging and they very well may not have anything to do with pricing models or computing power.  But whatever they end up being, I can guarantee they will be distinct.  If you think that customers will be satisfied with that same old app but running in the cloud, think again.

Comments [0]

If your code could talk, what would you ask it?

FishEye has been described as a revision control browser and code search engine: a kind of super UI to a source code repository.  That's true, but it's a rather passive explanation of the product, leading to statements like, "you can use FishEye to see what's happening in your project (commits and changesets)."  It makes the tool a window through which you can view your project.  But as the tool indexes a repository it accumulates a vast amount of information.  Statistics like your total number of committers, number of commits in a given period, total Lines of Code (Loc); changes in LoC can be very useful in understanding a project.  And other statistics like your commit history by month, day, or even hour, and an activity stream to drill down even to the level of the diff of the code that was committed can be extremely helpful in understanding you (or your team of developers') work on a project.  But the more I get to know the tool, the more excited I am discovering that there's even more value to be harvested from its understanding of a project - particularly with the emergence of DVCS (we support git now and are planning Mercurial soon) where a project can have a very complex life with branches and merges happening everywhere.

So as I work on the FishEye roadmap, I'm asking myself, "what can this repository tell us, and how can that answer help developers get stuff done?"  I'd love to get your ideas, too.  If your source repository could talk, what would you ask it?  Would you like it to give up more statistics about your project?  Would you like it to be more insightful about how your code is evolving over time?  Would you like a better sense of how the team is working together on a project?  Etc.

Feel free to use the comments - I'm sure others would be interested, too.  But I'd be glad to chat on the phone (or in person as I travel around) too.  Drop me a note if you'd like to give some more direct feedback.

Thanks!

Comments [0]

Bring us your UX and UI Brilliance

Atlassian has always been focused on great user experience. In fact, it's one of our core values (http://www.atlassian.com/about/values.jsp); solving customer problems with brilliant simplicity. Everyday we try to build products that are useful and that people lust after. We know that good design and experience is not a luxury: it's not an add-on to be picked up if a developer has some extra time on his hands at the end of a release.

To support that goal, we've been assembling a crack team of incredibly talented UX and UI experts. They not only influence our own products, but are also leaders in the field of web technologies and development as event speakers, authors, and all-around magicians of the possible.

But we need more! We want to increase the ratio of designers to developer on all of our teams. We need both interaction design and visual design masters to keep up with the company's overall pace (and it is a blazing pace!)

If you're the best of the best, please drop me a note (tim at buntel dot com). We're headquartered in Sydney, Australia – one of the world's greatest cities (and the one with the best coffee anywhere – and believe me, I've looked!) - and we also have offices in San Francisco and Amsterdam. It's a great place to work http://www.atlassian.com/32/why-join.jsp and we'll welcome you with excitement and elegance (a bridge climb http://www.bridgeclimb.com/ and fancy dinner on us) or a vacation before you even start http://www.atlassian.com/32/get-in.jsp !

I know you're out there: you're spending your days fighting an uphill battle against corporate management that neither understands nor believes in the value of outstanding experience and design. So come join an organization that already believes! We're small enough for your talents to have a real and meaningful impact on the direction of the products, but more than big enough that you'll never need to worry about that next round of VC funding coming through!

Comments [0]

Making Agile project management suck less: Hello Greenhopper 4.3

At Adobe we used what affectionately became known as "modified scrum" and I think that's pretty common.  Not too many development teams that I know do Agile and Scrum exactly the same.  A big part of it for me was always the absence of decent tools to do agile project management.  Sprint planning and task tracking can be spreadsheet hell.  If you're a scrum master, check out the new release of Greenhopper http://www.atlassian.com/software/greenhopper/ Version 4.3 just shipped and it has great improvements to get up and running quickly and (relatively) painlessly.  Nick Muldoon, the GH PM, describes some of the slick new goodness in the blog at http://blogs.atlassian.com/jira/2010/02/get-started-with-agile-using-greenhopper.html

I would have killed for the sprint Planning Board (http://www.atlassian.com/software/greenhopper/features/planning-board.jsp) a few months ago!

Comments [0]

A simple example of FishEye for Flex developers

A number of folks have asked me about Atlassian FishEye. There's broad familiarity with some of our other products (notably JIRA and Confluence) among the AS/Flex/ColdFusion community, but fewer know about our other dev tools. FishEye, specifically, has been an object of some curiosity to many of my developer friends from the Adobe world. As I'm a big fan of illustrations, enjoy the following simple explanation.

FishEye, in short, helps you understand your code. It opens up your source repository (Subversion, Git, Perforce, Clearcase and CVS) with real-time notifications of code changes plus web-based reporting, visualisation, search and code sharing. Yes, that last bit is from marketing content. Sorry. Let me stick to the first part: understanding your code.

I was just looking at the FlashBuilder 4 beta and wondering how the data-centric development features were progressing. I created a page with an empty data grid, then used the handy “bind to data” command to connect the grid up to a ColdFusion component (using the deelightful CF9 ORM features, bien sur)! I committed both the before and after into my git repository on gitHub and then launched FishEye.

Now, gitHub alone lets me see some information about my project.


I can see the raw code, commit history, nice visualizations about branch and merges. But it's not great at understanding how the code has changed over time. About the most I can get is some correspondence between the commit messages and the point where they match up with the current version of the code.


FishEye sits on top of my source code repository and gives me a much more powerful way to look into its contents. I can start exploring my project, get lost of data about its history, and get right down into the code itself (yes, this is a gross oversimplification, so I hope the dev team will forgive me. I promise more details in the future).



One of the nicest new features in FE 2.2 is a new IDE-like side-by-side diff feature. And it was just this feature that allowed me to easily answer my original question about what the data-centric wizard was doing. I could pull up the version of the file from the pre-wizard commit and the version after and, Voila!



The left and right panes can scroll independently, and the view stays anchored around a central point. Color coding illustrates where lines have been added and removed and where the line's internal content has changed. Each addition or deletion is linked to the opposite window by a colored triangle that links to the location of that change in the other version.

Here's a better example...


So by using FishEye, I get an incredibly deep understanding of the code in my project as well as its history. Again, that's just the tip of the iceberg, so bear with me and I'll give more examples soon.  And you can try it out yourself for free at http://www.atlassian.com/software/fisheye/

Comments [3]

The Environment of Software

The Finnish architect Eliel Saarinen wrote, "always design a thing by considering it in its next larger context—a chair in a room, a room in a house, a house in an environment, an environment in a city plan."  Software product managers need to do this with their products, too.  Consider the program on the machine in the office of the business.  And most of all, consider the user in the midst of it all.

Comments [0]

About