Radyology

Working Effectively with Transitional Code (Part 1)

Thanks to M. Feathers for the title inspiration.

Many companies today are struggling. As the economy contracts, they have started to look for new ways to become more efficient. Some have recognized the benefits of Agile methodologies, and have started to make the transition. These transitions can be lengthy, and if done improperly, painful and costly. A problem that I've started to see more and more among companies adopting an agile mindset is the stalled transition.

A stalled transition occurs when an organization:

• Partially adopts agile practices and/or principles. Some teams and individuals fail to make the transition and revert to old habits.
• Adopts practices that have been modified for expediency by mandate, rather than for effectiveness through team retrospectives.
• Fails to adopt sets of practices that are interdependent (Continuous integration without automated testing, for example).
• Mandates agile practices blindly, without understanding their benefits and effects.

For example, an organization may adopt some of the project management practices of various agile methods (Stand up meetings, planning poker, user stories) without adopting the technical practices that make those management practices effective (Test Driven Development, Continuous Integration, Refactoring). 

The result is, quite often, a mess. Projects managed in this fashion typically exhibit a number of common characteristics. Test coverage is spotty. Many tests make trivial assertions like checking for nullity of a returned object. Some tests make no assertions at all, which makes any code coverage metrics highly suspect. Builds often take 30 minutes or longer to complete, not due to any inherent complexity, but simply due to poorly written tests that run slowly. Refactoring is not done mercilessly, if at all, and so the the level of code quality is low and dropping. Quality standards are only intermittently applied. Pairing is rare or non-existent, and implicit code ownership silos start to appear "Give that task to Larry, he knows the UI better than anyone". 

As a result, the team may find it impossible to make frequent deliveries of working code. Customer demos are full of hand-waving and special cases, and the product is most certainly not ready to ship. When it does ship, defect counts and high, and stakeholders are often disappointed with the result.

I call this mess transitional code, and it is a serious and increasingly common problem. Adopting iterative and incremental project management practices without rigorously applying iterative and incremental technical practices is recipe for disaster. 

This is the first in what I hope will be a series of posts on this issue. I believe its resolution is critically important to the Agile movement.

Comparing Infinitest and JUnitMax

As the author of Infinitest, a lot of people have been asking me what the difference is between my tool and JUnitMax. They both run tests continuously. They both are packaged as Eclipse plugins. They both report test errors in the "Problems" view just like compiler errors. In all honesty, their similarities are much more numerous than their differences. So it's hard for me to compare them in a way that's helpful to those that ask.

Compounding this is the fact that we're doing, on average, a couple of releases each week. I don't know if Kent is keeping track of what we're doing, but we're very aware of what he's doing. When it comes to responding to change, I think we do it as well as anyone. So any kind of feature by feature breakdown is likely to be out of date by the time anyone reads it.

There are some differences though, and I think they are significant. Here are three that I think are unlikely to change in the near term:

Infinitest for IntelliJ 5.0 Released

As Rod already mentioned Infinitest 5.0 for IntelliJ is out. We've added some great new features to it, including gutter annotations that make it crystal clear where and why your test is failing. If you haven't tried it already, now's a great time.

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)...