Usability vs. Reusability

This blog post I’ve found from 2009 has a nice way of looking at the problem of comparing the ease of use with the ability to reuse. It claims that usability and reusability is always a tradeoff between building

  • a heavyweight, coarse-grained software component with few dependencies (very usable)
  • a lightweight, fine-grained software component with complex dependencies (very reusable)

The following picture nicely depicts this relationship:

Image taken from: http://techdistrict.kirkk.com/2009/07/08/reuse-is-the-dream-dead

Indeed, coarse-grained components are hard to reuse because they try to solve too many problems in the context of the coarse overall point of view. But I’m not sure if they’re necessarily easier to “use”. Being coarse, and thus complex, they may have solved the problem in the wrong way. And since they’re so complex, they cannot be changed easily to fit a slightly different problem domain. Since time can change the original problem setup (and it will in any project), heavyweight, coarse-grained components often cannot even be used nor reused for their “original” purpose. I.e. a coarse solution that is developed in a project over several years cannot be finished, because it cannot be changed after those four years.

And fine-grained components aren’t necessarily hard to use. It is possible to create components with very little dependencies, such that they do not introduce a lot of complexity. jOOQ is one example of such a component, which has no dependencies itself, apart from the JDK. But jOOQ is a library and not a business module, i.e. it implements horizontal reusability, not vertical reusability.

So, let’s hope the original post was not entirely correct and there is a good, middle way! See for yourself:
http://techdistrict.kirkk.com/2009/07/08/reuse-is-the-dream-dead

Strategy: Stop Using Linked-Lists

While using java.util.LinkedHashMap every now and then, when I feel that the insertion order is relevant to subsequent entrySet iterations, I do not recall having used a LinkedList any time, recently. Of course, I understand its purpose and since Java 6, I apreciate the notion of a Deque type. But the LinkedList implementation of the List type hasn’t occurred to be useful to me very often.

Now, here’s an interesting summary about why linked lists can be very bad for your performance:
http://highscalability.com/blog/2013/5/22/strategy-stop-using-linked-lists.html

This summary is referring another, original article:
http://www.futurechips.org/thoughts-for-researchers/quick-post-linked-lists.html#more-818

While the “academic” advantage of a linked list is obvious to everyone (big-O advantage of insertion, removal operations), “real life” disadvantages related to hardware, memory, heap, quickly turn against you when using linked lists. What holds true in the C universe is probably not so wrong in the Java universe as well…

The true spirit of Open Source

As an open source developer, I’m often asking myself why the hell am I going through all of this pain in my free time to deliver quality software, when I’m already doing this in my office?? Sure, it’s fun, you can try out new things, deepen your knowledge in a specific field, it helps boost your career, etc. etc.

But every now and then, I’m reminded of another reason:

I believe in open source

This is just like other people saying

I believe in charity work
I believe in militia politics
I believe in volunteer firefighter engagement
I believe in helping that poor grandma across the street

They do, whereas I…

I believe in open source

All these things make the world go round, without most people noticing, as there is no big fame in it. Of course, there’s always that other point of view on open source. You can make as much money with organised open source, as with organised charity work, or organised militia politics (a.k.a. lobbying), and that’s perfectly fine – why shouldn’t you? But the driving force is always the same, regardless of the pay: It’s belief. Here’s another open source project I’ve recently re-discovered, that has a very nice reason of being, along the same lines. It’s EMMA. Citing the EMMA website:

Until recently, the world of Java development had been plagued by an absurd discrepancy: Java developers had excellent free IDEs, free compilers, free test frameworks but had to rely on code coverage tools that charged an arm and a leg in license fees. As a Java pro, I would like to use the same free coverage tool regardless of whether it is a massive commercial project at work or a small fun project at home. I’ve created EMMA to be that tool.

Beautiful!

Must-have Eclipse plugin: AnyEdit Tools

On fresh Eclipse installations, I usually feel a bit naked, until I realise that this lovely little plugin is not part of Eclipse itself. It’s called AnyEdit tools, and it features the following nice things:

  • Convert Tabs <-> Spaces
  • Convert: Chars <-> Html entities
  • Convert: Camel <-> Underscores
  • Convert: Capitalize
  • Convert: Invert Case
  • Convert: To Upper Case
  • Convert: To Lower Case
  • Convert: From/To Base64
  • Compare/Replace with Clipboard
  • Compare/Replace with Workspace File…
  • Compare/Replace with External File…
  • Compare/Replace with Opened Editor…

Most of these features are available through shortcuts, too. Download it, too and you’ll never want to miss it again!

AnyEdit Tools screenshot
AnyEdit Tools screenshot

A very refreshing point of view about language design

Have fun:

http://joshondesign.com/2012/03/09/open-letter-language-designers

A Brief, Incomplete, and Mostly Wrong History of Programming Languages

Found a fun read on the net, recently ;-)

http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html