Main Page - Books - Links - Resources - About - Contact Me - RSS

Most Popular Help! I've Inherited Legacy Code Testing Untestable Code Continuous Integration... Why Bother? Mock Client Testing The Art of Work Technical Idiot Savants Targetted Skills Aquition vs Free Range Chickens The Habits of Highly Effective Developers

Blog Archive 2005-December 2005-November 2005-October 2005-September 2005-August 2005-July 2005-June

Mon, 26 Dec 2005

Ruby and the Rabid Enthusiasts

Just a thought on the blogosphere storm that came after Bruce Eckel's blog posting entitled The departure of the hyper-enthusiasts.

Hyper-enthusiasts might be another word for "early adopters". The early adopters are the people that jump on bandwagons early. They were all over Java in the early days. The first to PHP, Ruby and OSX, and other technologies. They were the first to own HD television sets. They like to tinker with new things.

Early adopters tend to be very vocal in their support of a new technology. If they tinker with it and like what they find, you'll hear about it. There are early adopters behind most of the up-and-coming languages and tools. That's why the technologies are up-and-coming. :) They haven't arrived but they are moving.

Perhaps some early enthusiasts were a bit too enthusiastic. Doe we throw out the baby with the bad bathwater? I'm thinking no.

Will Ruby replace Java? No. Will they co-exist? Yes. I've heard people say that Java will own the enterprise deployments and Ruby will own the smaller apps. Could be... I don't know but it's a possibility.

This doesn't have to be "us" versus "them". Learn both. Learn PHP, Python, C#, and whatever else you come across. Put the tools in your toolbox and use them when they fit.

Jared

posted at: 12:46 | path: | permanent link to this entry

Wed, 21 Dec 2005

The Copy/Paste Detector

Last week on the Agile Testing mailing list the topic of software metrics came up... several were mentioned and I wanted to follow up on one of them here. There's a nifty tool available to you called CPD. It's simply a Copy/Paste detector but it works on Java, C, C++ and PHP code.

The idea is pretty simple. When someone sees a block of code they want to use, sometimes they create a utility class or a common routine from the code and then use that common code. It's a nice, clean, maintainable solution.

However, most of the time, we just copy over the code and move on.

Why is that a problem? After all, it's quicker to just move forward isn't it? Copying the code into my class makes me productive right now.

The problem comes when the copied code needs maintenance. Perhaps it needs to be faster or tweaked to run with the latest toolkit (JDK 1.5 anyone?). Maybe the original code has a bug.

For whatever reason, you need to update the code. If there is a common routine to use, the code changes go in one place. If the code has been copied a dozen times, someone will waste a lot time trying to find all the code that needs updating. And odds are that some of the code will be missed.

Think about it this way. The last time you fixed a bug, did you search the rest of your codebase to see if the bug existed in other code? I know I usually don't.

Another more subtle reason to use CPD is to keep your code more readable. When your code is littered with aptly-named utility classes, it reads easier and is easier to understand. Instead of reading a for loop to understand what it's doing, you'd see a routine called sort_users_alphabetically or select_unique_values. Any of us would instantly understand what the routine was doing but understanding the for loop might be more of a challenge. Especially given how some people like to write code. ;)

They even have a GUI that runs using Java Web Start. If you have a recent version of Java, you don't even have to install anything. Just click this link and point it at your local code tree. You can't get much easier than that.

Is it a tool you need? I've been amazed at how often blocks of code have been copied not once but dozens of times. I've seen this in code from teams that turn out very good code and teams that don't. From what I've seen it's much more common than most people think.

Here's my challenge to you. Try it. See what it finds.

Then try to justify each copied block to yourself. Does the code really need to be copied or do you have an easy refactoring waiting to happen?

Reducing your lines of code, creating more readable code, and easing your maintenance work all at the same time. Sounds like a good day to me.

Jared

posted at: 22:15 | path: | permanent link to this entry

Eclipse or NetBeans?

I didn't realize there was a huge debate raging over the IDE of choice for Java developers. A friend recently forwarded me several links about the debate. I pass them on for your enjoyment.

Why Eclipse Developers Are Moving To NetBeans

Eclipse vs. NetBeans *yawn*

NetBeans vs. Eclipse - No Real Debate

After reading these entries, I think you'll agree that there is no debate. Everyone seems to agree that there can be only one winner. Now, if we can get everyone to agree on who that one winner is...

Seriously, here are a few observations.

First, competition is good. Having NetBeans chasing Eclipse will keep Eclipse sharp. And the same for NetBeans. Everyone runs faster when they are racing against someone else.

Second, if you're stuck in an IDE and don't know what it's doing for you, then you've done yourself a huge disservice. I strongly encourage you to be able to build your Java projects with Ant, your dotNet projects with Nant, and so forth.

Yes, it's more work at first, but you are buying yourself understanding. When Eclipse or NetBeans won't do what you want, you'll have an alternative. You'll also have a much better chance of understanding ~why~ things break. And it's inevitable that breaks will occur. The only question is whether or not you'll have to depend on your IDE's error messages to understand them. Don't put yourself in the position of having to switch IDEs to get a better error message.

And finally, try the other tool. Whichever one you like, try the other one. Stretch your brain and learn something new. Eclipse doesn't stink. And neither does NetBeans. In fact, I really like them both. I'm actually doing a bit of work in NetBeans today. I haven't used NetBeans in at least a year but it's come a long way.

You know, if there hadn't been a raging debate, I never would've gotten around to trying out NetBeans again.

Thanks everyone!

Jared

posted at: 20:17 | path: | permanent link to this entry

Daily Meetings: Who's Next?

I am involved with two teams who both have short daily meetings (SCRUM style meetings). Over time these meetings can fall into a bit of rut so we try to find ideas to break up the routine a bit.

One way is to have the last person who shared select the next person to share. Of course, this also tends to fall into the same rut. People tend to pick the person to their right or left and you end up going in the same circle you were trying to avoid.

So we created a next person selection rule.

You can't select anyone to your right or left unless there are no other selections available.

Letting people pick the next person is actually quite fun. We got the idea from Matt Bass who learned it while working with Ken Auer. You wouldn't think such a simple change would make much of a difference... who else has a tip or two to share? Mail them in and I'll post a follow-up.

Jared

posted at: 13:44 | path: | permanent link to this entry

But where are the Lava lamps?

Tonight on David Starr's blog I see that he's gotten himself addicted to the CruiseControl.Net Tray application.

I think that's a fine addiction to have David... but do you plan to add Lava Lamps to the mix? These lamps are red and green for the holidays, but the original used plain old Lava Lamps.

You've come this far... it seems a shame to stop now doesn't it? ;)

Jared

posted at: 00:16 | path: | permanent link to this entry

Tue, 20 Dec 2005

"JBoss At Work" Was Named Poorly

I recently met Scott Davis at a software conference. Since we both had new books in our hands, we traded books. I gave Scott a copy of Ship It (which he was kind enough to review) and he gave me a copy of JBoss at Work. Every time I pick this book up I find myself still reading it half an hour later. It's a very easy book to read and a hard book to put down. :)

Let me start by addressing my comment about the naming of the book. The name doesn't begin to do justice to the breadth of the topics in this book. From the title, I expected this to be a book on how to use JBoss. While the book does cover JBoss very well, it does much more as well.

Many people have complained about the size of the Java stack. This book gives you the introduction you need to the entire stack. Starting with Java and Ant, it takes you through cascading style sheets, JSPs, servlets, EJBs and finally into web services. It even gives you some JDBC and Hibernate.

They also provide you with practical tips and examples as they go. For example...

• A sidebar on how to enable SSL in JBoss.
• A brief XDoclet introduction
• A heads up on what version of Axis you need with a 1.5 JDK (as opposed to a 1.4 JDK).

In the first chapter they said they kept hearing "I don't wan to be an expert in it. I just want to make it work." That's what they've delivered. They don't take you into the plumbing of Hibernate or JBoss. They give you what you need to use Hibernate and JBoss and be productive. And many times that's all we need.

This is the best book I've read for providing an end-to-end introduction to the web services space, including the technologies that web services utilize. Also, they make a point of using freely available tools for every example. This is a book you can buy and then follow the examples at home without buying any extra software.

Are you planning on moving into the Java web services space? Then I suggest you get a copy of this book and read it first.

Jared

posted at: 14:53 | path: | permanent link to this entry

Leornard Nimoy Sings "Bilbo Baggins"

I'm not sure what to say... it's humor. Laugh? A great post the week before Christmas... as a break? :)

I found this on Digg.com a few weeks ago but it's not there anymore (that happens a lot!), so here's the direct link to Google Video.

Link

Enjoy... or at least laugh at what people archive for posterity.

Jared

posted at: 11:32 | path: | permanent link to this entry

Unit Tests as a Gateway Drug

As I rule I encourage people to avoid unit testing and write higher level tests. There's nothing wrong with unit tests and I'm not opposed to them, but it seems like we are, as an industry, overly focused on unit tests to the exclusion of other types of tests. I try to encourage people to write tests that exercise more of their application. Mock client tests are my favorite type. They exercise more code than a unit test. When used in a Continuous Integration environment, you still get really good feedback on where problems are. Mock clients are coarse-grained tests in a fine-grained build.

Recently I'm encountering more teams whose code is "untestable". They're convinced that their product isn't testable because it has a browser GUI.

First, that's just flat out wrong.

Do you have a browser front-end? Then look at Watir, Selenium , htmlunit, and others.

But I've also found that unless the entire team gets involved, creating an automated testing suite is more difficult than it needs to be. It's so much easier when there's a team involved. But the idea that "our product isn't testable"... that's a difficult mindset to overcome.

So, in the cases when I don't have the bandwidth to create a suite of tests myself, I'm starting to sidestep the opposition.

Assuming that your product isn't testable from the GUI, your units are testable. So we'll start at a level you can't argue with... unit testing.

So far it seems to be working... my goal is to introduce automated testing via unit tests. Then we'll broaden their horizons a bit. :)

I'll let you know how it works out.

Jared

posted at: 11:16 | path: | permanent link to this entry

Mon, 19 Dec 2005

Dual core Mac laptops in January

OSX has pulled the Mac line from it's traditional role as a niche operating system and positioned it for a strong run this year. I know a lot of people who've converted and aren't coming back. At the No Fluff Just Stuff software symposiums most of the presenters were on Macs. Macs just seem to be popping up everywhere as both a development platforms and desktops.

I've been waiting for the Intel versions of the Mac for my purchase though. I nearly bought a Mac Mini several times because my publisher has a very nice book rendering system that runs everywhere, but it runs more easily on a Mac. :)

However, now I'm now holding out for a Mac laptop. The rumor mill has persistently put the release for these notebooks in January, but the more recent rumors (today from from Think Secret, earlier from Mac Rumors) are saying the laptops will contain Intel's new Yonah processor and be dual core laptops.

From the Think Secret article:

Yonah's launch could mean that dual-core Yonah iBooks, at speeds of 1.5GHz, might be announced in January

Think about that for a minute. As a desktop, a dual core machine is just as responsive as a dual processor machine. That level of power will be in a laptop and it will be a Mac. It won't hang when you compile. It won't drag while you run twenty programs.

Again, OSX has converted many people in the last year. Now Macs will be on a more compatible hardware platform. And they will have the most responsive laptops on the planet.

I'll be in line when they are released. If only they were ready for Christmas!

Jared

posted at: 14:20 | path: | permanent link to this entry

Lisp programming videos

Following the lead of the Ruby on Rails guys, Sven Van Caekenberghe made a Lisp tutorial video.

The site is ~really~ slow. I suspect that Sven is overloading his hosting provider. :) Be patient. It will eventually load.

From the page:

Lisp Movies: Episode 1: HTTP Client and Server My first screencast showing how to use the HTTP protocol as client and server in Common Lisp, featuring the LispWorks IDE on Mac OS X.

Remeber what Dave and Andy say about learning one new language a year? Here's another good jumping in spot. (When's the last time you learned a new technology or language just to stretch your brain and provide a fresh perspective?)

Enjoy!

Jared

posted at: 12:33 | path: | permanent link to this entry

Sun, 18 Dec 2005

Carnival of the Agilists

I stumbled across the Carnival of the Agilists this week. It's a periodic blog with lots of good agile software links.

The Scrum graphic was great.

I also really liked the bit on how to handle legacy code. ;)

Enjoy!

Jared

posted at: 21:22 | path: | permanent link to this entry

Fri, 16 Dec 2005

Ruby on Rails Quickstart Bundles

If you're on OSX and wanting to experiment with Rails, then check out the Locomotive project on SourceForge. (Thanks to Charlie Squires for sending me the link!)

If you're a Windows or Linux user, then check out Instant Rails

In both cases the teams have bundled up Ruby, Rails, a database, and everything else you need to run Rails, verified the versions all work together, and bundled it all into a single package.

From the Locomotive web site:

Locomotive is a flexible one-click solution to Ruby on Rails development for Mac OS X 10.3+. In one self-contained application, it gives you a fully functional Rails development platform including: (but not limited to)

• The framework: Ruby on Rails
• The favored webserver: lighttpd with FastCGI
• An embedded database: SQLite

From the Instant Rails website:

Instant Rails is a one-stop Rails runtime solution containing Ruby, Rails, Apache, and MySQL, all preconfigured and ready to run. No installer, you simply drop it into the directory of your choice and run it. It does not modify your system environment.

This is the best way I know for a Rails novice to get up and running. I haven't used the Locomotive project but I have tried Instant Rails and it works great.

Why post about Rails again? Because your brain needs exercise. Learn something new over the holidays. :)

Enjoy!

Jared

posted at: 20:54 | path: | permanent link to this entry

Found- One Digital Camera. Your Pictures are on Flickr

This is cool. Here's the link

From the Flickr post:

we found a digital camera. if you know any of the folks in these pictures, have them email me with the following info for the return of their very nice camera: tell me where & when I found it/where it was lost (city and particular circumstance), the size of the memory card, make & model and maybe identify some of the other folks on the card (not pictured) and i'll be happy to ship it home. I just feel bad for whoever lost their family photos. Thanks! Camera was found in USA, New York state.

Jared

posted at: 07:17 | path: | permanent link to this entry

Thu, 15 Dec 2005

The New Practice Didn't Help

So what do you do when you've introduced your teammates to the latest greatest practice and it didn't do any good? What if it makes things worse?

This blog entry is a reprint from Ship it! A Practical Guide to Successful Software Projects. This section comes from the last chapter of the book, Common Problems and How to Fix Them (also known as the FAQ).

Obligatory legalese: The Following text is Copyright 2005 The Pragmatic Programmers LLC. All rights reserved.

The New Practice Didn't Help

We've talked all through this book about "standing on the shoulders of giants." The best way to do that is to learn the practices that the giants are using and use them yourself. There's always room for improvement in any software shop, so always be on the lookout for better practices that will provide that improvement.

When Not to Introduce a Practice

It seems strange to start here, doesn't it? But many shops add new practices and process when they're not necessary or at a bad time when they'll be disruptive to critical work. They end up causing more problems than they solve. The first question you should ask yourself whenever you're thinking about adding any practice should be, "Is now a good time to do it?"

Don't try to introduce a new practice or process if there isn't a problem that needs fixing. Never introduce a change because it's "the right thing to do." Instead, identify the actual problems in your shop, and then figure out how to fix them. Before you know it, you'll have a smoothly running shop because you've fixed only what's broken.

TIP: Only fix what needs fixing

Be creative when thinking about problems and fixes. "There's more than one way to do it" (The Perl mantra, noted at the bottom of the Perl man page) applies to more than just Perl programs! There are lots of ways to successfully run a software shop. No set of practices and no process will always work for every team on every project. You also need to think about what else is going on in your shop before you introduce a new practice. Three days before a major release is probably not a good time to change your current process. Your team will probably not take kindly to any distractions when they're frantically trying to get the product out the door. A much better time would be a week or so after the product ships, so the team can "catch their breath" before considering the change. So choose a time to introduce the practice that will minimize disruptions to critical activities.

TIP: Disruptive "best practices" aren't

And of course, make sure the practice or process you're considering will actually improve things. If it won't make things run faster and more efficiently, your team won't (and shouldn't!) adopt it. As far as they're concerned, "If it lets me go home at 5 p.m., I'll do it."

How to Introduce a New Practice

Once you've decided to add a new practice to your repertoire, how do you go about doing it effectively? There are two main things you've got to do: demonstrate and persuade. Accomplish these two goals, and you'll have a group of raving fans in no time. You've got to get buy-in from several groups of people. First and foremost are the people who will actually be practicing the new practice, namely, your team. If they aren't excited about it, it won't matter if anyone else is. How many stories have you heard about companies that have mandated from the top down new ways of doing things? And how many of these mandates have produced lasting change for the better? (Answer: not many. Think Total Quality Management, ISO-9000, and the like.)

Conversely, how many times have you heard about technologies and practices that have been brought in at the grassroots level, which then sweep through a group, company, or even industry like wildfire? (Think UNIX vs. mainframes, PCs vs. UNIX, agile development vs. the Waterfall software development model.)

TIP: Innovate from the bottom up

So how do get your team excited about this new idea? Remember we talked earlier about demonstrating? Show them the process or tool; don't just tell them about it. In particular, show them how well it works, especially in comparison with the old way of doing things.

If you know a "raving fan" who has actually used this practice to good effect, bring them in and have them show the group how well it has worked for them. Even better, use it yourself. Build up evidence about how much more productive and efficient you are, and then tell your team about it. You probably won't have to do much talking because the team has probably already noticed how much better you're doing! The key is to prove that this new-fangled idea is everything you say it is.

TIP: Show, don't just tell

Persuading your team to use this new practice is critical. That's not to say that you can completely ignore your management, however. Getting buy-in from your manager makes introducing a practice easier. Your manager can persuade those team members on the fence about the idea to give it a try and can act as a shield from the rest of the company. Such shielding can give your group time to figure out the best way to implement the practice. And obviously, it's easier to work out a change in your group when you don't have to hide what you're doing.

If you can't get management buy-in, don't let that dissuade you from adopting a practice, especially if the team is excited about it. Treat it like a "stealth practice," and use it quietly but fully. Practices like code reviews don't require management buy-in to be effective. You can use them without anyone outside your team being aware that you are having code reviews. You can set up a CI system on your own box and share the results with your team. After you've gotten some experience with the practice, show the practice, along with the associated benefits, to management.

TIP: Cultivate management buy-in

Tue, 13 Dec 2005

Desktop Linux Today

In this blog entry James Robertson says he doesn't think Linux will ever exist as a viable desktop alternative because things don't "just work".

I'd encourage James and others to check out how far the Kubuntu and Ubuntu projects have come.

Everything on my laptop just works... as well as a desktop machine. Wireless cards, USB keys, etc. For me, it all just works. And since both buntus come with live CDs that you can run boot and run live, trying out the system doesn't require a partitioning or an install to your hard drive.

Out of the box you get an office suite, graphics editors, and a lot more. And they all just work.

Don't get me wrong. I'm a fan of Windows and OSX, but neither comes with all the applications you need out the box.

I've used Linux since Slackware was the only game in town. There was a time that James was right.

But today? I'm not convinced. What do you think James? Willing to give Kubuntu a whirl? It might surprise you!

Jared

posted at: 18:15 | path: | permanent link to this entry

I Hate Email

Really. I do. Somedays more than others. Today? A lot. :)

Email is a very poor medium for communication. It's just flat text after all. ASCII. But it's one of the main communication methods geeks use. Andy Hunt often says that the bandwidth on email is limited and I experience that more somedays than others.

So what's wrong with email?

You can't see the smile or the frown. Whether you're the sender or the reciever, you have no idea what the tone behind the message is. You're left to assume the tone. Sometimes this works quite well. Sometimes it doesn't. When the reader is having a bad day, even a well-composed email can be interpretted poorly.

You can't stop talking in the middle of an email. In a face-to-face conversation I can see you getting angry or annoyed and stop talking. With email, you've got the entire message already typed out and if something strikes your reader the wrong way you can't snatch it back again.

So the tip for the day is this. When you recieve an email and you're just sure the person just attacked you, don't reply.

If you have an overpowering need to reply, remove all names from the To: field... this avoids accidentally sending out the message with a wrong keystroke. Then type up your reply and save it in your Drafts folder. Don't send it.

Then do one of two things. The first and best option is wait until tomorrow. Give it time to cool off and for everyone to get a little perspective. Sleeping on it is a great idea.

Second, walk over. Call. Switch the conversation to a better, richer communication medium. Make a personal connection with the person involved and find out what was really going on.

Assume it was innocent and see what happens. It won't always be a case of misunderstood intentions, but I find it very often is... and it's a very nice surprise when that happens.

Have a comment? Send me mail! :)

Jared

posted at: 12:34 | path: | permanent link to this entry

Mon, 12 Dec 2005

Validate your RSS feeds on line

Here's a handy utility. It's called the Feed Validator. And it does just what the name implies.

About once a week I'll paste in a character from a word processor or from a PDF and that character isn't allowed in RSS feeds. My blog software doesn't mind it, just passes it in the RSS feed. Then I start hearing from people that I've posted a bad feed again. (Sorry about that!)

It's usually one of three problems. First, an angled single paren instead of a straight, proper paren. A good one looks like this '

The second and third errors are double parens. One is the right paren, the other the left. Replace them both with regular parens like this " and you'll be fine.

Just hit this handy url and you can validate your feed (or someone else's) to see exactly what the problem is. And while I've found it doesn't do a great job of pointing out the offending line or character, it always gives the correct error message with the right Hex value to match up to your offending character.

Enjoy!

Jared

posted at: 01:26 | path: | permanent link to this entry

Sun, 11 Dec 2005

Experimenting with Google AdSense

I'm curious to see how Google's AdSense works, so I'm trying this page out.

I'm not sure if this works better than the header block (which may or may not be in the version you are looking at right now). I might remove the image/text mixed ad block and put in a text block (like exists in this blog entry).

Over the next week or so, I'll try out a few different formats and see what is the least intrusive but still effective.

I'm not looking to be a professional blogger, but it would be nice to cover some basic hosting costs and maybe even pay for a toy or two. Google AdSense seems to be the most popular and painless way to experiment with this type of revenue ex blog.

However, since Google won't let anyone talk about how much money they pay out, I have no idea if this is a complete waste of time. But I thought I should at least let everyone know why the ads are appearing. Just an experiment.

I was on the fence until I saw this page which made it sound very simple... and it was.

What do you think? Is it hideous? Does it detract from the message? Annoy you greatly? :)

Seriously, let me know. If I get dozens of emails complaining, they can be removed quickly. I'll take silence as approval or indifference.

Jared

Update: Apparently the way that Bloxsom publishes it's headers has caused the entire blog the RSS feed to look like it was just published. (sigh). The actual blog retains it's orginal order and time stamps. Sorry about that.

posted at: 19:42 | path: | permanent link to this entry

Thu, 08 Dec 2005

Humane Interfaces versus Minimal Interfaces

There's been quite a fuss about Martin Fowler's post on Humane Interfaces. If I summarize his post for the sake of brevity, a larger, more humanly readable API is preferable to a smaller, more cryptic API.

The discussion seems to be falling into two camps. One side says that if you are a ~real~ developer, you'll invest the time to learn the API. Then, as a skilled user, you'll apply that skill and build something.

The other camp seems to feel that with a human readable API, you just skip the "invest the time to learn the API" and move straight to building something.

Hmmmm...

Spend time learning Yet Another Unique API... or write code.

Spend time bulding a smaller, tighter, cleaner, more cryptic API... or make it easier to understand ~and~ use?

In my experience a team writing an API will spend a minimal amount of time adding these additional API calls. But the performance increase I've seen on the teams using this technique is substantion.

Remeber, the API developers wrote the API code. They know it better than anyone. For them, adding a first() and last() routine will take 30 seconds. Literally. The other option is to force your end users to learn the API well enough to know if the last() call should be list.indexOf(list.size() -1 ) or list.indexOf(list.size()). These bits of arcane, useless trivia should not be force fed to your users. It's just inefficient.

What was the argument again?

Jared

posted at: 23:54 | path: | permanent link to this entry

Testing Untestable Code

This blog entry is a reprint from Ship it! A Practical Guide to Successful Software Projects. This section comes from the last chapter of the book, Common Problems and How to Fix Them (also known as the FAQ).

Obligatory legalese: The Following text is Copyright 2005 The Pragmatic Programmers LLC. All rights reserved.

Testing Untestable Code

If you are a developer or tester trying to get an automated test suite set up for your product, you may find yourself in the uncomfortable position of trying to test a product that doesn't have good "hooks" for your test rigs. It's not impossible to test "untestable" code, but the effort involved in test creation and maintenance usually cancels out the benefit of the automation.

For instance, you might be trying to test an HTML page that has a lot of unnamed fields. So instead of using the "name" or "id" tags to locate a field, you count the items on the page and check the value in the fifth item. This is very difficult for someone else to understand and maintain, but the test is also very fragile. Often, changes to the page will break your test.

What's the solution? Tell your manager you want to start test driven refactoring. You want to start adding the simple hooks to your application that make it possible (or feasible) to do good automated testing.

First, create (or borrow) a test plan for the product. Keep the plan simple at first. Don't try to make it perfect on your first attempt. Shoot for a simple pass that exercises basic functionality.

Second, write an automated test. Make the test go as far as you can. When you get stuck, what's the least amount you can add to the product's code to get the test running? Is it just a return code to an existing API or an "id" tag for an HTML field?

Don't try to fix every problem with your first pass. Don't try to add "id" tags to every page in your product; shoot for the one page you need to get the test passing. If your test plan hits a roadblock, don't stop. Remove the part of the test plan you can't test and move on. Remember that you can also add the hard part to your next test plan.

The goal here is incremental improvement and momentum. As you make small improvements, your developers will start learning how to create testable products. As you write automated tests, you'll start learning tricks too. You'll be surprised at how much support you'll get once you've got a basic automation suite in place.

The Tip?
Use test driven refactoring to clean up untestable code

Related blog entries: Test Driven Refactoring and One Test per Feature

posted at: 23:22 | path: | permanent link to this entry

Targetted Skills Acquisition Versus Free Range Chickens

I've had this floating around in my head for a while. It all got started after someone told me that they though conferences were a waste of time. In this person's opinion you never come away learning enough to be useful. The learning is only skin deep and you learn things you shouldn't try to integrate at your day job anyway. If the course is on Spring and your company is using Struts, you've just split the mindshare and possible diverted your project.

This point of view is what I call Targetted Skills Acquisition. Learn only what you need to get through next week. When you need to learn Hibernate, go learn it then. Buy a book, go to a class, or just download something and get to work.

On the other side of the fence, we find Free Range Chickens. A free range chicken tends to browse around, learning a bit over here and a bit over there. They do tend to waste an lot of time learning things that they don't need to know. Most of the tools and technologies chickens learn are never used.

When a problem is encountered, who can solve it the quickest? The chicken can. Someone who browses a wide variety of technologies will immediately know what category of technology can be used to solve a problem. A targetted personality will have to research the problem before they understand how to attack it. However, the chicken has been "wasting" time all along, learning lots of other bits they never use.

When solving a computational intensive problem, a chicken might look to a grid or a distributed solution because they've read about grids and are familiar with the concepts even though they've never used them before.

The targetted skills person isn't familiar with ideas like grids, so they spend a lot of time trying to tune their code to run as fast as it can on a single machine. It's a very traditional approach that prevents the application from scaling to a true enterprise solution.

Another factor to consider is that a chicken who learns about both Struts and Spring is more qualified to evaulate both and understand which one solves their problem better. If you are ignorant of the strengths of alternatives, you can't make an educated choice about the technology. This is why targetted skill types so often pick the wrong technology for a problem. It drives a good chicken crazy just watching it happening.

What is the correct approach?

I am a Free Range Chicken through and through, but I work with some very smart and effective people who are completely Targetted Skills Acquisition.

|'ve seen times in my life when I wonder if a more focused approach wouldn't have served my employer better. Would we have turned out product faster if I had been more targetted? I don't know.

But I also have seen many targetted skills people completely miss the boat with their technology choices. Their lack of broad exposure causes them to re-invent the wheel poorly instead of using a simple, existing solution. They are ignorant of industry best practices so they don't use them.

A few years ago I spoke to an "industry veteran" at the top of his game. This person had more than a decade of software experience but had never heard of MVC. He wasn't dumb- in fact, just the opposite. He understood the concept and it's benefits immediately when I showed it to him. He just hadn't been exposed to it before. He's a very smart person, but extremely targetted. And no, he wasn't coding assembly or device drivers. He was able to use the idea to do his job better.

It's not that a Free Range Chicken type is any smarter than a Targetted Skills Acquisition person. It's that they are more broadly educated.

So, what's the balance? How do we both stay educated and effective?

How much do you strive for targetted learning versus browsing across the free range? The fact that you are reading a blog tells me that you have chicken tendencies. :)

How, as a company, do we encourage both ideas? I'm thinking this is something that Google's policy of letting everyone spend 20% of their time on an independent project might address.

I'm struggle with this topic every day. I wonder what types of solutions others have found?

Jared

posted at: 21:30 | path: | permanent link to this entry

Java Code Coverage Tool Cobertura Released

The open source toolkit Cobertura released a new version this week. They made some major additions, including support for AspectJ compiled code. Cobertura continues to improve with every release.

It's adoption is increasing as well. The SourceForge statistics page says Cobertura's had over 7,000 downloads and more than 400,000 hits on the web site.

Are you using code coverage? A coverage tool will tell you what parts of your source code are being exercised by your test code and what parts aren't. It's the only effective way to knowing what code is completely untested. It formats this information in XML files or, if you prefer, a nice report to make it easy to digest.

Here's a quote from the release notes:

We've just released Cobertura 1.7. We fixed the problems with the merge task, as well as a few other bugs. The full list of changes is below.

Enjoy!

Jared

posted at: 21:10 | path: | permanent link to this entry

Tue, 06 Dec 2005

Google Mapping Made Simple

If you've ever heard Scott Davis speak on the various real world mapping APIs, then you know how easy it can be to get started with your own mapping applications. He really makes the topic come alive with lots of relevant, clear examples. You come away knowing enough to get started immediately with just the sample code from his presentation.

I got to hear Scott at a No Fluff Just Stuff conference in Reston, Virginia earlier this year and it was great. I still have the Power Points on my desk! :)

However, he's now made it easier for everyone to participate. Scott just completed a Friday for the Pragmatic Programmers. A Friday is a short, PDF only document. Friday's are designed to get the information in your hands quickly and easily, so they are short and to the point. They are also much cheaper than a book!

Scott's Friday is called Google Maps API: Adding Where To Your Application and brings the same flavor of his NFJS talks to your desktop The code snippets can be copied right out and the links are clickable.

If you have thought about tinkering with the mapping API from Google, you owe it to yourself to pick up a copy of Scott's paper. I think you'll be glad you did. It's a great way to jump start your mapping work or just learn something new to exercise your brain.

Obligatory disclaimer: the Pragmatic Programmers also published a book of mine.

Enjoy!

Jared

posted at: 21:21 | path: | permanent link to this entry

Java versus Ruby on Rails

Rick Bradley posted an interesting write up of an evaluation of Ruby on Rails. He raises of a lot of good points about both technologies and it's a good piece to make you think.

You'll find the blog entry here

Enjoy!

Jared

posted at: 20:56 | path: | permanent link to this entry

Chainsaw Managers

Kevin Smith forwarded me a great blog entry entitled Ode to a Chain Saw

What can I say? Just read it. :)

Enjoy!

Jared

posted at: 20:29 | path: | permanent link to this entry

Sun, 04 Dec 2005

Help! I've Inherited Legacy Code

This blog entry is a reprint from Ship it! A Practical Guide to Successful Software Projects. This section comes from the last chapter of the book, Common Problems and How to Fix Them (also known as the FAQ).

Obligatory legalese: The Following text is Copyright 2005 The Pragmatic Programmers LLC. All rights reserved.

Help! I've Inherited Legacy Code

You've inherited a legacy product that you will be maintaining and enhancing. What's the quickest way to get a handle on it? Learn to build it, automate it, and finally test it.

1. Build it
First, figure out how to build it, and then script that build process. This task isn't always easy, especially if the code has had only one owner. The code will often build on only one machine because it relies on the surrounding environment. Once complete, anybody can build the product on any machine. After that, it should be easy to automate the builds.

2. Automate it:
Your goal is to automatically build and test the entire product on a clean machine with an absolute minimum of manual intervention. We didn't say no manual intervention; there's a balance here. Sometimes it's easier to manually install and configure a supporting piece of the environment than to write a script to do it automatically. Apps that you install only once are prime candidates (compilers, etc.). Document all the build steps and make this documentation publicly available.

3. Test it:
Figure out what the code does, then begin testing by writing mock client tests for it (see the sidebar on page 45). Once you have the project building cleanly, you'll want to confirm that it works. In order to write the tests, you'll have to learn exactly what the product is supposed to do (no surprise there).

Mock client tests are a good starting point: they test the broad functionality of a product because they act just as a product user would.

4. Test it more:
Figure out the product's innards (things such as structure, flow-of-control, performance, and scalability), and write more tests for it. Unless the product is completely unused, there will be bugs you'll need to fix (or at least document) or enhancements you'll have to make. Normally these changes are a pretty scary thing to do to legacy code, because you're never quite sure what you're going to affect when you make a code change. But you can do this fearlessly because of the mock client tests you wrote as a safety net; they'll keep you from breaking things too badly. (You did write those tests, didn't you?)

Write a new test for every bug you fix and for every enhancement you add to the product (see Defect Driven Test Creation). The type of test you write will depend on what you're changing (e.g., a unit test for a low-level internal change, or a mock client test for a new feature). At this point you're treating the legacy product in the same way you would any other product you support.

After you've done all this, anybody will be able to support this code! They'll be able to automatically build it anywhere and then confirm it's working correctly by running the automated tests on their desktop. And the automated build system will run the build and tests again in a clean environment to be sure that everything is really still working.

The Tip?
Don't change legacy code until you can test it

posted at: 19:21 | path: | permanent link to this entry

Common Problems and How to Fix Them

The last chapter in Ship it! A Practical Guide to Successful Software Projects is called Common Problems and How to Fix Them (also known as the FAQ). The chapter is a series of FAQ-esque entries with some solutions to those problems. I'm going to mix in a few of the topics as blog entries over the next few weeks.

If you've read the book and would like to see a particular entry published, let me know. Also, if you have an entry or answer you'd like to see expanded, this would be a great time to ask. :)

Thanks!

Jared

posted at: 19:19 | path: | permanent link to this entry

Sat, 03 Dec 2005

Military bloggers

I saw a link today on Digg about a site that links to lots of military blogs. The site is MilBlogging.com

I've only looked at a few of them, but it seems to be a refreshing way to get a front line view of various situations world-wide. Seems to be weighted towards Iraq.

It's nice to see what real people are thinking and seeing without the "media" helping to interpret everything. This is what I think about when I hear people talking about bloggers as citizen journalists.

Enjoy!

Jared

posted at: 12:35 | path: | permanent link to this entry

Thu, 01 Dec 2005

Java Sails on Rails

A co-worker of mine posted about a Java version of the ever popular Rails framework. Sails looks very interesting but I haven't had time to play with it myself. The guys involved hang with a very smart crowd though and that alone gives it some credibility with me.

Here's the link to Matthew Bass' blog entry on Sails.

Let me know if you like it. I'm quite curious to hear about how well it works.

Jared

posted at: 19:46 | path: | permanent link to this entry

More on Continuous Sin

A few weeks ago I blogged on Continuous Sin, a very interesting Continuous Integration product.

The idea that a code change can be automaticlly rejected if it fails to pass the test suite is intriguing. I also liked the idea of running on multiple machines to help the system scale.

Casper Hornstrup, the author of Sin (is that a resume line item or what?), saw my blog entry and sent me mail answering a few of the questions I raised. With his permission, I'm posting his reply.

Hi Jared.

Enjoy!

Jared

posted at: 15:57 | path: | permanent link to this entry

Tue, 15 Nov 2005

A Great Test

There are several characteristics a great test should have. I've discussed the topic recently and decided to create a blog entry about it. It will also be a part of a book I hope to start early next year.

By the way, bear in mind that I'm not talking about unit tests. While they do share some characteristics, they don't require external resources like external data.

Create

Anything you can do to make your tests rock solid and relable, you should do. Recreating data for each test run is an important step. Use tools like dbUnit to easily reproduce your data.

Run

That is to say, nobody has to run it. Once a test suite is set in motion, nobody needs to push a button, start a server, click a dialog or run a script.

Nothing is more frustrating that seeing someone create an "automated" test that doesn't run without human intervention. Sometimes people get so close, but forget to stop short before the edge of the cliff.

Decide

Build enough smarts into your test that it can either pass or fail without your help. It already has enough smarts to test the code. Add just a bit more and let it know what the result is. This frees you from the boring chore of reading log files every morning.

Fail

There are few ways to move in this direction.

1. You can target active code development. Put a few tests in place before the refactoring starts. These tests will ensure that your work doesn't change the code's function. This is great way to start your performance tuning, bug fixing, or feature adding work.
2. Wrap tests around bugs as you find them and then test the code close by.
3. Target code that's had historical problems. The odds are good that the routines that caused problems last year have undiscovered issues. Get test coverage in place to help uncover those unknown issues as well as keep the state of the code stable when addditional bug fixing occurs.

Clean

Finally, a great test cleans up after itself. It doesn't leave test droppings throughout the system that could corrupt the next test run or have unintended consequences.

Report

Sure, someone could go code diving to find the failed test and attempt to decipher the intent of the author. But a great test doesn't require that. It tells you what happened.

More?

Tell me.

Jared

posted at: 21:01 | path: | permanent link to this entry

Dancing Yoda: Update

I recently posted a link to a great video clip... Master Yoda break dancing. I've since learned that the Yoda clip is an Easter egg on the Revenge of the Sith DVD. You can find the directions to access the clip here.

The real story behind the egg is very interesting. The entire story is posted on Star Wars.com.

Apparenty Michel d'Annoville started the project as a surprise for the animation director... it turned out so well that when Lucas saw it, he insisted it go on the DVD.

But don't take my word for it. Read the entire story. :)

Enjoy!

Jared

posted at: 20:14 | path: | permanent link to this entry

Run Linux on your Windows desktop

You may already know that VMWare is now giving away their virtual machine run time.

What does this mean? Think of Adobe and PDFs. They give away the PDF reader (Adobe Acrobat) but they sell the tools to create PDFs. This is the same concept. You can run a virtual machine with the VMware player but you can't create one.

But you don't have to create a virtual machine. You can just download one. :)

Check out the VMWare Virtual Machine Center. Just by registering you can get VMs for Red Hat Enterprise Linux, Novell's Suse, etc. You can get WebLogic and Websphere as well.

You can also download their Browser Appliance . It's a prebuilt Ubuntu Linux image with FireFox already installed. I'm running on my desktop at the moment and it's quite responsive.

One of the cool features that I didn't expect is how it preserves state. Initially you "boot" into your virutal machine, but when you exit it preserves the state of the memory. When you restart the virtual machine image, it brings you right back to the same spot. Did you leave the browser open? It'll still be open. Cool.

This looks like a really easy way to keep different web browsers around, different versions of an operating system, etc. I can see this being very useful for developers or testers who need another environment around... or just someone who wants to tinker a bit.

Jared

posted at: 19:26 | path: | permanent link to this entry

Sun, 13 Nov 2005

Keeping continuous integration relevant and fun

I found this blog entry this morning and I had to pass it on.

Some clever folks used the Ruby-DOOM API to create Doom maps based on the number of PMD warnings!

This is an idea that people should grab and run with... how many other tools could use something like this? CruiseControl? Cobertura? FindBugs?

It's amazing how much can be done with a some general knowledge, a little bit of specific knowledge and a dash of creativity.

What have you thought about creating this week? ;)

Enjoy

Jared

posted at: 09:17 | path: | permanent link to this entry

Fri, 11 Nov 2005

Dancing Yoda?

I've often wondered what Yoda was doing between the two trilogies, during that long exile. Now I know.

What else can I say? It's humor. You'll love it.

Yoda link

This is why they made Google Video!

Enjoy!

posted at: 18:01 | path: | permanent link to this entry

Sat, 05 Nov 2005

Beyond Java: What's Next?

I just finished reading Beyond Java by Bruce Tate, author of several books including Bitter EJB, Better, Faster, Lighter Java and Spring: A Developer's Notebook. Let me start by saying that I really liked the book.

Who should read this book?

Anyone who writes Java for a living. In fact, anyone who works with code and also looks ahead of the game to see where things are headed next. Bruce has said that he's really good at seeing things from 10,000 feet high. This book gives you that type of high-level perspective but then it layers in practical application.

What's the big picture?

Bruce starts with the environment and situation that helped Java get started and then helped it thrive. He then talks about where Java is today, where it's headed, and how the situation parallels the early days of Java. He shows how the time is ripe for a new disruptive technology to emerge. Java continue to focus on the enterprise, and it's doing very well there, but the barrier to entry to for the new developer is getting ever higher. As Java gets more and more complex, the time is becoming more ripe for a new low-end replacement. Something that easy to use, easy to get started with and easy to become very productive with.

There's an good overview of a number of languages ranging from Perl to PHP to Smalltalk and where each one is positioned in the market. Bruce comes down hard on the side of Ruby, Rails and continuations... or at least hard on the side of the next big thing sharing a lot of the same traits those technologies bring to the table.

What's to like?

There are several parts of this book I really enjoyed.

I liked the historical overview of the Java language in it's early days. I worked in Smalltalk long enough ago to remember some of the history. The perspective of Microsoft's role in the rise of Java was also refreshingly honest instead of the obligatory Microsoft bashing so many books include.

There is an entire chapter devoted to introducing you to Ruby, another for Rails and a third for continuation servers. Each of the introduction chapters was excellent. Very well written and easy to follow. I've actually gone through the Ruby snippets in the book and been able to run them all. I consider the sign of a good book when I am pulled in enough to actually run the code samples.

What's not to like??

The book is about half history and half future with a strong bent towards Bruce's vision of the future. If you see what Bruce sees and agree, you'll love this book. If you don't agree with where Bruce sees the industry headed then I think you'll get annoyed by the Ruby focus. But I can't complain about anything else in the book. I really liked it.

What's the Summary?

What were the factors that led to Java's rise? Are those factors in play again to bring another technology to the forefront? If so, what will that new technology look like? How can I get a head start with the new technology?

Enjoy!

Jared

posted at: 13:46 | path: | permanent link to this entry

Thu, 03 Nov 2005

Defect Driven Test Creation

Defect Driven Testing is a great way to start accumulating testing coverage on a product that's already in the field. It's a pretty simple idea that lots of people are already using under different names.

The steps are simple.

1. Find a bug (also called a defect) in your product. Okay, I know this never happens to ~you~, but other people in your shop can use this. ;)
2. Write an automated test that exposes the bug. This test should fail with a message that points out the defect.
3. Take the test that fails and then work on your code until the test no longer fails. You know the code is fixed when the test stops failing. If the test doesn't fail anymore but the bug isn't completely fixed, fix the test you have already or add another one. This step is a lot like Test Driven Development.
4. Add the test to your Continuous Integration system so that it will be run every time the code changes. This will keep the defect from sneaking back into the product. When the defect does show up, laugh loudly and stomp it out again.

That's it. It's pretty simple stuff but very effective. What are the key points here?

First, write the tests for the areas of the code that need tests. Whether this code is under active development or is just intricate, you'll be adding tests directly on top of the code with known issues. It's possible that other areas of your code need automated tests more, but you can address those areas when you're actually fixing bugs in those areas.

Second, you'll be adding tests in familiar code areas. I say it's familiar because you've been tracking down bugs in the area. This means you don't have to go learn a package to write tests for it. You're already invovled. Take advantage of that.

Third, bugs generally come back to haunt you. Many developers keep multiple copies of the code on their machines. When they fix a bug in one tree, they don't always get the fix into the other trees. Then they commit code in the other trees along with your pesky defect. Instant bug regression. You can "innoculate" your code against regressions by testing in a Continuous Integration system.

Also, when you add one test, be sure to play a little test Jazz. Variations on a theme. You'll often find more than one bug in an area.

Try out Defect Driven Testing the next time you have to track down a bug and squash it. You can build a very effective test suite in a short amount of time.

btw, related blog entries are Types of Tests, A Short JUnit Tutorial, and JUnit is not a Unit Testing framework. Sorry for the Java bias. I plan on adding more dotNet resources as time allows, but the ideas do apply.

Enjoy!

Jared

posted at: 20:10 | path: | permanent link to this entry

No Fluff Just Stuff was awesome!

I spoke in both Atlanta and Reston's NFJS software symposiums and had a great time. I think I had a better time meeting and getting to know the other speakers than presenting... but presenting was a blast too.

I'm trying to give you a flavor for the types of people you'll run into and get to talk with if you get a chance to attend a NFJS. So here's a quick list of a few of the people I got to spend a few minutes with over the last two weekends, in no particular order.

• Andrew Glover-I met Andrew in the hall on my way to attend a session and we ended up talking instead. If you haven't seen his book Java Testing Patterns, I'd suggest you check it out.
• Bruce Tate- This very well known author and speaker asked me, a newbie, no-name author, if we could trade books! What a humble gesture. I got a copy of "Beyond Java" and he got a copy of "Ship It!" Thanks Bruce! Btw, Beyond Java is an awesome book. I just finished and will post a review soon. I also had a chance to talk with Bruce, Ben and Venkat on the way to a pre-Halloween party at Neal Ford's house.
• Keith Donald-Another great guy. We probably talked for an hour before I realized he was one of ~the~ Spring guys. (I am so out of the loop these days!) We talked about the unique architecture of his house, his soon-to-arrive child, etc.
• Scott Davis-I attended two of Scott's talks (great stuff!), shared a ride to the airport twice, and had supper together. His latest book, JBoss At Work, is the next on my reading list. His talk Testing the Web Tier, Part 2 was full of great tools with practical usage tips.
• Stuart Halloway-We were practically stranded in the Dulles airport, got to talk over food a few times, and sat on two expert panels. Despite being a Duke graduate, Justin's a great guy.
• Ted Neward-I got a chance to continue a blogged thread on the use of the term Best Practices. I don't think we changed each other's minds, but it's still a good conversation to have.

I'm just going to stop at this point. The post would go too long if I told you about getting to talk with Dave Thomas, Mark Richards, Floyd Marinescu, Paul Duvall, Ted Neward, and others. Let me just say that attending a NFJS symposium will give you a chance to mingle with some very smart people and potentially pick their brains about the future of our industry. I consider myself very fortunate to a part of the conference.

Btw, those of you who were kind enough to fill out evaluation forms for me in Atlanta and Reston, thank you. I made the cut and should be on the tour next year. I appreciate all your feedback and hope to incorporate your comments into next year's talks.

posted at: 17:51 | path: | permanent link to this entry

Mon, 17 Oct 2005

What's your UI?

As a developer or tester, you realize that a bad UI can ruin a product. No matter how good your product is, if you don't present it properly to the user, the product is perceived poorly. Maybe even cancelled.

If you write installers and your code is chugging along, installing all the bits properly, but your UI appears frozen, people assume the appliation has locked up. Same for data analysis or even web browsing. Feedback is vital.

We know this as an industry. We have UI specialists. We have user interface guidelines in larger companies. The look of a product is vital to it's success.

So, to be crystal clear, as an industry we know that a good UI is essential to a product's success.

So why don't we treat ourselves the same way?

I'm not suggesting we all apply for eXtreme makeovers, but I am suggesting that many people in the technology field give no thought to how they are seen or percieved.

I'm not talking about physical appearance, although that can be a part of it. There are many aspects to presenting yourself well.

Today I'm thinking about speaking well. Your ability to communicate clearly impacts your job, whether you are interviewing, pitching a project, or leading a daily meeting.

Many of us consider our technical jobs as crafts to be honed. How many of us realize that proper speaking just another tool in our toolbox? How many of us take time to hone that part of our craft?

How do you hone your craft as a speaker? One great way is ToastMasters. ToastMasters is an international organization dedicated to helping people learn how to communicate better. They present it more as public speaking but it's the same concept. The idea is to teach you how to present your ideas so they can be understood.

Even if you only attend your local ToastMasters for a few months you'll learn some important things.

There are people who work every week to improve themselves. They are honing their craft. (Are you?)

You'll learn the value of short learning exercises to improve yourself. (They don't read about talking. They don't talk about talking. They talk.)

Just listen to the feedback for each talk and you'll also pick up some valuable speaking tips. (Sounds like a code review, doesn't it?)

Lastly, let me point you to Alan Hoffler, a ToastMaster and also someone who's helped me with several presentations. He's started a blog with practical speaking examples and tips.

You can find his blog here.

So... when's the last time you polished your UI?

Enjoy!

Jared

posted at: 20:21 | path: | permanent link to this entry

A Rails IDE

I've not used it but it's based on Eclipse and sounds very interesting. They are looking for testers. Anyone interested?

Check out radrails.

It really is amazing how much mind share Rails is getting these days. If you haven't checked it out, you owe it to yourself to give it at least a cursory look.

Jared

posted at: 19:49 | path: | permanent link to this entry

Mon, 10 Oct 2005

Tests Rust

They really do. Think about it... when you first write automated tests, they work. They're cool and shiny. But then you get busy, so you don't run the tests everyday. Eventually, you don't run them every week. It's like the abandoned bicycle in the backyard.

Over time, the automated tests become something you pull inside to use at the end of your product cycle. They become release tests... at least, you hoped they would be. But something happened to those tests you left out in the rain. They don't run cleanly anymore. They've rusted.

What does it mean for a test to rust? In the best scenario they just squeak a lot. In the worst case, they won't run at all. But why?

First, the code being tested breaks. It happens. Developers are human. Since they aren't perfect errors occur. So you find dozens (or hundreds!) of breaks when you finally run the tests. Unfortunately, with that many failures, most people assume the tests are bad and ignore them.

Second, the tests and the code get out of synch. The two need to march in lockstep. If the test doesn't know what the code is doing, it can't test the response. So again we have massive numbers of failures that get ignored.

Finally, trust fades over time. If your tests haven't been telling the developers anything useful, why should they listen to them? Trust is earned over time, not tossed over the fence at the end of the cycle. During the end of cycle, when everyone is stressed and busy, then you run the tests. Even if the tests only have a small number of failures, the developers will ignore them.

The only way to keep your tests shiny and new is to use them. Run them.

How often should you run them? I'm glad you asked. :)

Assume your test has a basic value of V. I can't tell you what your tests value is. That depends on your product and your test.

But I can tell you that over time V can degrade. Every time your code is touched and the tests aren't run, you lose value. In fact, if a test run is R and a code change is C, the formula is (R/C)*V

You start with the basic value of the test but you'll lose value if you only run the test every 10 code changes. You'll lose more if you only run every 100.

So if your test has a value of 10 but you only run it every 10 times the code changes, you have an effective use of (1/10)*10 = 1. However, if you have a really simple test with a value of only 1 but you run it every time the code changes, it's value to you is (1/1)*1 = 1.

The only way to maximize the return on your testing investment is to run your tests as often as possible, preferably after every code change.

The best way to do that? Continuous Integration. Add software that will build and test your product every time your code changes. It's not as hard as you might think and the pay off is tremendous. There are lots of products available to help you out.

Don't spend all that time on your tests just to see them rust.

Jared

posted at: 23:56 | path: | permanent link to this entry

Sat, 08 Oct 2005

On sale at Amazon

Amazon seems to have messed up the pricing for several of the Pragmatic Programmer books and their loss can be your gain. :)

If you've been thinking about picking up a copy (or an extra copy!) of Ship It! you can pick it up this week-end for $14.25 instead of the normal price of $20.

Mike Clark's Pragmatic Project Automation, the CVS book, and the C# Unit testing book

Remember, Christmas is right around the corner and wouldn't any grandparent just love to find a copy or two of Ship It! under the tree?

Enjoy!

Jared

posted at: 12:22 | path: | permanent link to this entry

Fri, 07 Oct 2005

Some tools I use...

Sorry the blog went dark the last two weeks. Work's been very busy and we've had some sickness in the house... nothing serious, but nothing fun either. I thought a fun way to ramp back up would be to link to a few of the tools I've found useful recently and then add a few quick blog links.

Visual Thesaurus This tool was invaluable when we were writing Ship It! and I still find myself going back to it from time to time. In fact, I used it tonight. The interface is just amazing. They offer a free trial as well. Hit the URL and type in a word. After a few moments you'll see a visual representation of the words grouped by similar meanings. Invaluable when you're trying to figure out how to say something just right.

NVU is a great HTML editor. They bill themselves as "the complete web authoring system for Windows, Mac and Linux". I've only used it on Windows and Linux and it works great. I use it for any non-trivial HTML.

Dia is a program to draw diagrams. Reminds me of Visio. The Windows version is here.

The Gimp This is the a great (and free) image manipulation program. I'm no graphics guru so I can't speak to it's advanced features but it's great for the types of simple edits I need to do for presentations. It does take a lot of horsepower though... it's the reason I just upgraded my wife's box to one AMD's dual core chips!

Speaking of the dual core chips... wow! My desktop is a dual Opteron and my wife's dual core is just as responsive. If it weren't for the hassle of reinstalling everything, I'd probably sell my desktop and upgrade. I'm still amazed at how inexpensive her box was... at Best Buy no less. I'm waiting for the dual core laptops to start shipping. I've found press releases that say the laptops will show up in October.

As you've probably noticed, there are no code tools listed here today. Recently I've been working on several presentations and I haven't had any spare cycles for code. Hopefully that will change after Atlanta.

For those who've missed it, the Pragmatic Ajax book is in beta. I love the cover. If you're working with Ajax, buy the beta and tell the authors what you need. How often do you guys like Justin Gehtland writing to your spec?

Also, Jeffery Fredrick had a great a great blog entry called Ruby, Rails and Eclipse. (See? People read your blog!)

I'm going to try to post about how automated tests rust in a bit... but first I've got to go edit a few slides. :)

Enjoy!

Jared

posted at: 21:10 | path: | permanent link to this entry

Sun, 25 Sep 2005

The CruiseControl Quick Start Edition!

The CruiseControl team made a huge leap forward by releasing a quick start version of CC. (Okay, the team called it a "binary" version but I like Quick Start Edition better!) They bundled Jetty (a very cool Java servlet container) with their 2.3 release.

You can download the 2.3 binary release (found here), extract it, then start cruisecontrol.bat (or cruisecontrol.sh) to run CruiseControl on a sample project. The reporting engine is running as a part of CruiseControl. Just hit http://localhost:8080/cruisecontrol/ (after you're running CC of course) and you're viewing live build results less than a minute after your download. Not bad.

This should jump start anyone whose been thinking about trying out CruiseControl but didn't have time to come up to speed on the configuration and deployment.

A few suggestions to the CC team for future releases?

The Control Panel tab is present but isn't enabled. JMX is turned off. It should be on for the sample application to let people see what it can do.

The xsltlogpublisher (a publisher plugin) should have a sample XSL file that generates the same HTML as the JSP, eliminating the need for a servlet engine altogether. I started to tinker with that this evening but I don't know XSTL, I tend to create really ugly HTML, and realized that there are probably dozens of people who've already done this better than I ever could. I couldn't find anything on the web but I'll bet someone on the user's mailing list would submit a decent sample. Then the xsltlogpublisher can publish a nice HTML interface as it's default transform.

CruiseControl gets better every release! Thanks a lot guys!

Jared

posted at: 19:54 | path: | permanent link to this entry

Pop Quiz

I saw an interesting blog entry by Jimmy Nilsson this week and it made me stop and think.

The entry discusses a few current development topics and the buzz around each one, and I wondered how many people I knew would be familiar with each of the subjects. The people that I think would know are also the most effective and well-rounded developers I know.

How well read are you? Are you staying up to date on the latest developments outside of your own silo of work? (There's a blog entry in the whole silo idea... if time permits I'll write that one up in the next week.) Are you slowly becoming a Technical Idiot Savant or are you staying current in your field?

Here's Jimmy's blog entry: Language innovations aren't unimportant after all?

Before you think I'm just pointing fingers, I hadn't heard of one of the topics either! :)

Enjoy!

Jared

tw, Will and I got a nice interview printed in the October edition of Software Development Magazine. It's a page within a nice article by Mike Reilly titled The Proof Is Out There. It's a portion of the podcast interview we did with Mike a month or two ago. Last month's edition had a very favorable review of the book as well! -jrr

posted at: 00:06 | path: | permanent link to this entry

Mon, 19 Sep 2005

Ship It! enters it's second printing!

This probably isn't a huge event for established authors, but I'm enjoying it! I can't believe the first printing is already selling out. Our publishers are sending out the latest version of the book to the printers this week. The second printing will have a lot of corrected errata and an expanded "praise" page.

If you've reported a typo, thanks very much. An extra thanks goes out to Kim Shrier... you should moonlight as a copy editor! ;) I can't believe we all missed some of the stuff you caught!

If you haven't gotten a copy of the (ah-hem) historic first edition, time is running out! Order soon so that you can see all those typos for yourself! (kidding!)

Seriously though, if you bought the PDF version of the book, visit the Reship Ship It! page later in the week and you can download the latest version for free.

We'd like to thank everyone who bought, reviewed and/or blogged about Ship It! Thanks for the support! Will and I really appreciate it!

Jared

posted at: 21:14 | path: | permanent link to this entry

Speaking of Tracer Bullets...

I'll be talking about Tracer Bullets at the RTP SPIN (Software Process Improvement Network) on Thursday, September 22nd.

If you are in the area, drop in and say "Hi"! We'll be at EMC in RTP (62 T.W. Alexander Drive) from 10:20 until noon.

Jared

posted at: 21:14 | path: | permanent link to this entry

Building your own JDK?

I stumbled across this link today and I just have to say, all the ~real~ geeks are building their ~own~ JDKs! You're not one of those developers who lets someone else build their compilers for them are you?

It doesn't look trivial, but it's not insane either... how cool is that? Someone do this and let me know if it's as easy as it sounds!

Here's the link

Enjoy!

posted at: 21:14 | path: | permanent link to this entry

Sun, 18 Sep 2005

Subversion on Windows Quick Start guide

I've been preparing a presentation for an upcoming No Fluff Just Stuff conference about vital software tools. Of course, source code management will be discussed. However, given the very practical nature of the conference, I want to provide practical examples with the talk, so I put together a very short Subversion quick start guide. It's the basis for the live demo I'll give during the talk.

This tutorial doesn't try to teach you about good source code management practices or try to sell you on the concept of source code management. It shows you how to set up Subversion on your Windows box and then teaches some basic operations. The basic operations will work with Subversion on any platform. (Maybe I should break those out into a separate doc at some point?)

The tutorial can be found here

Please let me know if there's information you think should be added or some of the information doesn't make any sense to you. :)

Thanks!

Jared

posted at: 21:40 | path: | permanent link to this entry

Thu, 08 Sep 2005

Continuous Sin Looks Intriguing!

I saw a link to Sin today and I couldn't help but check it out! And I think I like it!

Get your minds out of the gutter everyone! Sin is a Continuous Integration product.

It's got two interesting ideas in it.

First, everyone pushes code to a branch. The Sin system itself compiles (and maybe runs test?) the new code, and after the new code is validated, it's automatically moved over to the "main branch". This means your main code tree can never be non-compiling. Most CI systems notify you when your code breaks and they want you to fix the problem. This one does that as well, but it doesn't promote the code to the production level until it sees that it's clean.

Very nice concept!

The other intriguing feature is that it's distributed. Each of the nodes that does the validating is stand alone. It uses SOAP to communicate between nodes and spread the work out. They claim it scales linearly with the hardware.

Again, a very nice idea!

However the Sin web page was very thin, so I'm asking the community... is anyone using Sin (the product, not the moral concept). ;) Does it really scale? Do you like it?

Let me know!

Jared

posted at: 20:43 | path: | permanent link to this entry

Tue, 06 Sep 2005

Microclimates and Software Development

Have you ever experienced a small microclimate? It's when you walk into the edge of a forest and feel the cool air the shade. Even a medium-sized tree can provide this affect. It's why people sit under trees... they like it there! :)

Something creates a microclimate when it affects the atmosphere in it's proximity independent of the rest of the region.

Merriam-Webster Online Dictionary defines a microclimate as the essentially uniform local climate of a usually small site or habitat.

What's your development microclimate?

Independent of the rest of your organization, are you tinkering with new technology? Are the guy who introduced Nunit tests to your team? When people talk to you over lunch, do you talk about Andy Hunt's latest podcast or Ted Neward's latest blog entry?

The question is not how well read you are but how far out do you limbs reach each day? Are you so engrossed in today's problems that you don't have the time to look around?

Here's a quick litmus test for you. If each software blog you read this week was a leaf, what kind of tree would you be? A tree that provides shade or a scraggly old hulk that looks half-dead?

Strive to be the person who picks up one or two new ideas each week. Ask people what they think about the ideas over lunch or try to implement the ideas during the day. You don't have to change the world today to make a big difference a year from now. Little changes add up!

What are some practical ways to get started?

Artima.com's Buzz forums is a great blog aggregator. I catch everyone from Martin Fowler to Andy Hunt.

The Buzz can be perused as sub-categories as well. They are .Net, Agile, Design, Java, Linux, MacOS, Open Source, PHP, Perl, Python, Ruby, Web, Windows, Wireless, and XML.

If you can't find one a category that applies to your work, then move to Artima's blog page. There you'll find people like Bruce Eckel and Michael Feathers.

Still haven't found what you're looking for? Then visit Technorati and type in your favorite author, speaker or topic. Find out who else is talking about the books, authors and practices that you are. Search on junit or Ruby on Rails to see whose talking about these topics.

The information you need is out there and it's accessible. The only question is whether or not you're going to go get it and generate a nice localized microclimate of best practices and interesting ideas. Or will you sit back, let the industry pass you by and have to say "Oh crap! My Job Went to India (And All I Got Was This Lousy Book).

;)

Jared


posted at: 21:41 | path: | permanent link to this entry

Mon, 05 Sep 2005

Blitzkrieg Testing in Action

On Tony Semana's blog we find a great example of Blitzkrieg testing in action. You can read about it here.

Here are a few quotes:

...we had rebuilt basic coverage of the existing features and planned release features prior to the start of the testing cycle, and a good picture of what needed to be accomplished when the application was built into our test environment. Our testing cycle was still very short and effective because we knew where to focus our manual tests, integration bugs were found and resolved quickly, and we added automated tests to cover many of the bugs found manually to address bug regression. In the end it allowed 3 of the 5 main project members, including myself, to keep vacations this week that were booked out months in advance.

and

This process captures a very effective way of implementing the practice of automated testing (in this case acceptance/integration testing) in an environment/project where none exists.

Enjoy!

Jared
Technorati Profile

posted at: 19:50 | path: | permanent link to this entry

Very Short JUnit Tutorial

I wrote a very short JUnit tutorial with developers in mind who are very competent, understand Java quite well, but haven't seen JUnit before. These people are smart but also very busy and probably won't take a few hours to investigate JUnit. I hope this can give them just enough information to get moving and let them see the potential. Feel free to forward it around.

If you like JUnit, there are lots of additional books and articles you can go to for more detailed information, like Pragmatic Unit Testing or the JUnit.org articles page.

The tutorial is located here.

Enjoy!

Jared

Thu, 01 Sep 2005

Keeping your back to the wall

One of the magazines I started reading recently is Fast Company. They have a good mix of articles in a wide mix of industries.

Fast Company recently published an article on Chrysler and how the company has traditionally done so well in a crisis and so poorly when times are good. The article is called "Keeping the Crisis in Chrysler".

Chrysler's current management has isolated three key points from the company has instinctively adopted in the tough times. Now they are trying to adopt the same attitudes, even in the boom times, to keep their edge. I think these points map rather well to the software space, so here are the points with my commentary. :)

We are all in this together
No matter how much the guy up the hall annoys you, he is really trying to ship great software too. He's probably not really trying to tank the company, it just feels that way to you sometimes. The disagreement you're having with him is probably really about direction or tactics, but you share a common goal. Once you realize that, it's easier to find common ground and work together.

Every nut and bolt counts-
I love this one. It's a variation on "Quality is Job One" or "the devil's in the details". The work you do every day adds up to create the products we ship. Software, and life, is cumulative. If you can't be bothered to turn out solid work today, don't be surprised if three months down the road, your entire product is shoddy. Don't gloss over that problem or tolerate broken windows. Fix it today.

Remember the driver
Our job is not to code or test software. It's to ship software! Never forget that someone will be using your product, running your code. Is your product running slow enough to bother you? Then remember Chrysler and fix it for your "driver". Is the GUI clunky? Is it only "good enough"? Work on it! Contact a co-worker for a second opinion. Make it great!

How would you try to instill each of the three points to your team mates? Or would you? Do you need to keep a sense of urgency alive to do your best work? Is it true that most people perform best with a deadline? Or are these just good principals to remember all the time?

Enjoy!

Jared

posted at: 16:40 | path: | permanent link to this entry

Tue, 30 Aug 2005

No such things as Best Practices, part two

In Ted's second post he didn't quite get my point, but I've re-read my earlier posts and it's probably my fault. I don't think I stated it very clearly.

"Best Practices" is ~not~ a term that originated with the software industry. We borrowed it.

Hit this Google link to see how many hits "best practices" -software gives you. I'm seeing 20,400,000. The first hit is about manufacturing best practices. The second is a company who walks companies through implementing best practices in general business environments.

I mentioned the previous posting to my wife and her first comment was "It's not a software term. It's a common term. They'll just confuse people".

Well, right.

Yes, the term has been abused. By if we choose to ditch the term and go with "useful practice", we've put yet another barrier (YAB?) between ourselves and our customers. We've introduced another term they don't know. We've done just a little bit more to mystify the priesthood of the programmer. We're using one more bit of jargon... don't we have enough jargon already? When your customer asks about best practices, will you tell him you don't use the word anymore or are we suggesting a secret society set of terms that we use when we are among the more enlightened people?

I firmly believe we should demystify our work, our processes, and our problems. One part of that is using terms our customers understand. And if a few luddites misuse the terms along the way, so be it.

Jared

posted at: 20:52 | path: | permanent link to this entry

Mon, 29 Aug 2005

Sample chapters posted at Artima, NFJS profile posted

FYI a sample chapter of Ship It! has been posted at Artima. If you've been wondering about the book, download the PDF and see if it speaks to you.

You can also visit our quotes page and what people like Mike Clark, Ernest Friedman-Hill (JavaRanch Sheriff), and others have to say.

Also, my No Fluff Just Stuff speaker's profile is now active... I guess they'll have to let me in now! ;) I need to clean up the description of the talks but the rest is good. The Charlotte event I was going to speak at has been cancelled, so I'll be in Atlanta instead. Reston, VA hasn't changed though.

Also, final note, Ted has replied to my earlier post on Best Practices. I'll try to speak to his comments tomorrow. :)

Jared

posted at: 19:51 | path: | permanent link to this entry

Fri, 26 Aug 2005

No such thing as best practices? Sure there are!

Ted Neward blogged this week about a topic that James Bach recently talked about... Ted said There is no such thing as "Best Practices": Context Matters

While I agree with their intent, I don't think I agree with what they said. Let me 'splain.

Here I'll quote Ted quoting James. (Feel free to quote me if you like!)

First, "There are no best practices. By this I mean there is no practice that is better than all other possible practices, regardless of the context. In other words, no matter what the practice and how valuable it may be in one context, I can destroy it by altering things about the situation surrounding the practice." James hits the nail on the head with this one: any practice, taken out of context, can easily be turned from "best practice" to a "worst practice" without too much difficulty.

They said "There are no best practices" and then they had to define the term... but they defined it wrong! A best practice isn't a required practice or a universally dominant practice. It's just one of the best ones. It's used quite often, but not everywhere and not always.

I do agree with what I think is their intent, although I wouldn't presume to speak for either of them. Many junior followers of any given software process tend to idolize the core practices of their process. The thought leaders, at least the good ones, in each process are saying "Experiment! Find what works! These core practices are a starting point, not a destination". But their more junior followers have found their molten idol and aren't moving one inch.

I think this comes down to a lot of what Andy and Dave have been saying about the Dreyfus Model of learning. The scale goes from one to five, with one being a rank novice and five being a wizard.

Stage One beginners ~need~ rules on a very visceral level. They can't exist without concrete rules because they don't know what they are doing. They aren't interested in learning about something, they just want to get something done. This group can't concieve of moving beyond the core practices.

In Stage Two we start to grab principals but without understanding why they are important or how to use them in context. Once a Stage Two developer finds a principal that works once, they are stuck on it! It works doggone it! Everyone should use it! It's a Best Practice! ;)

However, once we hit Stage Three, we start learning to ask questions. We start looking for reasons and understanding. We, like Spock, start to realize that logic is the beginning of wisdom, not the end of it! (Sorry for the obligatory Star Trek reference!)

Stage Four and Five do fine so we'll skip them here... their biggest problem is figuring out to communicate usefull knowledge to the Stage One and Two people.

Sadly, most people never make it to Stage Three. They find they are good enough to get by at Stage Two, so they stop searching and get productive. They know just enough to get by, or at least they think they do... but that's another topic.

Here's an example of a Best Practice abused. A few years ago I was at a user's group and ran into a guy who worked at a local XP shop. We were in a group of half a dozen people and the subject of software process came up. During the conversation it