Radyology

The New Manifesto

The Manifesto for Software Craftsmanship

Only good things will come of this. Glad to sign it.

Kata:Python:Reverse all the words in a string

s = "Theses are the words I want to reverse"

" ".join([x[::-1] for x in s.split()])

Lets take a look at this rather terse solution from the inside out.

Agile 2009 Proposal: Continuous Testing Evolved

I just finished submitting the first draft of my Agile 2009 presentation proposal: Continuous Testing Evolved. A lot has changed since I presented on the same topic last year, and I felt there was a lot of value in exploring some of those changes. It's also still a very new practice, and there's a lot of people who are unfamiliar with it and would benefit from this talk.

The talk would also be a great opportunity to demonstrate the new Eclipse plugin for Infinitest that Ryan and I are working on. I'm expecting a great many improvments to become possible because of this plugin, not the least of which is a significantly easier (and more familiar) installation process. 

Anyway, go give the proposal a read. Feedback is much appreciated. 

Soviet vs American Coupling

If you've worked on projects of any reasonable size, you know that managing dependencies is an very important part of software maintenance. However, the terms used to describe coupling between packages, efferent and afferent coupling, sound so much alike that I can never remember which one is which. So, I don't use those names...I have my own naming convention.

Yakov Smirnoff was well known in the 1980's for jokes using the following template:

In America, you [verb] [noun]
In Soviet Russia, [noun] [verb] you!

Hilarious.

I use this now popularized meme to differentiate between the two basic types of coupling, like so:

In America, you depend on other classes
In Soviet Russia, other classes depend on you!

So American Coupling equates to efferent coupling, while Soviet Coupling is the same as afferent coupling. When using these cold-war era terms to analyze a particular class or package, I never get confused about which sort of coupling is which. I just think of Yakov and all becomes clear.

Build Failure Hardware Geekout

So, I built an alarm to notify our team of build failures.

Here's a shot of the internals:

Overhead view

It has an audible alarm and strobe light, is controlled via USB and runs off 12v power. The control software uses the RSS feed from our build server to watch for failures, and sets off the alarm accordingly.

This was a really fun project, and I'm still hunting around for cool electronics to hook up to it (I still have 2 open relays!)

Better Than @Ignore

If you're using the @Ignore annotation to disable failing JUnit 4 tests, you might consider using a different technique. By adding the expects=AssertionError.class parameter to the @Test annotation, you can actually assert that the test fails as expected, instead of just ignoring it.

Why would you want to do this? First of all, a failing test will not necessarily continue to fail in the same way if it's disabled. If you've written a test to reproduce a bug, but in the course of fixing it you find yourself blocked, you'll have to disable the test (or delete it) in order to check in. But the test you wrote is useful...it reproduces a known bug! By asserting that the code is broken, rather than simply not checking, you ensure that your test remains valid while other changes are happening in the system. 

You also help prevent someone else from adding a new (duplicated) test if they try and fix the bug. If they do, your test will start to fail because the bug is fixed, and the other programmer will be immediately aware of the duplication.

Give it a try!

My 2009 Language: Javascript

I try to learn a new programming language every year. Not necessarily to an expert level, but well enough to solve non-trivial problems with it. Last year's language was Groovy. The year before was Python. This year's language is (drum-roll please)...

The Dangers of Perfection

Is very difficult to improve upon perfection.

If you have the ideas in your head that your (product, tool, process, organization, whatever) is perfect, or even close to perfect, you're not going to have the right mindset to improve it.

Even if it was perfect at some point (highly unlikely), it's probably not now. A commitment to continuous improvement is the hallmark of a true craftsman. You have to accept the fact that everything you do is a hack; A workaround until you can find another way that's less hacky. That's not to imply that you shouldn't make it as good as you can get it...you should. You just need to realize that it can always be made better.

A Craftsman's Toolbox

The Agile manifesto declares that it's adherents favor Individuals and Interactions over process and tools. But all software development teams use tools, so what kind of tools match this mindset? Here's two characteristics that I see:

Agile tools are easy to replace. They provide value without increasing the cost of change. If you get locked in to a tool, you'll have to find a replacement thats MUCH better before it's worth the effort to change. 5 years could go by while you're waiting for that to happen. The more adapted you are, the less adaptable you become.

Agile tools are flexible yet simple. The best require little configuration or customization, yet can be used in hundreds of different ways (take your favorite text editor, for example).

It's a common fallacy that Agile developers don't value tools. We do. We just realize that the tools won't do our job for us, and that it's up to us to make the project succeed.

Read This!

You should start reading this group. Right now. Here's the feed.

It's about professional ethics and personal responsibility in the software development world. In a larger sense, it's about answering the question: Who ensures that software is useful today, and it continues to be useful in the future? That is; Who ensures that it consistently delivers value?  

I think the answer to this question, or something very similar, will define the next generation of software development efforts. As inconvenient as it may be, software developers are not cogs. The dedication and ability of the individuals involved, not the processes or practices they follow, is the primary determinant of success. The realization of this fact will bring about radical change in the industry.

For managers, this will mean a radical shift in how you organize and lead. For developers, this means that you will now have a professional responsibility to ensure that what you're building is actually useful to the person paying for it. I have no doubt that many organizations will fail to make this fundemental change and suffer the consequences.