Agile Software People Inspiring

XDepend - Like NDepend, But For Java

 

Master of understatement, Patrick Smacchia, has quietly introduced a Java variant of his insanely revealing .NET code analysis tool NDepend, which - because the name JDepend was already taken - is called XDepend.

It supports the same dependency analysis, metrics and Code Query Language as NDepend, and people who have built tools that integrate with NDepend outputs files will no doubt find their investments reusable here, too.

Hoorah!

Next stop, I suspect, is a LINQ for code analysis, which will allow some very sophisticated queries indeed, making it possible at last to automatically search for complex code smells and other design quality problems (I have the specs all ready to go) - possibly in NDepend 3.0?

Time Passing

 

It's a sobering thought indeed that there are children alive today who weren't even born in 1999 but who already have the critical faculties needed to know that Star Wars Episode I isn't a patch on any of the originals.

Second SC2009 Sessions Preview

 

I'm delighted to be able to confirm another top notch session for Software Craftsmanship 2009.

Three Paradigms: Taking an extreme position on coding style in a safe environment is a hands-on refactoring workshop that asks Java programmers to refactor the same code from the same starting position in three very different ways, and then discuss the relative merits of the resulting improvements.

It's being run by Keith Braithwaite, who usually gets very good write-ups for his conference sessions, so I'm really looking forward to participating in this one.

If you're registered, you can find details and let people know you plan to attend that session, too, on the conference wiki.

Don't forget that we're open for registration again. And the final deadline for session proposals in January 1st (next Thirsday), so there's still a little bit of time to get yours in before we cruelly and heartlessly slam the gates!

Merry Xmas - In A Rational, Secular Kind Of Sense

 

December 25th has always been a pagan celebration - the Winter Solstice - in the United Kingdom. It got sort of hi-jacked, first by the Christians, and then by Coca-Cola, and these days by Russell T Davies, it would seem.

But it's a fun day and a great excuse to see family and friends you haven't seen for a while. Right now I'm visiting my sister and nephew - who is very much looking forward to his Xmas Who - and I'm staying in a hotel where:

a. I'm the only guest, and
b. They run an honour bar (you serve yourself and they trust you to add it to your own bill)

Bliss.

If you're that way inclined, then I hope you have a very Merry Christmas and a Happy New Year.

Best wishes

Jason

Dependencies & The "Credit Crunch"

 

In support of my parallel between the problems involved in managing complex networks of debt and the likely propogation of defaults, watch the interviewers face as mathematicians Nassim Taleb and Benoit Mandelbrot calmly and rationally explain why we're all ****ed.

The international debt network has gotten way too complex and is divided among too few financial institutions that are too highly interconnected. Similarly, too many dependencies in your code divided among too few packages with too many interpackage dependencies will likely as not lead to the potential for the tiniest change in one part of the code leading to massive disruption in the rest of the software.

Now I know that many developers just don't "get" dependency management, but you simply cannot afford to ignore a problem like this. It will hurt you.

Remember the three rules of dependency management:

1. Less code = less dependencies. Remove as much unnecessary and duplicate code as possible. Remove features that aren't being used, for exampe. And remove all examples of copy-and-paste inheritence.

2. Encapsulate your dependencies. As Robert Martin teaches us; things that change together belong together. Break up your classes into size-optimised, highly cohesive and loosely-coupled packages. And no, size-optimised doesn't mean "as small as possible"...

3. Depend on things that are more dependable. Sounds obvious, doesn't? In OO programming, this generally means we should favour dependencies on classes and packages that are: a) less likely to be disrupted by changes to other parts of the code (more stable), and b) easier for us to substitute without affecting the client (more abstract).

OCL is a dead language. Universities: stop wasting time teaching it.

 

A sure sign that academia and industry are out of step in the software industry is the sordid tale of the Object Constraint Language.

OCL is a declaritive language that complements the core Unified Modeling Language, allowing us to extend our models with precise expressions (e.g., formulas) and constraints (i.e., rules). Using OCL, it's possible to create precise, testable specifications with UML. It's also possible to turn those precise models into executable code, if you're feeling especially adventerous.

It is also only very, very rarely used outside of academic institutions. I can think of two occasions in the last 10 years when I have been called upon to use OCL on a real project by someone else who uses OCL. And the people in question were only one degree of separation from the chap who invented OCL in the first place, so those occasions were probably a statistical aberration - a symptom of the company I keep.

But every month several hundred people download my Java OCL tutorial. And the web stats show very clearly that they are almost all doing so from behind University firewalls.

OCL, to me, is the Latin of specification languages. The only people who speak it are people who teach it, on the whole. Out here in the real world, OCL is a dead language. You may recognise its influence in the development of some Java libraries (again, written by academics who teach OCL), but you'll be very hard-pushed to find a Java programmer working on commercial prjects who has maybe even heard of the language.

It's with some regret, then, that I seem to have become something of an international authority on OCL, since there is absolutely no demand for OCL training and coaching whatsoever here in the UK.

I do get academics approaching me for help with OCL-based projects. But why are they still flogging this particular dead horse? It's certainly not going to do their students any good to learn OCL.

If you don;t believe me, search on the big IT job sites for "OCL" or "object constraint language". Nada. Nil points, as they say. There's no demand for it at all. Not a sausage. Time spent learning OCL today is time wasted. That time could be spent practicing writing better unit tests, or learning to automate acceptance tests with FitNesse, Watir or Cucumber. employers are falling over each other for those kinds of skills.

OCL, though, has gone to meet its maker. Its pushing up the daisies. It is an ex-language.

SC2009 - Registration Re-Opened

 

We're taking more online registrations, but you'll need to be quick as places went like hotcakes last time the form was up.

As before, we'll close the gate when we're full up again, and then you will be emailed with an invitation to confirm your place on the conference wiki.

Job Alert - City, London. Senior Agile .NET Developers Required

 

Isn't it comforting to know that in this brutal climate, some financial companies are still hiring.

A client of mine based in the City (London) is seeking true .NET craftsmen (and craftswomen, let's not forget). They're undergoing a transition to better and smarter ways of delivering software and systems, and this is a great opportunity to play a major part in that process and really flex your OO, TDD and refectoring muscles. Lots of juicy legacy code to practice on, plus new projects springing up faster than they can staff the teams! Contract and (ideally) permanent.

There's strong senior management commitment here and plenty of enthusiastic developers making things happen. Plus a dedicated program of development coaching and the promise of ongoing peer-led learning (regular dojo's, peer certification, apprenticeships, etc).

Interviewing now. Permanent positions only. Email me to find out more.

SC2009 - First Session Confirmed

 

The final programme for Software Craftsmanship 2009 isn't due to be announced until Jan 7th, but we felt so strongly about some sessions that we're able to confirm them now and give you a sneak preview of what to expect on the day.

The first such session is Programming In The Small, an interactive tutorial proposed by Ivan Moore and Mike Hill.

It's based on Ivan's blog series of the same name, and looks to be a very interesting and useful session.

If you've confirmed your place on the conference wiki (or are about to do so), then you'll find details of confirmed sessions there.

If you've not been able to request a place through the conference web site yet, don't panic. As we predicted, not everyone who as requested a place has gone on to confirm it on the wiki. (You MUST add a page about yourself to confirm your place, by the way. If you didn't do that and just added your name to the list of confirmed delegates, then you need mto go back and add that page ASAP or you may lose your place.)

We expect to re-open online registration by the end of the weekend. Keep an eye on this blog for the actual anouncement.

Confirming Your Place At Software Craftsmanship 2009

 

If you submitted a request to register for Software Craftsmanship 2009 then you might want to check your Inbox (or your SPAM-box) for an invitation to join the conference wiki, which is hosted on WikiDot.

To confirm your place, you will need to add your name to the list of confirmed delegates and add a page introducing yourself and telling us what "software craftsmanship" means to you.

If you didn't manage to register before we closed the gates, don't panic. We expect some people will drop out and fail to confirm their places, so we may be open again for registration in a week or so. Watch this space (and/or this RSS feed)!