Radyology

Kata:Ruby:Prime Factors

2009-11-13T22:48:31-06:00

It took me a fair bit of refactoring after I got the last test passing (generate 10 ) to get it this tight, but I like it.


def generate(n)
  return [] if n == 1
  factor = (2..n).find {|x| n % x == 0} 
  [factor] + generate(n / factor) 
end

svn replacement for git stash

2009-09-30T20:51:40-05:00

I had no idea how dependent I'd become on git's stash function until I needed it while working on a project that uses subversion. I needed to make a quick change to a class to support a change to a schema change to a live server (don't ask), but I was already in the middle of working on another task.

Thankfully, you can approximate git stash by creating a patch file:

% svn diff > WorkInProgress.txt
% svn revert -R .

% svn commit -m "Patched to support server schema change"
% patch -p0 -i WorkInProgress.txt
% rm WorkInProgress.txt

New post on Continuous Flow

2009-08-20T12:09:48-05:00

You're Already Doing Continuous Flow (poorly)

This was a fun one to write. One of those blogs that just flows out of you in one pass.

Survey results posted on feedbackjunkies.com

2009-08-18T00:07:55-05:00

I've started a new blog called Feedback Junkies as a home for all my rants on software development. I'm looking forward to talking a lot about Improving Works and the good stuff we're doing with it.

As an inaugural post, I've published the results from last week's survey on TDD and automated testing. They were quite surprising, and I hope to do it again soon.

Agile 2009 Sessions

2009-08-11T09:06:00-05:00

If you're headed to Agile 2009 this year, and you're at all interested in TDD, be sure to swing by my two talks: Test Driven Development in Java: Live and Uncensored and Continuous Testing Evolved.

The TDD session will be a lot of fun. I've found that solving real-world problems in front of an audience can lead to some unexpected outcomes which are usually entertaining and informative for everyone. Plus, it keeps me on my toes!

I'm hoping the Continuous Testing session will spark some discussion about the future of TDD, Continuous Integration and automated testing in general. I really think CT is the future of automated testing, and Rod and I are going to be bringing some great new research and insight to the conference for this session.

Survey on automated testing and TDD

2009-08-05T21:43:23-05:00

Take the survey!

I'll be posting the results on this survey next week. Thanks in advance for participating!

Dual Licensing for Infinitest

2009-07-29T00:00:00-05:00

In the latest release of Infinitest, we've moved to a dual license model. While the terms of the commercial license are nothing special, the terms of the free license are rather innovative: It's free for individuals. Companies that want their employees to use the tool can buy a commercial license from our newly formed company, Improving Works. While I think this license is actually quite straightforward, its novelty demands an explanation. What does "free for individuals" mean anyway? (Hint: it's not the same as "personal use")

First, let's talk about why we moved to a dual license in the first place.

I think some companies believe that by "open sourcing" their products, they can enlist an army of unpaid developers to help them meet their business goals. I'm sorry, but it doesn't work that way. On every open source project that I've ever contributed to, the core committers wound up doing 95% of the work, Infinitest included. Patches from the user community, while helpful and appreciated, tended to focus on bugs and compatibility issues, and were never significant enough to actually move the project forward. What Infinitest needs right now, more than anything, is to move forward. I think Continuous Testing is going to become an essential practice in the next few years, similar to what Continuous Integration or automated developer testing are today. In order to get there, however, the practice needs a mature Java tool.

We believe, like many other companies that use a dual license model, the most direct path to that maturity is via commercialization. While we gladly contribute our free time to Infinitest, most of the Infinitest committers are professional consultants. That means we have the flexibility to turn every dollar of revenue that we earn into development time for the product. It also means Infinitest need not be a full time gig for us. If it can pay for 500 additional hours of development a year, that's great. 5000 hours? Even better. With this approach, there's no magic number we need to reach to be sustainable, because we're sustainable from day one. And with the depth of Improving Enterprises' bench at our disposal, we can offer high quality support to our customers without worrying about where it's going to come from.

The conundrum, however, is that Infinitest also needs to be a freely available tool. If developers are not free to use the tool on their own projects, without restriction, it's unlikely that they'll be able to learn the practice of continuous testing well enough to apply it when working for a client or employer. The reality of the software industry is that very few companies will pay you to learn things that aren't (in their view) directly related to your day-to-day work. If you want to learn a new tool or technique, you often have to do it on your own time. We don't think you should have to pay to improve yourself.

So why not use the GPL, as is typical with dual licensed products? We considered a more traditional dual licensing model using the GPL, and if Infinitest were a library, that would be the clear choice. The problem is, you don't need to create a derivative work from Infinitest in order to use it. So the GPL doesn't create the kind of incentives necessary to make a dual license model feasible for a tool like Infinitest. The usage requirement we need in order to create those incentives also means that any open source license we adapted to our needs would surely not be accepted by the OSI, the FSF or any other group. Plus, open source license proliferation is generally not a good thing, so why make it worse?

After much research and debate, we wound up in the middle ground. The licenses we created balance all these concerns with a single restriction: You must be working for yourself. That is, free licenses are granted only to individuals, not corporations or other entities. Those individuals cannot use Infinitest to do work on behalf of another party (what's known in copyright law as a work made for hire). However, if you want to license, sell, or even assign the copyright of your work after creating it with Infinitest, that's fine. We want to encourage individual entrepreneurs and innovators to use Infinitest in any way that benefits them, because they contribute the most back to the user community. I think that's simple, fair, and offers a good balance between all the competing interests.

And if that's all too much to absorb, the layman's version goes like this: If you want to use Infinitest at your day job, your employer has to pay for it. Otherwise, it's free for you to use however you like.

For more information about Infinitest, please visit Infinitest.org or ImprovingWorks.com.

Working Effectively with Transitional Code (Part 1)

2009-05-13T22:44:37-05:00

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

2009-04-23T23:24:04-05:00

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:

There is an IntelliJ version of Infinitest

Kent has blogged about possibly doing an IntelliJ version at some point. We've got a working version today, maintained primarily by my friend and colleague Rod Coffin. I think it's a more mature tool than the Eclipse version in some respects, but they're both based on the same core.

Infinitest selects a subset of tests to run, while JUnitMax runs them all

I think there are two basic functions that make a continuous test runner worthwhile. The first is test prioritization. The order that you run your tests in is very important. You can think of this as "the fastest possible red bar". If a test is likely to fail, I want it to be the very first test I run. Both Infinitest and JUnitMax track test metrics and use them to prioritize the tests.

The other function that I think a CT runner needs to do is test selection. If you're doing TDD, you're probably running a single test every time you make a change. If you're doing CI, you're running all your tests on a semi regular basis. Somewhere in the middle of these two approaches is a good balance of feedback quality vs speed. I think that's where CT tools should be focused. Infinitest uses dependency analysis to determine what tests need to be run for a given change. JUnitMax runs them all. My philosophy is that time spent running tests that are highly unlikely to fail is wasted. I want "the fastest green bar possible" so that I can have confidence in my last change and move on to the next one. And while the multicore revolution may one day provide so much desktop CPU horsepower that we can run all the tests in a typical project, concurrently, in a second or two, we're not there yet.

You don't have to buy Infinitest to use it

All of the committers to the Infinitest project share a common vision. Not only of Infinitest as a useful tool, but also of Continuous Testing as a valuable and transformative developer practice. We've been writing code this way for a couple of years at this point, and we find the difference between Continuous Testing and plain Test Driven Development to be quite substantial. It reminds me of when I first got addicted to doing TDD...there's just no way I could go back.

I'm a software craftsman. That means that I'm committed to not only building quality software, but also contributing back to the profession by helping others learn. With Infinitest, I get to do both.

I think these differences make Infinitest a better tool. I also think there's plenty of room in the CT tools market for multiple vendors serving different market segments. We'll see how everything settles out in the next year or so...it promises to be a very interesting ride.

Infinitest for IntelliJ 5.0 Released

2009-04-03T09:12:27-05:00

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.