You’ll need:

• The Url of your Jira server (I’ve only tested with ondemand)
• Username and password to an account with rights to export xml
• This list of jira fieldnames (not the same as jql)

Now open a spreadsheet or create a new one.

Now insert something like this.

=ImportXML(“https://yourserver.atlassian.net/sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?

jqlQuery=project+in+%28%22Projectname%22%29+ORDER+BY+Rank+ASC&

tempMax=1000

&field=summary&field=timeoriginalestimate&field=timespent

&os_username=alice&os_password=bob“, “//item”)

You need to change the text in red to something that will work for you. And make it all one line – I just broke it down to make it easier to read.

As you can see I’ve listed the fields I need – you don’t need to do this if you don’t mind getting a lot of data. Remember to use the fieldliste above – not all fieldsnames match their jql names.

The last part of the statement – the xpath – tells google doc, which xml elements to extract. It’s actually a bit to simple her, as the timeoriginalestimate and timespent fields have a “seconds” attribute, that may be easier to work with the the text “2.54h” text returned by the field it self.

Change the xpath to something like “//item | //item/timespent/@seconds | //item/timeoriginalestimate/@seconds” to get the attributes (which is a bit useless for what I want as google places them on separate rows and only does it if there actually is an attribute – which makes it hard to know which value was returned if only one fo them exist in the xml – I’ll note it here what I end up with). The alternativ is something =if(C9<>””, value(left(C9,LEN(C9)-1)), “”) on the hour columns.

Have fun!

Best of both worlds right?

Well it isn’t exactly fast. Here’s a few rough timings:

Windows boot cold to online: 170 seconds

Boot virtuel ubuntu maskine to login: 53 seconds

Start Aptana (in virtual machine): 54 seconds

Start rails (in virtual machine): 35 seconds

So I found my old desktop, which I though had died, but fortunetly it hadden’t, cleaned it up and installed ubuntu(a bit old and slower CPU (dual 1.8GHz, 3Gb Ram)).

Boot ubuntu maskine to login: 50 seconds (about 15 of those are bios)

Start Aptana: 20 seconds

Start rails: 15 seconds

Quite a bit faster – and best of all, it doesn’t seem to lock up all the time, like the Virtual machine did..

I’ve long had a feeling that, at the end of the week, the more visual aspects of the tasks at hand had had less “love” then they warrant. Lets say we add a new page – all the new fields will be there, the new needed functionality will be implemented, but the visual glue, that’s supposed to pull it all together is somehow missing. It gets pushed to next week, where the same thing happens.

Sometimes we working from photoshop generated mock-ups, and the designer will have spend most of his time making sure the alignments are just right, or the color gradients are just as they should be.

All of this usually gets low priority with the developers – “it’s not crucial” – and it isn’t. In the pressure to have somethings to show off on Friday, the visual elements, paradoxically, gets down prioritized.

The Problem

I understand why this is – the developers focus on the hard stuff first. They want to know that the core is okay, before they spend time on other things. It’s more important not to have errors, than to have “bling”.

But at the end of the week – when we demo the changes implemented, we also have a system that doesn’t look as good as it could. When the only comment we get is “Why is that button still green? I though we agree it should be red?”, after the demo of some nice new feature, you get the feeling that nobody saw anything, except for the missing red button.

And I understand this too. The business people can only see the surface (the UX). So you added a ton of code behind a field in a form and switched from one framework to another and upgraded jquery and fixed the broken dependencies… and all they can see is that it’s the wrong color.

What we have been doing until now, was to take out a week, once in a while, and only do the visually oriented stuff, that normally gets down prioritized and focus on them, without any functional issues getting in the way. This works, but it doesn’t solve the issue of the Friday demo.

A possible solution

I want to add a bit of priority to the “low priority” of the visual issues, and currently my idea is to do what I want to call Visual Impact Priority.

I don’t want to throw away the usual priorities, but I want to add an extra step in the process.

The idea is to simply look at the page/task as it is, and select the lowest hanging fruit/task that will have the biggest Visual Impact on the system.

The way you calculate this is very dependent on the system, but very concrete things like the number of pixels involved and how big the color change is, could be a place to start. Change a small area a little bit – Small Impact. Change a big area a lot – Big impact.

Changing a the background color of a page from black to red will have a huge impact on the page, and take all of five seconds to do. Changing the headline color from one shade of gray to another, is probably low impact. Changing it from green to red, is bigger impact as it will be noticed. Adding a new field to a form, will have a big visual impact. Even if it doesn’t have all the bells and whistles it’s supposed to have.

It’s a bit like having two priorities on all tasks. One if “Functional (Impact) Priority” (FIP) and one is “Visual Impact Priority”. And you alternate between them. Sort the task list on FIP. Take one from the top. Sort on VIP – take one from the top. Repeat.

And it doesn’t mean that you can’t slice the tasks. Maybe the specification is for a nicely graded green header. Making it green takes a minute. Making it graded takes an hour. So you spend a minute and make it green. Huge impact. And it allows the designer to see that green wasn’t that great a choice and he can change his mind, before you spend that hour doing a graded version.

I’ll let you know about our experience with this, when we’ve been doing it for while.

p.s.: I’m using word “Impact” in my priority-types to indicate that the balance between how important something is and the amount of works that goes into it is important. Your basic Return On Investment assessment thing.

It’s mostly a question of missing context and having the wrong audience. Allow me to explain.

But first a somewhat related video – not directly related, just the one that made me remember these thoughts.

So imagine you are a software developer (or something else, but not a “sales guy”), sitting in a room that’s 50% developers, %30 sales guys and the rest is management. One of the C-Level managers is giving a status report – it’s not going to well. Sales are down.

He is saying stuff like “We need to sell more!” (without explaining how that’s going to happen) and “We need to focus on closing!” (like the sales guys didn’t know this). All the while the dev guys will be nodding, waiting, reciting Pi in their head and just try not to look bored. They have heard this before.

“Everybody needs to sell – you all need to sell.

You all have a responsibility for closing those deals!

You are all sales guys!”

<Bangs fist in table – points around the room>

Thank you everybody and goodbye.

What just happened?

Well, firstly notice how this card is never pulled, unless the company is in deep shit. It’s a desperate step, that is though to pull the company together – to put everybody in the same boat. We are all sales-guys. I’ve rarely seen this card pulled, without somebody or a bunch of somebodies being fired shortly after.

Secondly you just told the sales guys, that they suck so badly at their job, that a bunch of developers and administrators can probably save the day. Sell the stuff they didn’t manage to sell with their 10+ years of experience. Probably not that inspirational.

Quite a few developers are a liability in the sales process (not all). Yes, there should be lots of collaboration between sales (they are a customer of the product as much as anybody), and the development team, but taking a random developer to customer meeting is mostly a liability.

A developer will say things like “Yeah, that sounds easy, it will take a couple of days to develop” to the customer when the real answer is “The value to you will be  999 and I think you’ll be willing to pay 555, so we will need exactly 555 money to make it” (just packaged differently) – which is usually a lot more then what will be charged for two straight days of dev time. Also the first estimate of the dev will be low (he’s bragging – I know, because I’ve done this).

The developer will go back to his desk. Shake his head and forget it – if he’s lucky. He might feel a bit depressed, because he sees this, for the desperate move that it is. He sees the future. Okay, so lets say he thinks a bit more about this.

What does he know about sales? Well, the sales guys seems to be talking a lot with (potential) customers. They seem to call customers and “sell”. Sell might be stuff like explaining why the product kicks ass and why the customer needs it. More meetings and then it will sit in pipeline for a while and then disappear. Hm.

Where does the customer come from? Random dialing? Randomly browsing the yellowpages? Some sells guys seems, to sell the new product to all their old customers/friends, and then run out of steam. Does the dev know anybody interested in the product? What will his (dev-) friends think of him if he calls them and tries to sell them something? Will they ever talk to him again? Probably not. Probably better to call and ask them about any job openings, than alienate them…

The dev has only been in one real sales meeting before, which he though went pretty well, he even managed to respond with a quick estimate to a question from the customer, but his recollection of what really happened there are hazy. Did we “close” that deal? Was it good? Probably – didn’t a few weeks of development work came out of it?

So the developer spends the rest of the day twirling his office chair, staring into the air, waits for somebody to tell him what to do. The next day, he’ll be back to normal, with just a small nagging doubt that something bad looms in his near future.

Does it ever make sense?

Well, yes. If you make it clear what you mean by it.

But mostly it’s common sense – because it’s something, that you should be doing every day. Whatever it is you are developing, it is going to be sold. Somehow, somewhere, somebody is going to give you money because of that product. That’s “sold”.

Developers are sales guys only in the sense, that they make products that has to be sold. If they are really good (and the market is right) they make a product, that sells it self. You are in sales, because every time you spend resources on a feature or function, you remember that the time you spend on it, needs to be financed by a customer. Maybe not today, but one day.

Now you are selling.

Still doesn’t make you a sales guy.

(that takes brass balls – being a developer takes balls as well, but they don’t have to be brass)

p.s.: If you don’t know if a function has “sell” value, go ask for a “business case” (I’m really hoping you already have a “use case”). Ask you product manager, ask a sales guy, make one. Maybe collaborating with a sales guy, maybe having him add a real (potential) customer to the team. Go!

A Deepness in the Sky

The Qeng Ho (human traders) and the Emergents (also humans, but more top controlled) are both racing towards the OnOff star and it’s single planet. A planet inhabited by the first hi-tech alien civilisation that humanity has meet. Immense riches wait for the group what gets to trade with the aliens. The Qeng Ho and the Emergents has a small clash when they arrive at nearly the same time, won by the Emergents, but damaging both groups so much that they are forced to co-operate. A lot of the book is about the fight between the two different ways of life, as represented by the Emergents and the Qeng Ho. Most of this can be read as a long tribute to the old Heinlein and Poul Anderson stories (like Trader to the Stars). I enjoyed this part of the book a lot. Lot’s of interesting surprises and plot twists.

The other part of the book is about the aliens, which I’m sorry to say, kind of bored me. They where simply put not alien enough. Most of their story, but for a few references to extra arms and such, could be read as a quite normal story about the industrial revolution, and even if Vinge gives a good reason for this (the way of the translation) this doesn’t change the fact that it bored me and the references to the earth of today was kind of clumsy if not downright silly. A couple of hundred pages of boredom about the industrial revolution entwined in five hundred fantastic pages of intergalactic culture clash, doesn’t kill the book or even make it a bad book. It’s still one of the best books released the last ten years

Amazon.co.uk – Amazon.com

• Something physical. 10-20 minutes before I start, I do twenty push-ups or similar. Something to get my blood pumping. Allow enough time for your breathing to become normal again.
• Clear my nose. Make sure breathing is as unhindered as possible. Sometimes I use saltwater spray to help.
• Close down software. Close down Skype, Outlook, etc, anything else that will popup and especially the ones making notifications sounds.
• Mute phone, and put it away, so that it wont make speakers go woop-woop, when there’s an incoming call. Turn of your speakers if you can.
• Prepare story. Make sure every step is planned. Make sure every stop works.
• Drink a bit of water. Yeah, coffee is King, but water clears the mouth better.

That’s it. The last one is of cause a bit more involved, but that’s a topic for another post.

As my more vocal  Atheist friends haven’t neglected to make absolutely clear to me, the Atheist Alliance International 2010 Copenhagen Convention is this week-end. I’m a big fan of James Randi and would really  like to see him. But I’m not going, because I’m not an atheist. And I’m frankly beginning to be a bit tired with them – paying a small fortune for a week-end with a couple of hundred of them, isn’t my idea of fun.

But lets first take a look at what Atheist means (Wikipedia):

Atheism, in a broad sense, is the rejection of belief in the existence of deities. In a narrower sense, atheism is specifically the position that there are no deities. Most inclusively, atheism is simply the absence of belief that any deities exist. Atheism is contrasted with theism which in its most general form is the belief that at least one deity exists.

So Atheism, is the negated form of “the belief that at least one deity exists”. I don’t think I want to define my self with a negative, if I can avoid it. The only place for such a definition is when, there’s a conflict with the positive form. But as I don’t have a problem with theists, I don’t need to define my self against them.

I’m not a non-believer, because I’m not defining myself against believers. I’m not defining myself along them either. Other peoples believe in or against this or that, is irrelevant for my definition of me.

It’s not that I don’t have negative definitions. It’s just as easy to define what you don’t like, as to define what you like. I’m fairly anti-stupidity. I’m anti-fanaticism. I don’t care for people, who try to push their believes on me. But that goes for anybody who’s trying to “sell” something…

I don’t reject the believe in the existences of deities. Rejecting something is a energy consuming activity. And as I firmly believe that other peoples believes are their personal business, I don’t waste my time on having an opinion on it.

And there are so many other things, I want to spend my time on.

And just to be absolutely clear: I do reject the evils done in the name of deities and their prophets. Just like I reject the evils done in the name of nationalism, racism, expansionism, stupidity and fanboyism. I like good things done in the name of deities and their prophets. Just like I like good things done in the name of altruism, love, loyalty, dedication and if-that-ever-happens pure stupidity.

I reject evil, no matter what the excuse is.

I accept good, no matter what the reason is.

The Question

But what about all the evil or just stupid things done in the name of deities and their prophets?

I think I already answered that above, but allow me to clarify:

There’s two levels to that.

1. On one level it’s about power structures and how to enforce them. Waving the “God told me to rule you all” flag, is just an easy way to gain control. Just like democracy, socialism or the fear of terrorism. I do agree that “God ordained” power, seems to extraordinarily easy to build and sustain, but it’s competitors, Capitalism, Western Democracy and Chinese Commercial Communism (just to name some of the biggest), even if they are in their infancies, aren’t doing to bad either. Power structures can be good or bad, or both or anything in between, but the older and bigger it is, the more it tends towards being mainly about sustaining it self.  I do have a problem with this, but the excuse for the power structure is irrelevant.

2. On the personal level, it’s about finding something that helps you make sense of the world. If you find something that helps you do good and see the world in a positive light; Good for you. If you find something that, helps you do evil and be bad; Not so good. On a personal level, I’ve seen more bad done in the name of Socialism, than religions faith.

The other question

People like Sam Harries and Richard Dawkins argues that faith it self is bad (or outright evil), as it leads to and allow irrational thinking. The question seems to be; if you can base your life philosophy on the belief in an unprovable deity, what from stopping you from extending this to all decisions, even the ones that need a more scientific approach?

I think the question is misleading and that they have it up-side-down. I don’t think anybody is capable of rational thinking all the time. Everybody makes faith based decisions. More or less all the time, on all kinds of levels. Every moral or ethic decision you’ve ever made, has been faith based. Using a deity to rationalize those decisions, is just as valid as not. It doesn’t really matter.

What matters is that nobody really does that, where it matters and where there’s a rational alternative. Nobody decides the strength of a break wire in a car, based on the teaching of the bible or “God told me to” – not without having some major brain malfunction that would have manifested it self badly anyway, with or without faith in a deity. Not even the most devoted believer will accept a car manufacture using  “God told me to use the weak (and cheap) wire” as an excuse, after they have crashed their car in to a wall. If, on the other hand, your life philosophy help you cope with the meaninglessness of an accident or loss, that’s all good. If it locks you in a pattern of grief and sorrow that’s bad. With or without a deity.

The other side of that argument is that having faith in a deity (and a religious system), will stop you from seeking new knowledge and “rationalize” yourself. Again, I don’t think that belief in a deity is needed for that. I’ve seen plenty of non-believers who prefer ignorance in most matters. It’s just a basic human condition – you seek the knowledge that confirms your beliefs and ignore things that work against it. Doesn’t matter if the belief has a deity in it or not.

The really bad decisions are made based on the needs of power structures, pure stupidity and greed (or combinations). I would rather fight that, then broadly attack everybody who believes in a deity.

Infrequently updated, but with my musing in English.

My danish blog and my google+ stream are updated more often.

With this post I try to change that. Slowly. Just to see how it goes.

I’ll start by telling you a story about failure, and how to learn from it. Not because I’m a negative person, but because failure, should be see as an excuse to stop and ponder. There’s often something important to learn.

We, and by we I mean me and the development team of Metaconomy, of which I’m the product manager and daily contact person, failed last week. The goal for the week, was to refactor the partnership functionality and UX, in our Channel Performance Manager solution.

The week started on Tuesday, as Monday was a public holiday in Ukraine, with me presenting some wire-frames, made in the excellent tool Balsamiq, with my idea to the new GUI and some of the changed interactions. After some discussions about the needed architectural changes, the Devs spend sometime time without me (we are working over Skype, I’m in Denmark, they are in Ukraine), breaking down the tasks and estimating them, before we got back together again.

The plan looked good – the estimates where, a bit beyond, what’s realistically possible within a four day iteration. But it looked doable, if we would allow some of the tweaking to bleed into next week. And we like to be aggressive with our weekly iterations.

The Wednesday status meeting went well. In hindsight, there might have been a few more questions and a bit more uncertainty that normal, that I could have picked up on, but I didn’t. We didn’t have a status voice/video status meeting on Thursday, as that was a public holiday in Denmark.

At the Friday status meeting, it was clear that we where not going to make the cut (we normally present the weekly changes to the Business team each Friday afternoon). Changes had been made, but weren’t in a state where they could be demoed and there was a lot of uncertainty about how to finish the task.

The team had learned things about the task, during the week, that made it possible for them to ask questions about how the system should work, I just couldn’t answer.

Pull the Plug

It was time to pull the plug on the task. So we decided to stop the task and get back to it Monday. Go do something else – maybe even take some time away from the keyboard.

It was kind of perfect, that this happened on a Friday, but I think (and hope) my reaction would have been the same in the middle of the week. Sometimes you need some distance. Allow your brain to focus on something else and just leave all that new knowledge, to do it’s own thing while you aren’t watching.

I must admit that I was a bit nervous, about the Monday iteration start-up meeting. But we all had some good ideas. I had some ideas on how the business logic could be changed to make more sense (inspired by the twitter form of follow based relationships) and the Dev guys had some idea for architectural changes, that would be easier to implement and allow us to be more flexible in our business logic, if I had gotten it wrong (again), without having to throw everything out (again).

Lessons learned

This may not sound like a major catastrophe, and it isn’t, but I still think it’s a good opportunity to learn something.

1. Just do it

We have been pushing this refractory job in front of us for a while. We knew we had to simplify the partnership design, but we didn’t seem to find just the perfect way of doing this. I did wire-frames and discussed it with Business. We thought we kind of had it. But we kept pushing it, because we might get an insight or new knowledge that would help us do right.

But deadlines are deadlines, and sometimes you have to just do it, even if you don’t know it all. This is want happened last week. We tried to implement something, with an incomplete idea of what it was. That didn’t work. We failed our iteration objective, which was a Friday demonstration of  “the new partnership functionality”.

But something else happened – we gained a lot of insight into the partnership domain. All that time spend with Business at the whiteboard or over wire-frames, was well spend, but trying to actually develop that – and failing, was the mechanism that allowed us to collect the missing pieces in our knowledge.

Lesson learned: Sometimes you just have to do it, brace your self for failure, but be ready to learn.

2. Identify the odd iteration

We knew our knowledge was a bit weaker then it usually is, when we started last weeks iteration, but we set out with the same goal, as all the previous, successful one-week iterations. Run for a week then demonstrate whatever we had. It may not be a full feature set, but it’s in a good enough state, that it can be demonstrated to Business.

I think we forgot to question the process. Okay, I forgot – that’s my job.

The one week iteration, with a demo at the end, have served us really well. We’ve been running a good long successful streak of them.

But with the level of uncertainty in this task, it might have been a mistake to leave a demo as the goal. A simple change of goal to “Validate the proposed partnership functionality/UX – if possible by implementing it”, would have left us more open to a running review of the assumptions in the proposal.

It would have left the developers with more freedom to scrap the iteration, faster and without consulting with me (who had the audacity to take a day off), instead of luring them into a useless work-harder-to-get-this-to-work-before-Friday-state.

Lesson learned: Identify iterations with a higher uncertainty that normal and treat them differently.

There’s also some lessons learned about communication, and the limits of what you can do, when you don’t have any real ways of validating your designs, but that’s for another post…