Marc Palmer

I just had a brainwave. For a little while I’ve been wondering about how ineffectual setting the Component seems to be in Jira. Many end users don’t know what component the issue affects, initial assessment is often wrong, and most of the time it just feels like you are entering data for data’s sake:

Add to that the fact that Jira does not support per-component versioning (AKA truly nested projects) and Component seems pretty redundant; it can only used in searches or in the Open Issues tab to break down by component.

With the popularity of tagging in applications like Flickr, iPhoto, delicious etc I wondered if this might work better for grouping issues.

Also I’ve recently been working with a client for whom I have setup all the initial tasks we have but I need them to prioritise them for me so that I can tackle the most important ones first in a series of incremental code builds. Changing the issue priority is a coarse way of doing this – I want to schedule these into different release versions in the roadmap, and have sensible priorities on them within each version. Also, if I re-edit the priority later I lose the information that the client provided about the importance of this issue to them.
I realised that tagging would help here. Tags like “must have”, “very desirable” and “wish list” are concepts that people can relate to, and allow me to preserve issue priority information (which applies per release rather than globally).

I thought of adding a custom field as Jira has great support for these, and includes them in searches etc. However it might be a bit too loose – my clients may not know what tags to type in, spell them wrong etc and we end up with a mess.

Then I realised. Component field settings ARE tagging but with the wrong name. I’m going to set up “components” (in Jira parlance) for “Must have”, “Very desirable”, “Wishlist” as well as other non-priority terms like “Web”, “Search”, “Content”, “Browser compatibility”. These are not strictly components at all but if you look beyond the name you can get exactly what you want – and even better, the Open Issues tab will now show me how many “Must have” issues there are etc – and provide links to view lists of them so that I can review them, bulk change, and assign them to versions in my roadmap.

We can’t rename the Component/s field to “Tags” in Jira – maybe they will do it for us in future… but for now in Jira setup (Issue Fields) we can at least change the description to explain the tags concept to the end users.

I had the pleasure of attending a free Groovy and Grails seminar hosted at SkillsMatter in London by Dierk König and Graeme Rocher.

Having used Groovy already for some months but not having had time to extensively learn its full feature set, I found out some interesting things I hadn’t noticed / remembered. This includes ranges and using exotic objects as “case” conditions in switch statements. No more the horrendous “if…then…else if…” chain.

As for Grails, it was great to be able to interrogate one of the main protagonists (Graeme). I’ve only been playing with grails for a couple of weeks but it shows huge promise, and Graeme and the grails user mailing list members have been most helpful.

I’m looking forward to trying out the Ajax stuff and also doing some exploratory work on strapping WebMacro views onto it to replace the GSP (Groovy Server Page) view which in my opinion is just as bad as JSP in that it allows all manner of scripting sins within the view – but nicer than JSP in that you can expand values anywhere in your document without resorting to a tag.

Of interest was the realisation that “grails console” exists as a command and allows you to perform quick tests and examinations of your domain model. Also Graeme told me how to include template content in views across controllers (<g:render template=”/common-template-path.gsp”/>). As I’m not yet a SiteMesh convert (reparsing the response and requiring full render before delivery starts?!) I like to do headers and footers etc the “old” way.

I’ll also be interested to see how the WebTest integration will handle functional testing of Ajax driven sites.

Dierk and Graeme are running some Grails training courses at SkillsMatter later this year, I strongly recommend them for anybody who wants to get a foothold on this exciting and fun new area of programming for us tired Java hacks!

I’ve been using Jira issue tracker for some years now for software development. I’ve also helped to roll it out at several client sites, which has given me the opportunity to see the different ways of approaching the issues of release versioning and dealing with workload and build cycles that have to hit hard deadlines.

These days I’ve hit on what I think is the nicest way to approach it. Jira’s excellent Roadmap view is king here. It shows you the status of issues assigned to different fix-for versions. You can view the next 3 unreleased versions on one page, or have it show you all unreleased versions. The key thing here is that it only shows issues that have a fix-for version, and then only for versions that have not been marked released.

The key objectives I have for managing software release cycles are:

1. Know clearly in advance what you plan to include in the next release. Everything else is for the future.
2. Always have a discrete version number for every release – don’t have 20 release builds all called v1.3
3. If you have a hard deadline around the corner, be rational and bail out non-essential work – roll it over to the next version.

This is now a staple routine of mine and works very well. It is simple and helps to manage workload. Those of you that know about “Getting Things Done” will see some parallels in this later.

OK I’m a self-confessed Jira fan-boy, but Jira makes it easy to manage releases like this if you know how to use it. However there could be improvements, which I will mention later in this post.

Now I’ve seen a lot of people who just set the fix-for version on every issue to the first unreleased version. This is bad news full stop. It’s OK if you’re not the project manager and its an open source product and you don’t know what the plan is – but really the current pending release should already be planned out and not accepting new features – after all if you follow this kind of approach you are planning your next release while working on the current one.

What you end up with in this scenario is lack of direction – every issue logged against the next version. It is a giant insurmountable mountain and nobody knows what is really going to be in the next release, and it looks like there will be little or nothing in future releases. With public projects this is particularly important.

On the flipside, the worst thing you can do in my opinion is not set any fix-for version so it ends up in the dreaded “Unscheduled” category in Jira which does not register at all in the Roadmap – and thus the roadmap does not give you your complete view of upcoming workload.

So here’s the idea:

1. Administer your project in Jira, and add a “Wishlist” version that is the very last version in time order – and will always remain so
2. Create at least three minor revision version. If your product is on 1.0 in marketing terms, create 1.0.0, 1.0.1 and 1.0.1 for now. I always try to keep another 2 future revisions available in the version list – which means adding a new one to the end (before Wishlist) after you release every version. This is particularly important if you are on very short build deployment/test cycles. I’ve successfully used this approach with release cycles of 1-2 days during internal QA.
3. Perform a review of all existing issues. View all unresolved issues on your project and use the often overlooked Bulk Change feature (top right in issue navigator) to change the fix-for versions of issues en-masse to schedule your next 3 releases. Be rational – don’t overload the next release. Anything that you’re not sure about, put it into Wishlist
4. From now on you create all new issues against the next version (not the current) unless they are killer issues that have to go out in the imminent release. If you have no deadlines you can ignore this, but software with no deadlines – at least internally set ones – tends not to see the light of day.
5. Now on a day to day basis you use the Roadmap view, and even more conveniently in a team – the Personal Road map option, to see what your tasks are. Clear and simple, you see precisely what there is to do. Feel the relief!
6. You also see on the roadmap view a bar show % completeness of this release. Once it is green and 100% you can release. Then you go to Administer Project and Release the version in Jira. This is vital, and is often overlooked by slovenly managers. This step updates your roadmap so that this completed release is no longer listed – but it is shown in the Changelog view now and you can produce release notes.
7. Perform a review regularly – although typically at release “crunch” time. What’s left in this version? Is it really needed? If not, enter the “BAIL OUT” technique – use Bulk Change to roll over the issues to the next version – don’t wait for the “Release” function of jira to roll the issues over! If you do, you will have deliberately scuppered your own plans. Review issues in the Wishlist periodically or use Jira voting for them and look at the Popular Issues view. Is there something to bring into the next release from there? Change it’s fix-for version individually or bulk change if there’s a batch of them

For us at least this approach gives us great peace of mind. Our eyes are always fixed on the roadmap.

We know what needs to be done to succeed.

We know that no other idea or requirement is lost, it’s always there on the Wishlist version.

We know that the rational solution to unreachable deadlines is to defer or “bail out”. It’s OK to do this because we know that those deferred issues are going to come in the next version if they are important, and we have already planned for this.

As for my wishlist for the Jira Roadmap, these have been stated before. I only wish I had time to implement it as a plugin (I did make a start but problems with DWR and Jira’s plugin mechanisms scuppered me):

• The Roadmap (or maybe a new Remap feature) needs to allow Ajax-driven drag and drop of issues to “tabs” representing the release versions. Dragging and dropping further down a long roadmap page will not be user friendly.
• There should access to a well of “unscheduled” issues that you can drag and drop into a release version
• There should be version “nudge” functionality to select any number of issues in the view and nudge them forward or backward a version
• Popup hints on the issues should show you who they are assigned to
• Drag and drop should be supported to perform bulk transitions – i.e. drag items and drop them onto a lozenge marked “Close” would take you to the bulk transition flow to mark the issues closed simultaneously.

The more I have to use these online property sites (for purchase or rental) the more it drives me nuts. The people behind these sites obviously lack enthusiasm when it comes to usability or user-oriented design. Have they thought that many people may be using their site on a daily basis for six months or more?
Here’s some free web application and usability tips for any of the people working on those sites if they are listening:

1. AUTOMATICALLY remember the properties people have clicked on. This is far more useful than any “add to basket” feature, especially when the page titles are rarely informative so browser bookmarking and history are usually useless. This is trivial to do, with a link for “Recently viewed properties”.
2. AUTOMATICALLY remember the searches people have used. When they return to the site, offer to let them run the same searches again – separately or as one big result list.
3. Following on from (2), automatically only show new results that the user has not seen in a search result before – with an option to view all that would apply in a given date period (i.e. updated in last 7 days) for the cases where people have given up half way through the list. Alternatively have a “Mark these properties as seen” option at the bottom of each page of search results.
4. Don’t allow agents to post properties that have no data other than price and area and number of bedrooms. You have a quality of service to maintain to your end users, and as soon as they have to reach for the phone to get useful property details, your service has failed the user and most likely the agent. I’m sure most of them prefer people to filter houses online rather than on the phone.

Here’s hoping that someone pays attention and actually produces some quality software that people can enjoy using!

While reading the excellent Lifehacker site’s blog this morning I happened upon an article on site YourGreenDream which carries news about environmental developments and so on.

The article is about a company called Prism Solar Technologies that has developed a method of using a hologram over a layer of glass to redirect sunlilght to solar PV cells. What this means is that you can need far less silicon.

Hopefully if this makes it to prime time this could have several major effects – you can generate the same electricity now for a much lower investment, you can generate a lot more from the same space and same amount of money you might spend on PV now (power a whole house with a rather big panel?) and even better for us in the UK, I imagine it might mean that PV power would be viable on a domestic scale even in the winter. I’d be interested to know if this is the case.

Apparently the increase in light hitting the cells is “only” 10x compared to other lens/collector solutions which can get 100x – 1000x improvements (wow) but are no doubt far more expensive, and the main selling point for this is getting cost down by reducing the amount PV cells required.

I’m wondering if you could actually make an attractive glass roof out of this however, and spend the same on PV that you would in today’s market but get a whole lot of power.