I just saved A$4 500!

Over the last few weeks I have been suffering from a serious case of Mac lust. However a quick enquiry on the local Perl Mongers list elicited a few pithy words, from less giddy heads than mine, showing that I should give myself a good slap and be happy with my Ubuntu system (which is superior in many ways).

Thanks Guys and Gals!

Here’s a good idea for a Web 2.0 business

Blog by Kveton » Love those credit card companies

You know what would be cool? A credit card company that wasn’t evil. One that didn’t flaunt the information about you that it knows. One that doesn’t try to upsell you or confuse you. Better still, I’d like to work with a group of my friends (that all get good credit) to get even better interest rates. It’ll happen …

… for instance using the connections in social networks like facebook or LinkeIn

Could this be a plan to get a group together and start a social network based credit union?

Powered by ScribeFire.

Because all the cool kids have one

Facebook | Alec Clews

I now have a facebook account, as well as MySpace and LinkedIn. Come over and say “G’Day“.

However I gave up on Twitter, I’m not that cool.

Updated Dec 2008 — I’m cool again and have a twitter account @alecthegeek

Powered by ScribeFire.

I introduced a Y2K bug!

An Agile trap for the unwary « Alec the Geek

Some of us may remember the Y2K bug

Some of us actually introduced our own Y2K bug .

In about 1984 I was working in Jordan on an ATM system implementation. The customer has some very specific requirements with regard to keeping transaction records on the card magnetic strip. As you you can imagine there is very constrained space on the back of a bank card for information storage, so we stored the date of the last transaction as DDDYY (BCD storage for those that can remember back that far). I did point our that come the end of the century then I code would fall in a nasty heap, but was laughed at for being so niave as to think it would last that long.

I often wondered what happened…

Powered by ScribeFire.

An Agile trap for the unwary

Code Craft » Avoid code donuts

Agile processes are highly vulnerable to code donuts

Kevin articulates the unease which many people, including me sometimes, feel about agile development and the possible impact of apparently very short term design decisions. This is especially worrisome as systems become older and larger. The impact of early decisions, made with insufficient data or thought, can have very far reaching affects that were impossible to predict when doing the test driven development (for example).

How do we overcome this?

1. Follow the Agile practices. Refactor and plan that rework will be required. It’s already been paid for by earlier delivery of business value.
2. More importantly, don’t be dogmatic and make sure you do some Big Design Up Front — but just enough (and that’s a fine line to recognise)

Nothing beats experience of course — shame it’s so expensive to get it.

Powered by ScribeFire.

Performance tuning Subversion and ‘bulk CIs’

Information from IBM on SVN performance when managing binary files and directories of files

Performance tuning Subversion

Performance tuning Subversion

The basic conclusion to be drawn from the article is that

• Don’t store deltas of binary files. It takes too long
• Compress binaries before storing them

Another technique discussed in the article the archiving of a complete directory structures into a single file. This single file is then placed in Subversion as a configuration item (CI — the technical term for a file or anything else placed under version control).

This technique is very useful (ignoring issues relating to performance) in certain limited version control scenarios. For example:

Scenario1:

When a tool generates a substantial number of files (e.g. a code generator) it often does not make sense to track changes to individual files because they all be regenerated the next time the tool is used.

Scenario2:

A package is released as a set of files. After the release build the complete set of file is managed as a single CI. Any change to a small part of the system creates a complete new release.

Powered by ScribeFire.

Design Patterns Workshop

Yesterday I went to the Cogent Design Patterns workshop. A good time to was had and many interesting discussions around various aspects of patterns and OO programming occured.

Considering I am now a PHB I managed to keep my end up very well I thought . Many thanks to Andy Bulka and the other delegates for a great time.

Dimensions of Change

In the past when I’ve looked at Change Management issues I’ve tried to concentrate on lower level more practical topics. However recently I have the opportunity to think about change processes at the a higher level and of course that let me to want talk about it.

When looking at a change process it is tempting to see it as a single process, one size fits all, i.e all changes can be treated identically. However life is never that simple because changes have multiple facets. As well as identifying which change process needs to be followed, change dimensions provide information to assist us in prioritising work.

The most obvious difference, and the one that most people first come across, is the budget difference. Depending on who is paying for an change (IT or customers) has a direct bearing on the approval process. If the customer is paying (either directly or indirectly) then they, or their delegate such as the marketing department, must be involved in the financial approval to spend money. If it’s ‘free’ then the customer involvement may be limited to status updates.

A second dimension is size. The larger the size of the change the greater the process complexity and check points. How do we measure size? A variety of metrics need to be used, typically financial cost to implement, architectural impact on the software system, impact on other systems, how many project owners/stakeholders exist (this increases the issues involved in communication and resolving conflicting needs). This concept is reflected in the ITIL change process which recognises three levels of change impact and has different process flows accordingly.

A variation on the ‘financial cost to implement’ value is that different software systems may have different costs to deliver a similar level of business value. So a legacy application that contains a lot of cruft might cost $x to deliver y benefit, however in a different part of the business a different system might take a lot less than x dollars to deliver the same amount of value. So when comparing changes in a priority list, looking at a pure financial cost may not be enough.

The third Dimensions of change can be considered as political, i.e. who is sponsoring or controlling our changes? Often the executive team are able to generate a significant amount of strategic work which could absorb the all potential development and related resources. However an organisation also needs to exist on a daily tactical level and there are significant improvements to be made by implementing as many improvements to the current business as possible. However these changes often appear less significant to executive sponsors because of their more tactical nature despite their possibly huge business value.

When the various facets of a change are taken into account we can then make some decisions about the change e.g. Who will make the change, what level of process maturity will the change need to follow, which budget will pay for the change, who will be involved in acceptance testing, when will the change be released and so on.

Next time I will discuss some practical consequences of this and how to avoid some of the resulting pitfalls

Handy Hack:How to install Perl modules on Linux

An excellent series of posts on the Melbourne Perl Mongers mailing list on the correct way to install Perl modules on your RPM or Deb based distro.

Now I know what I was doing wrong and how to fix it. Thanks Mongers

Update: I thought the information was so good I slapped it into Perl Net.

How to avoid task dependency hell

A rather obvious point really, but often teams and organisations stagnate in a cesspit of inactivity because everything depends on something else, which of course also depends on something else. Soon it feels as if nothing can be done and everything is delayed waiting for someone else to do something.

There are two answers. The quick fix and the long term management of work.

Quick fix
The answer is to “Just do it”. Break the work in hand down into smaller pieces and find something that does not have a dependency, then do it! Repeat as required.
If you can’t find anything without a dependency then work around and do the best you can without needing the dependency

Long Term Answer

1. ‘Design’ work as a set of loosely coupled activities with small, well considered, dependencies. Of course the activities need to be coherent and internally cohesive.
2. Make sure you document and track your tasks and the tasks you assign to others.
3. When the dependencies get too complicated then package the work up into large bundles that can stand alone; re-examine the package as a whole and start attacking the work by ‘nibbling’ at the edges. Apply the ‘Quick Fix’ if needed.

At this point any analogy to software design breaks down. In software we are better off having simpler tasks (objects) and more dependencies (interactions). However for activity management we often (but not always) need to lean the other way. Providing our tasks are basically coherent then we can  make each chunk of work bigger if it  helps reduce the dependencies between activities.

This approach scales to teams and larger groups. The more we can package work into independent projects and just get on with them the better. If our work is not perfect because of a missing dependency we are still better off anyway because at least we have started to break the logjam.

Powered by ScribeFire.

Handy Hack: Configure correct version of Java in Ubuntu

When you install anything related to Java in Ubuntu (e.g. Eclipse) then it insists on installing the GNU Java compatibility layer (Java 1.4). If you remove it to try and force your shiny new Sun Java 1.6 (for instance) then things break in apt .

So let apt fix it by re-installing gcj and then run the command sudo update-alternatives --config java and select the correct version of Java you want use.

YMMV

I think update-alternatives bears closer scrutiny.

Powered by ScribeFire.