techno.blog("Dion")

Man, I haven’t been as excited about a development tool as I am about Joe Stump’s Sprint.ly in a looooong time (GitHub is probably the last time).

It is an incredibly timely tool for me. I use a variety of small tools for different projects. Open source hacking vs. large projects at work with a bunch of different teams.

I enjoy Pivotal Tracker, and have even begun to appreciate why I have to use JIRA…. and thus, for some projects I am forced to use both. This is far from ideal, and every few months I look to see if I can shoot one in the head to focus on one tool.

For some context, I should write down my high level believes around creating software products, and then we can talk tools.

If I try to distill my beliefs I get:

Responsibility

Everyone in the team builds software products (and should be empowered). Great organizations push down responsibility (yup, even Steve Jobs). This enables teams to have minimal bottlenecks, and by enabling the teams they will enjoy their work more, and will care. How many situations have you seen that end up with “well, some bozo boss told me to do that…. so duh, I did it… and of course it was dumb!”

Communication

The closer everyone is to a shared understanding the better. There are many levels of communication, on a variety of themes. In general I believe that a business/group should trickle down: business goals -> strategy -> high level roadmap -> products that fullfil.

Planning

Some people tell me that agile == an excuse not to plan. This seems to stem from people thinking that “we can’t see into the future” means “we shouldn’t plan, and instead react.” This is almost always a false assumption :)

If you aren’t thinking about the future and “skate to where the puck will be” then you can only ever slowly evolve. As an example, right now at my company we are trying to re-imagine what commerce and retail could be like for customers 5 years from now, and we can back track from that. Not being able to see in the future means that you end up making bets, but it is critical. This planning and thinking is all about product vision. It is not set in stone, and it can evolve itself. Steve Jobs thought that the network computer would be the future at one point (he was friends with Larry after all ;) but we still have hard drives.

Execution

I don’t favor complex planning tools. I like the basics. There are a list of things that need to get done for your product. You have people to work on making this happen, and you can prioritize the work. You need to keep on top of the queue of work and keep changing the prioritize tactically.

To execute you need all roles firing. Product management, engineering, UX, QA. The role of “stories” can give a high level common language that can be a great starting off point to interface these roles.

Although you can’t look into the future, the longer that a team has worked together, and the longer a project is in place…. the better chance you have of knowing how true your view of the project is.

So, with this all in mind, how do some of the tools stack up?

Pivotal Tracker

Tracker has been a great tool for development. It fits in to a lean methodology and the “queue of work” mentality. I find the UI very simple, and with one screen and keyboard shortcuts all interactions are fast.

The integrations, including Campfire (critical for communication), JIRA and others are crucial…. since no One Tool has been the solution.

There are some things that I don’t like though:

• Although each story has a URL, if you go to the URL you get the entire UI loading… and then your item pops in (vs. a simple page with just that content)
• Stories have tasks, but you can’t assign different people to those tasks. So, if you wanted to have a QA task and a design task as well as a development task…. the assignment breaks down. With JIRA you could use subtasks just fine, or you could use an assignment workflow
• No ability to make bulk changes
• Searching is a lil weak
• Tags end up being the Solution For Everything
• “The application has died. Please reload.”
• Reporting is weak. Tracking the backlog and tying to versions etc is hard.

JIRA

JIRA is an issue tracker. It is incredibly complex compared to tracker (and Lighthouse and Trac …) and you can extend the data and workflow behind it. The complexity is frustrating to many though. Having to grok Projects, Versions, Components, labels, issues….. is more than you often need.

It does let you have nuanced views on the data though, so you can make it do the right thing for the different roles. Searching is rich (there is a query language for the beast! eek :/) and you can slice or dice all day long.

I do not like JIRA for main development and tracker is for that…. but JIRA comes into play due to QA and other groups knowing it well.

I have tried Greenhopper a few times, trying to see if that view can take the place of Tracker, but it is overly complex for my needs and a frustrating experience. First, you need to configure things (setup a Ranking Field blah blah), and then you think that you should be able to drag things around and it never quite works right for me.

There are other things that bug me about JIRA too, such as:

• The emails. They hide the interesting data and I need to look carefully to see what the heck it is trying to tell me!
• The performance of onjira.com…. I keep picturing OFBiz trying to keep up
• How is there not a simple Campfire integration???? Really? I have to use Hubot?

Asana

I enjoyed meeting the Asana team, not only because it was fun to chat about their platform (Fibers and such), but also because they are trying to make Enterprise software not suck. The meta-system for master-detail is definitely something that you can use for planning and executing software products. It was a little too meta for me though (this was early beta) and I wanted some more features specific for software than custom fields to use. Also, the fact that there wasn’t a way to access on mobile or API to tie into integrations, mean that it isn’t there yet for me.

GitHub

GitHub is amazing. It is an integral part of my software development and I think that these guys and this product could keep growing to Own It All if they so fancy. I like GitHub Issues, but they are still a little too simplistic for me for larger projects. For some open source projects of mine they are perfect, and having the great integration with code, commits, and pull requests is spot on. Working with larger cross functional teams though…. not so much. I again need more than “well you can use tags and a taxonomy to kinda make that work.” I very much do appreciate their vision, and how fast the tool is to use!

There are so many other tools across the stack (Lighthouse, Trac, VersionOne, ….) but I won’t go on and on.

Sprintly

If I look at the things that I believe in (up top), and the things in tools that I have used over the years that I like and don’t like, and then map this onto a “tool I wish I had” I quickly see that a lot of those features map on to Sprintly.

I haven’t even used it yet, but am very much looking forward to giving it a go. It seems to be the sweet spot around:

• Thinks about cross functional teams
• Stories and tasks in a way that makes sense (assign tasks to different people)
• Great dashboard: visibility FTW!
• GitHub integration up the wazoo
• Looks beautiful!

It looks great already and it is probably a 0.6. I hope they keep pushin’ and make I can use GitHub+Sprintly as my go-to pair…. and I can leave the rest behind.

Has anyone been using it and thinks it stacks up? What other tools am I missing? Michael Mahemoff is a Trello fan :)

Do you sometimes feel like the browser is a black box? We are building richer and richer applications on the Web platform and this means that developers are running up against new issues to debug and test.

We feel like it is a great time to develop new tools that afford you the ability to look into the runtime to hopefully help you find a bug, or allow you to keep your application as responsive as possible.

Today we want to start a conversation about some of our thinking, with the hope that you will join in.

We have been taking a hard look at the tools landscape, and here is a presentation that gives you an idea of our thinking:

We will be posting more of our thoughts, but as you can hear, our vision for these tools is that they:

• Are able to run out-of-process. We view out of process tools as the preferred way to observe the runtime because it enables us to somewhat ignore the Heisenberg uncertainty principle. If we are profiler the browser, having to deal with NOT profiling the profiler code can be painful. Also, we want to be able to use the same tools on devices. I would much rather point my desktop tool to a Fennec device, compared to trying to use the tool on the phone itself! This leads us too…
• Enable cross browser experiences: Our lab doesn’t have the resources to develop deep integrations with multiple browsers, but we very much want to enable that. Since we are running out-of-process, we can document the communication API and many hosts can then be wired up.

The first experiment in this vein is a stand-alone memory tool prototype that lets you poke around in the JavaScript heap. What objects are there? How many of them are there? Any dangling references due to closures or event listeners?

To kick this off we worked with awesome Mozilla colleagues such as David Barron and Atul Varma which enabled us to spike down to the bare metal of the browser.

We ended up with an architecture for the tool that contains these components:

Firefox Add-on

A special Firefox add-on installs a binary component that gives us access to the low level JavaScript heap. This gives us a simple API with methods that allow you to enable profiling, get the root objects in the heap, and get detailed information on the objects themselves.

Firefox Memory Server

The current consumer of the core API is a min server. Once activated, the browser freezes and your only option to interact with it is via this server. It exposes a simple socket API with URLs mapping to the high level APIs. For example, you can access /gc-roots to get the root object ids. Or you can ask for details on an object via /objects/XXX where XXX is the object id you are inspecting. When you are done, you access /quit and the browser is unfrozen.

All of these APIs support JSONP which is how we get the data back into our main application.

NOTE: Currently, the server lives within the add-on itself (at chrome://jetpack/content/memory-profiler-server.html) but eventually this will migrated to a Jetpack.

Memory Tool Ajax Application

The main application itself is a simple Web application that can be run in any browser (not just Firefox!) After you have installed the Firefox Add-on, and turned on profiling via the Memory Server, you can visit the tool. Currently, after you connect, the tool gets a dump of the root object for the first tab in the browser (not including the memory server tab). You will see the meta data associated with the object, and you can click on any of the data elements that have their own memory id (memory locations are integers with 9 digits). This tree view lets you poke around the heap.

If you want to aggregate the data, you can click on the “2. Dump Heap” button, which goes through the entire heap (which can be big!) and aggregates all of the objects for you. If you see a massive number of objects of a particular type, this could be a flag!

Enough talk, lets see it briefly in action:

The tool is very early stage and changing constantly. However, it is all out in the open. You can grab the open source pieces:

• Firefox Add-on (currently includes memory server)
• Memory Tool Web App

As is always the case with Mozilla, and Mozilla Labs, we want to get ideas out into the community as soon as possible. This tool is very much alpha, and the goal of getting it out in the wild is to start a conversation about tools like these.

What tools in this area would help your job as a Web developer? We are all ears, and would like to share our dev tools mailing list / group as a good area to share ideas.

What about Firebug? This particular tool freezes the browser, and since Firebug is in-process right now, it wasn’t a great fit. However, we very much want to take this kind of work and get it into Firebug at some stage. We just aren’t at that stage yet!

On our side, we will be engaging with the Mozillans who truly grok the JavaScript (and entire browser) internals to see what interesting data we can expose to developers. We have found that the Firefox team has already added a lot of the infrastructure there, and now the task is to work out what will be useful, and how can we best report it.

We have plenty of ideas too. A wish list could contain:

• Short term clean up (fix the backend code that interfaces with the heap, abstract out the service into a Jetpack, and make sure we are using the correct APIs, and get these APIs added where appropriate)
• We want to visually add the graph to the object dump, so you can really understand what you are looking at. It will probably look something like this:

  

• We have wired up Bespin, and we will suck out the source code from functions and showing that inline to the tool itself. There is much more to do though, and we want to find out what you need.
• More profiling info: break up buckets of memory (images, js, DOM, etc)
• Great way to see who is reference whom (memory leak detection)
• Garbage Collection: When and how long are collections occuring?
• Granular filtered profiling: Profile this event and measure every event-of-interest from the start of navigation to the present e.g. DNS & TCP connections, page header parsing, resource fetching, DOM parsing, reflow, etc.
• Web Worker thread monitoring
• Have a profiling mode that gives you data without having to freaze the heap, and only when you need to do a deep dive do we get to that.

We have learned a lot as we created this prototype. Atul is going to write up his experience, and we will continue to talk in the open about how we take this prototype and your ideas to the next level with browsers.

Update

Atul has posted on his experience with SpiderMonkey and how the JS Runtime works. Nice in depth stuff. He also created PyMonkey “a Python C extension module to expose the Mozilla SpiderMonkey engine to Python.” which is crazy cool.

Dave Thomas gave a great keynote talk at RubyConf this year titled F**k Ruby (where the term was for Fork ;).

Dave is a very enjoyable presenter to listen too. He always has some of the British humour that I am of course partial too.

I loved how he managed to use the Scottish term Tath:

The luxuriant grass growing about the droppings of cattle in a pasture.

His talk is embedded at the end of this post. The Ruby stuff was very interesting and great, but what stuck with me was the early talk about loving the tool that you work with every day.

As programmers (Dave always titles himself as “programmer”) Dave talks about how we get a blank sheet daily, and if we don’t love the tool that we get to use to make the creation that day, then we will not do the best that we can, and it will show in our work.

I can totally relate to that. Sometimes we may think “use any tool as long as you create somethin useful.” Stick with Java even if you fancy doing something with Rails/Django/… because it is the safe choice.

If you are having fun and loving your tools then you will create (or adapt, which could simply be with config, plugins, or whatever) something so much better. Of course, as I now run a developer tools lab with Ben I don’t think of “tool” as just a programming language, but much more. Your entire environment. The items in the box.

As 2009 rolls around, I can’t wait to create some tools that I love. Something that makes me excited to start building something new. And not only for myself, but hopefully for some of the Web community.

Happy new year, and let’s listen to Dave: