Saturday, June 21, 2008

Why non-agile project effort estimation sucks

Let's start with a warm up exercise back from school.

We have 4 voltmeters as in the picture below.
What is the total voltage if the voltmeters read:
V1 = 1V, V2 = 1V, V3 = 2V and V4 = 3V ?



You say 7V? Yeah, sure, maybe in your high school physics class, but definitely not in engineering lab.
What I mean is of course margin of error during measurement (please excuse my poor vocabulary).
I haven't given the margin explicitly, so you should have used the industry standard 0.5 of the meter's unit (which obviously is 1V, as otherwise I would say 1.0V. You should have guessed that too, of course)

So the answer is 7V±2 : most probably 7, but maybe 5 or 9.

Lets come back to software engineering.

I have 4 tasks, I estimate the first will take me 1 day, second too, third 2 days and the last one 3 days.
High school student may say the whole project will take me 7 days. Engineering student knows it will be from 5 to 9.
But hey, we are experienced software developers, so we know that developer's estimate has at best 30% error margin. If we are product managers we know we should multiply the developer's estimate by 8.
We are not product managers, so lets assume 30% (rounding up to half days, because we all know what happens when developer finishes the task an hour before lunch)

Real task estimates: T1,2 = 1d±0.5, T3 = 2d±1, T4 = 3d±1
Project estimate (on Monday): 7d±3, which means somewhere between this Thursday and the following weekend (unless I catch a cold, realize that task 4 is much bigger then I thought or Christmas happens)

To make things more interesting, do you remember how to calculate error margin for division?
(Oh yes, I definitely have 4 developers to divide work among, that flue that Bob has caught from Charlie is definitely not long term)

What does it all have to do with agile project management?
Well, if you commit only to 2-week iterations, you can be no more then 2 weeks behind the schedule before the project manager starts noticing.
Compare that to 6 month tasks that are 80% done until the last day, when they begin to be 90% done for next 6 months.

Coming soon: why Auto adjust in JIRA's Log Work action sucks :-)

Friday, June 20, 2008

JScrollPane - Beer Challenge

Ok, I am fed up and I give up. JScrollPane is ridiculous in its behaviour. Therefore, I challenge you to solve the problem I will describe in a second. The winner gets
  • a bottle of beer of his/her choosing
  • inclusion of his/her code in the open source project (Atlassian IDE plugin). With big-ass comment praising the individual as my personal hero
So, the problem to solve is:
  • take JEditorPane, set it up to display random HTML. The string to display may be empty, may be long, may be whatever
  • set the editor to read-only (this is an optional step)
  • wrap the editor in the JScrollPane (or do whatever you wish to make its contents scrollable if necessary)
  • put the above edit panel in the GridBagLayout in a container that has a variable width and height (is resizeable)
  • put some other controls in the same panel, both above and below the edit pane
  • the resulting edit pane should be at most 200 pixels high, regardless of container's dimensions
  • if the text rendered by the edit pane is "naturally" smaller than 200 pixels, the pane should display at its "natural" height (i.e. whatever component is below the edit pane, should appear immediately below it, not 200 pixels below it)
  • the edit pane should not show scrollers if this is not necessary to fit its contents in by 200 pixels area
  • scrollers should be the "right" size (i.e. not aloowing you to scroll 100000 by 100000 pixels, but just enough to see the whole text of the edit pane)
  • the above should work in the DescriptionPanel class in the Atlassian IDE plugin ( you are welcome to take a look at this code, but you have to register your user name in JIRA Studio to get access (free registration)
  • code must not be an ass-ugly hack only known to Swing voodoo masters after 10 years of initiation in a buddhist monastery in Tibet (i.e. computing size of the JEditPane by parsing rendered HTML and calculating average font sizes, then rendering everything in a temporary, invisible container, then pasting this back to a visible form - like some folks in some forums suggest - is bullshit that I refuse to use. There *must* be a better way)

RSSOwl on Ubuntu with new shiny Firefox 3

Recently I became so frustrated with MS Vista (the reasons why probably deserve a separate blog post) which I stupidly had chosen as my OS at work several months ago, that when I had to analyse one problem with FishEye, SVN and symbolic links and use some Unix/Linux platform for that, it ignited my final decision to move to Ubuntu on my office laptop.

While configuring all my favourite development and office tools, I encountered the problem with RSSOwl, which I started to use a few months ago when it turned out that Google Reader leaks my confidential feeds.
The problem was that Just whenever I clicked on any feed, instead of list of news for this feed I was getting nothing, but the following error in the log:
No more handles (java.lang.UnsatisfiedLinkError: no swt-mozilla-gtk-3349 or
swt-mozilla-gtk in swt.library.path, java.library.path or the jar file)
at org.eclipse.swt.SWT.error(SWT.java:3589)
at org.eclipse.swt.SWT.error(SWT.java:3481)
at org.eclipse.swt.browser.Mozilla.create(Mozilla.java:323)
...
RSSOwl is really a great RSS reader tool, so I did not want to give up quickly.
It turned out that Ubuntu 8.04 out of the box + new shiny FireFox 3 + RSSOwl 2 (which bases on Eclipse) do not want to cooperate with some nudging.

The solution was simple in my case and was to install additional XULRunner support for gnome with:
sudo apt-get install xulrunner-gnome-support
and it did the trick. I found the original hint on this blog.
I decided to write this post, as there is very few hits in the web on this subject, for some people RSSOwl does not necessarily equals Eclipse and finally with recent Firefox 3 launch and millions of downloads this problem will probably affect many more people.

P.S. Probably some of you did not know that Vista finally introduced the concept of symbolic links to its file system. Now you can have real symlinks to files and directories, although there are as always some crazy features and limitation of this stuff. You can think why then I had to analyse this problem on Unix/Linux. The answer is simple: SVN compiled for Windows does not support yet symbolic links regardless of the version of OS.

Swinging with JScrollPanes

Let me tell you - Swing sucks - big time. Especially some parts of it - I am looking at you JScrollPane. I have fought with this monstrosity for a bunch of days, trying to coerce it do host a JPanel with some random content in it in a reliable and non-ugly manner, that would show the whole content of a panel and not clip it in weird ways.

Out of all approaches I tried, this brutal one seems to do the right thing for me, with least hassle:

class ScrollablePanel extends JPanel
implements Scrollable {
private static final int A_LOT = 100000;

// cheating obviously but this seems to do the
// right thing, so whatever :). Let's hope some
// time will pass till people routinely have
// monitors 100000 pixels high
public Dimension getPreferredScrollableViewportSize() {
return new Dimension(1, A_LOT);
}

public int getScrollableUnitIncrement(
Rectangle visibleRect,
int orientation,
int direction) {
return 1;
}

public int getScrollableBlockIncrement(
Rectangle visibleRect,
int orientation,
int direction) {
return 1;
}

public boolean getScrollableTracksViewportWidth() {
return true;
}

public boolean getScrollableTracksViewportHeight() {
return false;
}
}

And then

ScrollablePanel panel = new ScrollablePanel();
// now put whatever you want in the panel,
// or even add stuff to it later, after putting it
// in the srcoll
JScrollPane scroll = new JScrollPane();
scroll.setViewportView(panel);

Sunday, June 15, 2008

What is faster - ArrayList or LinkedList

Inspired by JavaSpecialists article by Dr. Heinz M. Kabutz of the same title, I decided to verify one aspect where I expected LinkedList to be faster - creation of short-lived collection of items to process a few instructions later.

Say, as in code below:
List store = new (Array|Linked)List();
for (Object o : someData) {
if (condition(o)) {
store.add(new Adapter(o));
}
}
doStuff(store);

I extended Dr. Kabutz' code with following methods (see the original post for context):
public static void testListCreate(List list) {
long time = System.currentTimeMillis();
for (int i = 0; i < NUM_ELEMENTS; i++) {
list.add(new Object());
}
time = System.currentTimeMillis() - time;
System.out.println("Creating " +
list.getClass().getSimpleName() + " took " + time);
}

public static void testListIterate(List list) {
long time = System.currentTimeMillis();
for (Object o : list) {
if (o == null) {
throw new NullPointerException();
}
}
time = System.currentTimeMillis() - time;
System.out.println("Iterating " +
list.getClass().getSimpleName() + " took " + time);
}


Called from main test method:
testListCreate(new ArrayList());
testListCreate(new LinkedList());
testListCreate(new ArrayList(NUM_ELEMENTS));

testListIterate(ar);
testListIterate(new LinkedList(ar));


The results were quite surprising (Mac OS X 10.5.3, JDK1.5 server mode, Intel Core 2 Duo 2.4GHz):
Creating ArrayList took 31
Creating LinkedList took 50
Creating ArrayList took 9
Iterating ArrayList took 8
Iterating LinkedList took 2
beginning ArrayList took 1839
beginning LinkedList took 3
middle ArrayList took 976
middle LinkedList took 3920
end ArrayList took 446
end LinkedList took 768


For small arrays the results and differences were negligible.

Conclusions (random relevance to the subject):
- I have a faster computer then Mr Kabutz ;-)
- ArrayList creation is faster, even when the initial list size is unspecified.
- Iteration of LinkedList is faster, but not faster enough to pay off the creation overhead.
- ArrayList comes as a first autocomplete suggestion for 'List l = new [Ctrl-Shift-Space]', so it is much easier to pick than any other List implementation.
- There are lies, damns lies, statistics and microbenchmarks.
- blogger.com is sub-optimal for writing posts about java code.

Tuesday, June 3, 2008

koders.com - my new (third) best friend

I am involved in writing 2 plugins for IntelliJ IDEA supporting Atlassian products.

I spend most of the time wondering "How the (bloop) am I supposed to use this openapi class to do what I need properly?"

In general, the IDEA API is poorly documented. There is some JavaDoc, but for most classes there is no human-provided description, not to mention sample usages etc.
Fortunately, most classes and methods are well named, so once you know which class to use, it is usually possible to guess how to use it.

Here comes my first best friend - autocomplete feature of IDEA.
Did you know that IDEA has 3 different key combinations for autocomplete, each working in a different way?
Go To Class and Go To Symbol are quite useful too.

Now, where do I find some sample code?
Plain Old Google might be helpful, but my second best friend is the Open API and Plugin Development forum. Searching the forum sometimes leads you to some insightful code snippets (sometimes even straight answers). You may post a question there and some guys here claim they even got a reply (I haven't been so lucky yet, maybe my questions were too nonstandard).

Here comes my new friend I stumbled upon recently: koders.com

So, let's see how to create a TreeTableView.

JavaDoc
- not extremely helpful, is it?

Let's go to koders.com:
- [Searching...]
- Sweeeet :-)

Trivia (world is small :-) ):
- Have you noticed how this is similar to openapi's TreeTableView?
- koders.com has been bought by Black Duck Software, who sell Protex IP, the "GPL Contamination Detection" solution - rings the bell for anyone? ;-)