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 came out that everyone in my shop didn't practice Pair Programming full time. I was the technical lead of my team and said that I thought Pair Programming was a great practice to be used as needed. It wasn't something I thought should be used full time in every situation.

Oh boy! My XP enamored friend didn't like that very much! He said things like if I hadn't done Pair Programming full time for at least two years, I wasn't qualified to make that statement, and he didn't understand how we thought we could ever ship quality software without Pair Programming, and many other similar things. I tried to excuse myself and move to another group, but he followed me, apparently sure that he argued me a big longer I'd see the light. This guy stayed on my trail for half an hour, until the speaker started. He then tried to corral me after the meeting. My other friends sat back and had a good laugh at my expense while I kept moving around the room all evening!

What's the point? My confused friend thought Pair Programming was a Best Practice as defined by James. I'd say that he had settled on a Required Practice, which in my mind is different.

I realize that James and Ted are trying to make a good point, that they are attacking blind adherence to ~any~ practice. And they are right! But let's not throw a perfectly good term just because a few zealots have abused it. They'll just grab the next term we choose and hijack that one too! The term Best Practices is accepted and understood by CEOs (at least mine), teachers, experts and novices. Let's just hammer in the context part.

What do you think?

Jared

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

Do Computers Dream?

If they do, these guys may have figured out what they dream about! ElectricSheep.org. Electric Sheep is a really cool screen saver that's been around for a while, but I finally saw it in action this week. It looked incredible, and then when I heard more of the story behind it, I had to install it. :)

I've shown it to a few people and everyone has been impressed. Several have already installed it themselves! So what's the big deal?

Electric Sheep is more than just a screen saver. Here's a blurb from their website:

Electric Sheep is a free, open source screen saver run by thousands of people all over the world. It can be installed on any ordinary PC or Mac. When these computers "sleep", the screen saver comes on and the computers communicate with each other by the internet to share the work of creating morphing abstract animations known as "sheep". The result is a collective "android dream", an homage to Philip K. Dick's novel Do Androids Dream of Electric Sheep.

Anyone watching one of these computers may vote for their favorite animations using the keyboard. The more popular sheep live longer and reproduce according to a genetic algorithm with mutation and cross-over. Hence the flock evolves to please its global audience.

Wow! Each computer running the screen saver helps to compute the next generation! So instead of running some CPU intensive OpenGL screensaver that won't render smoothly on your lowly video card, you run MPEGs! And you only have to generate a fraction of what you display.

So you get a free, open source even, gorgeuos screen saver that's also a distributed application. How cool is that? It may not be quite as useful as participating in some of the other distributed applications... but still it's very cool to watch!

Check out their samples page even if you don't plan on participating and picture this image, rotating and morphing, as ~your~ screensaver.

Enjoy!

Jared

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

Thu, 25 Aug 2005

Quick Ant tip

I was writing a short Ant script to generate the static HTML version of my blog, back everything up and then push it up via FTP to the hosting web server. The FTP task gave me a little trouble, so I'm passing the solution on in the hopes it will save someone else some time.

I know that Ant's FTP task is an optional task and requires the Apache Commons-Net jar to run. This is a known thing for me. So when I set everything up, I looked in Ant's lib folder and saw ant-commons-net.jar I thought "Great!" and kept going.

But somehow, ant-commons-net.jar is ~not~ the same as commons-net.jar. I gave up this evening, downloaded the official version, dropped it in my ant/lib folder and now FTP works. Why? I have no idea... if anyone knows why the Ant team is bundling a jar file with such a similar name, I'd love to know why!

Jared

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

Ajax is hot!

I use Technorati for much of my blog searches. Yes, it can be slow and it's not nearly as reliable as Google or Yahoo, but it works enough to keep me happy. Why? It's got a great UI for showing my saved searches (a "Watchlist") and it also shows me the top searches for each hour (which I find terribly interesting).

For the last several days, I've finally realized that among all the debate about Pat Robertson, Intelligent Design and Lance Armstrong, there has consistently been a single technical topic in the top ten.

Why is this significant? Because blogging isn't exclusively the realm of the technical anymore. The technorati have built the tools that allow the non-technical to blog and they now own the space. Religion, politics and current events rule most of the blogoshphere.

Except for Ajax.

As I write this Ajax is ranked number three in all searches. What is so compelling about Ajax that makes it so popular?

First, Ajax exists in the browser, not on the server. Your Ajax-enabled application can use Microsoft's Asp.NET, Sun's Java, or the latest greatest entry to the web space, Ruby on Rails. It doesn't matter what server-side technology you use, from VB to Perl to Python, you can take advantadge of Ajax. It extends existing technologies.

Next, Ajax makes your web application look fast. Fast like an installed desktop application, not fast like a souped up web server. Ajax fools your users into thinking nothing is happening while it slips off to fetch data in the background. We all know that users waste lots of CPU cycles just reading the screen. Ajax just puts that wasted time to work!

Third, Google made Ajax hot. When they rolled out Google Maps, using Ajax technology, every non-technical software manager in the world believed that Ajax could make their application scale too. They didn't realize that Ajax only helps stretch your scalability by downloading data in the background where the user can't see how slow everything gets when your application is under a heavy load. Google has a thousands of machines that help their applications scale with or without Ajax.

So it's cross-language, makes your web applications blazingly fast, and has been proven in the field by Google.

All in all, those aren't bad reasons to be popular.

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

Wed, 24 Aug 2005

Types of tests

Jeffery Fredrick posted a great blog entry on a comment by Michael Feathers called Rules for Unit Tests. It's a great set of litmus tests you can apply to your so-called unit tests and see if they really are unit tests.

So what other types of tests are there? I'm glad you asked! ;)

Taken from Ship It!, pages 43 and 44.

There are many different kinds of testing; each one is targeted at identifying a different kind of problem.

Unit tests are designed to test your individual class or object. They are stand-alone, and generally require no other classes or objects to run. Their sole purpose in life is to validate the proper operation of the logic within a single unit of code.

Functional tests are written to test your entire product's proper operation (or function). These tests can address your entire product or a major subsystem within a product. They test many objects within the system.

Performance tests measure how fast your product (or a critical subsystem) can run. Without these tests, you can't tell whether a code change has improved or degraded your product's response time (unless you are really good with a stopwatch!).

Load tests simulate how your product would perform with a large load on it, either from a large number of clients or from a set of power users (or both!). Again, without this type of test, you can't objectively tell if your code base has been improved or degraded.

Smoke tests are lightweight tests and must be carefully written to exercise key portions of your product. You would use smoke tests because they run fast but still exercise a relevant portion of your product. The basic idea is to run your product to see if it "smokes," i.e., fails when you invoke basic functions. Smoke tests are very good to use with your Continuous Integration system (see Practice 4, Build Automatically, on page 30) because they're fast. During your product's life cycle, the smoke tests that you actively run will probably rotate. Your smoke test suite targets areas of active development or known bugs.

Integration tests look at how the various pieces of your product lines work together. They can span many products: sometimes your products and sometimes the third-party products you use. For instance, various databases used by your product can be exercised as part of your integration tests. You want these tests to cross product boundaries. Integration tests are often used to validate new versions of the components your product depends on, such as databases. If a new version of your favorite database comes out, you will want to know if your product can run with it. A suite of tests that exercise functionality all the way down to the database should answer the question of functionality for you and also give you a quick look at your performance with the new components.

Mock client testing is used to create tests from your client's point of view. A mock client test tries to reproduce common usage scenarios for your product, ensuring that the product meets minimum functional specifications. This type of testing can be very effective for getting essential testing coverage in place to cover the most commonly used code paths.

So what's the best and most important type of test? The type that are run frequently!

Enjoy!

Jared

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

Tue, 23 Aug 2005

The Great Rails Blog-off

It's largely died down now but there was a great bit of back-and-forth about Rails either being overhyped or great stuff. Justin Gehtland, Ted Neward, Dion Almaer and Glenn Vanderburg all jumped in and commented. I'm sure there are more posts out there I missed!

This is more than a great opportunity to watch a few folks fire friendly volleys back and forth. Read the threads and learn a little about what these guys value in a web framework. What do you they see in Rails that they don't see anywhere else? Or everywhere else? :) These are all very smarty guys. What do they value?

I thought about putting these in chronological order, but instead I sorted by person. Enjoy!

Ted gets things started
http://blogs.tedneward.com/2005/08/13/NFJS+Austin+And+Rails.aspx
http://blogs.tedneward.com/2005/08/18/More+On+Rails.aspx
http://blogs.tedneward.com/2005/08/20/Rails+Finis.aspx
 
Justin's posts
ttp://www.relevancellc.com/blogs/?p=60
http://www.relevancellc.com/blogs/?p=61
 
Dion's entries
http://www.almaer.com/blog/archives/001027.html
http://www.almaer.com/blog/archives/001031.html


Glenn's
http://www.vanderburg.org/Blog/Software/Development/ted_on_rails.rdoc

Of course nobody mentioned what I think is the best part of Rails. It's a complete, tip-to-tip Tracer Bullet Development process. Rails creates an entire, working system for you that you can add to as you build your application... and people are loving it!

Jared

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

International book reviews

Ship It!, thanks to the Pragmatic Programmer guys and O'Reilly, is selling all around the world. And because I'm a first time author and apparently have too much free time, I look for (and sometimes find) reviews in other languages.

Since I can't read Japanese or French very well, I rely on the Google Language Tools to do my translations for me. Of course, Google provides more humour than real information. :) I get a good feel for what the review says, but it's very entertaining to see how the translations get warped.

For instance, this this page talks about Tracer Bullet Development. With the magic of Google however, the page now says:

The eyeball is the TBD which is not the TDD. With saying, they are not eye new forcing ones separately. The mark which " tries collecting old method, to modernism " it is technique.

I'm pretty sure the original is saying the Tracer Bullet Development isn't Test Driven Development, and is in fact not a new technique at all, but a collection of existing techniques. Maybe...

But I like the way Google said it better. :)

I also found a Frech review. Here is the translation.

Here's an Italian review by Filippo Diotalevi with a Googlized translation. Fortunately for me, Filippo has an English version on his personal site.

And finally, here's another classic

Don't you think? it is appealing, you try to try reading by all means.

What can I say? :) I agree.

Jared

UPDATE: sorry for the edits... I was trying to get this blog post done (this morning) in time to get my daughter to school and before I went to my regular job. :( Next time I'll just hold the post until I get the URLs closer to right! -jrr

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

Ship It! shirt winners...

I got a note today from Hiroshi Sakurai, one of our shirt contest winners. I loved his note:

Hi Jared

I received ShipIt! T-shirt yesterday.
It is cool!

Today is the first day to wear the T-shirt to work.
I can't see what it says on my back while wearing it, but I love it.

Thanks fot the nice T-shirt

So we decided to post a better version of the shirt! :) With this new and improved shirt you can wear it ~and~ read it at the same time! It still has the Key Practices on the back of the shirt, but it also has them printed upside down on the front.

Have a great day!

Jared

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

Mon, 22 Aug 2005

Java code coverage: Cobertura 1.6 released

I was fortunate enough to be involved with getting the JCoverage fork (called Cobertura) launched. Although my role was primarily managerial, not technical, I still enjoy watching it grow. SourceForge tells me that the project has nearly 250,000 "Project Web Hits". Today Mark Doliner and company (Grzegorz Lukasik, Jeremy Thomerson and others) released version 1.6 of Cobertura.

If you are writing tests, you need to know what code is being excercised and what code is being missed. A code coverage tool should be a part of your toolbox. If you've never used one before, you may be very surprised at what it shows you.

Here's a sample Cobertura report. The web site has sample Ant tasks to get you started quickly. Here are a few of the Cobertura features:

• Runs from Ant or the command line
• Instruments Java bytecode after it has been compiled
• Generates reports in HTML or XML
• Shows percent of lines coveraged and branches coveraged for each class, package, and for the overall project
• Shows the McCabe cyclomatic code complexity of each class, and the average cyclomatic code complexity for each package, and for the overall product
• Sorts HTML results by class name, percent of lines covered, percent of branches covered, etc in ascending or decending order

Of course the project is using CruiseControl, under multiple JDKs! See here.

If you're still not sure you want to tackle Java code coverage, read Measure test coverage with Cobertura by Elliotte Rusty Harold, an article on IBM's developerWorks site.

Enjoy!

Jared

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

Sun, 21 Aug 2005

Python on Rails?

I just saw a post on Slashdot about Subway. It was a comment, not a complete story... however it sounds interesting. From the Subway web page:

The Subway project aims to create a Web development stack combining the ideas and spirit of Ruby on Rails with a comprehensive suite of prewritten Python web libraries and tools.

So, do you know Python but just been itching to play with Rails? Looks like you have an easy way to get started! Check out Subway and let the rest of us know what you think.

Jared

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

Another Rails hint

You may recall my post from a few days about about configuring Rails on Windows. Well, three other people I know ran into a second problem. It's trivial once it's solved but it can be quite frustrating.

In a nutshell, add the following line to your database.yml
port: 3306

if you run into this error:
No connection could be made because the target machine actively refused it. - connect(2)

Sri goes into a great more detail (but I've included enough detail that you can find the post on Google. ;)

Check out Sri's post here.

Jared

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

Thu, 18 Aug 2005

One Test per Feature?

Here's a practical way to get your Blitzkrieg Testing rolling. It comes from Johanna Rothman's blog, Managing Product Development.

Here's a short excerpt:

Not every product has smoke tests (a series of tests you can run after each build to make sure the product works well enough to continue development and testing). Smoke tests provide early feedback to developers about their work. So, for the last several years, I've been suggesting to my clients that as they develop a feature, they include one short automated test for that feature in the smoke test. This test allows the developers to know their changes didn't break the product.

...

This isn't optimal, but the people in the group are becoming accustomed to receiving feedback about their work. With the way they'd been implementing "smoke" tests, they prevented themselves from seeing any feedback about their work. This technique might help.

Sounds like another good technique to put in your toolbox...

Enjoy!

Jared

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

Wed, 17 Aug 2005

Continuous Integration goodness

I have two bits of CI news to pass along.

First, CruiseControl.NET is almost at version 1.0 Those of you who don't like the Java/Ant integration of the original CruiseControl for your C++ projects have a great alternative in CC.NET. Here's Mike Robert's post on the release. And here are the release notes. Native msbuild support!

Second, Jeffery Fredrick, CruiseControl guru, maintainer, etc, has a blog entry talking about the next release of CruiseControl ~and~ the third party tools that are spring up all over the place. :) That's the sign of a healthy project!

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

Tue, 16 Aug 2005

I'm speaking at No Fluff Just Stuff!

I've been corresponding with Jay Zimmerman about the NFJS tour and it looks like I'll get a shot at speaking at two events! I'll be a trial speaker in Reston, Virginia October 28th-30th and in Charlotte, NC November 4th-6th. If people like me I'll get to come back again. I'm very pleased to have the opportunity and being in the same event as people like Dave Thomas... well, hopefully I won't bring the average down too far! ;)

I'll be talking about (big surprise!) the three major sections of Ship It!. Each of the major sections in the poster of Key Practices will be a session. Techniqes, Infrastructure and Techniques.

Here are the short version of each session. If you look over them and see room for improvement, please let me know! ;) I'll take all the help I can get. (grin).

Software Tools That Make Life Easier

• Do you spend more time fighting your tools than writing code?
• Do you avoid merging your code with your teammates because of “Integration Hell”?
• Do the same bugs keep sneaking back into your product?
• Do your builds depend on the roll of the dice?

A good set of infrastructure tools can go a long way toward smoothing out these and other problems. Come see how to make your toolset work seamlessly in the background so you can Just Work. We'll cover source code management (SCM), build scripts, automated test harnesses, automatic builds, feature tracking and issue tracking.

As part of the session, I intend to install Subversion, create a project, and then add code for the SCM section ... just to obliterate the "it takes too much time to set up and use" argument. For build scripts, we'll add an Ant script. Let's throw in a few JUnits to demonstrate test automation, and then I'll put it all together in CruiseControl. The live demo will include breaking the build, then breaking the JUnit test, and then finally fixing it and seeing it all work.

Software Development Techniques

Throughout our software careers we learn habits from our coworkers, from books we've read, and occasionally, from conferences we attend. Much of our competence comes from the tips and tricks we pick up as we go. In this session, learn five of the techniques I've borrowed along the way. We'll discuss The List, code reviews, code change notifications, daily meetings, and tech leads. These techniques are often abused, but when used properly they can make a huge difference in how you develop software. Take this opportunity to add these practices to your toolkit.

Pragmatic Tracer Bullets

Are your product designs hit or miss? Do you have trouble building a loosely coupled system? Is your code incestuous? Refactoring not an option with your code base? Tracer Bullets help keep your project out of the fire. Tracer Bullet Development:

• helps you create great software
• lends itself to an iterative cycle
• can be used for demos early and often
• is easily refactored
• allows your teams to work in parallel
• makes a very testable system

Tracer Bullets can coexist with nearly any other development methodology. In this session we'll write some basic Tracer Bullets in Java. Come see how easy it is!

Have fun!

Jared

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

Ergo tip of the day

I've had problems with my upper back and shoulder area for years. I've had a gradually worsening problem with a muscle that cramps or seizes. The muscular lockups have been at times spread into the shoulder, the other side of my back, etc. I've been in physical therapy, on various meds, ergo chairs, keyboards, workstations, track balls, etc, all to no effect. Various treatments could decrease the problem but not eliminate it.

I think I've finally found the problem and it's so annoyingly simple... I've turned down my mouse acceleration. I've slowed down my mouse speed. I'm one of those people who have their mouse accelleration turned all the way up. The only thing that moved was my wrist... the rest of my arm and shoulder stayed locked in position. Over time, this becomes a Really Bad Thing.

The earliest I can recall having this problem was before my oldest daughter was born and she just turned seven. I think this has been going on for nearly a decade now. In that time I've seen doctors, PTs, chiropractors, massage therapists, and ergonomic specialists.

Now, instead of keeping my shoulder locked in position, I have to move the mouse to one side of my desk, then pick it up and move it back to the other side and move it a bit more to get the cursor from one side of the screen to the other. And at home I've got dual monitors, so I have to move even more. This constant exercise seems to be just what I needed! And it really hasn't slowed me down on the computer.

And yes, I've tried the left handed track ball as well, but it did no good. I suspect the exercise of picking up the mouse and moving it left and right is playing a major role. :) Isn't this sad?

I'm sharing this in hopes it will help someone else out. High mouse speeds are great in video games (UT anyone?) and they make you slightly more productive, but over time it can cause real problems.

Jared

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

Mon, 15 Aug 2005

Tomcat's not ready for primetime yet you say?

I am always hearing someone talking about Tomcat not being able to handle production work loads, etc. I've pointed out (over and over) examples of Tomcat working fine in a production environment. The last company I worked at (a small biotech) had a six figure software package that ran on Tomcat.

This evening I saw a very interesting blog entry. It seems that EBay is looking very hard at Tomcat... perhaps even decided to switch to Tomcat.

Here's the link.

You tell me? How's Tomcat looking these days? ;)

Jared

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

The Art of Work

Fast Company has a good article this month called The Art of Work. The article is about Mihaly Csikszentmihalyi's study into what he calls "flow."

What is flow? Mihaly describes flow this way: "It is what the sailor holding a tight course feels when the wind whips through her hair....It is what a painter feels when the colors on the canvas begin to set up a magnetic tension with each other, and a new thing, a living form, takes shape...."

It's what we are enjoying when we are writing code, creating a new thing, forgetting time, skipping meals, and losing ourselves competely in our work. It's a great feeling, but it's also a very productive place to be. Apparently companies are taking great interest in Mihaly's work. They want to make their workplaces conducive to flow. Flowing employees are productive employees and that makes the company more money... it also helps the employess enjoy their jobs more. :)

To quote the Fast Company article:
In the past few years, however, many major companies, including Microsoft, Ericsson, Patagonia, and Toyota have realized that being able to control and harness this feeling is the holy grail for any manager -- or even any individual -- seeking a more productive and satisfying work experience.

Although Will and I don't call it "flow" in Ship It! we do talk about the team's need for a tech lead that insulates them from interruptions. Will and I talk about it like this:

Insulate the Team from External Distractions
You're in the middle of an intricate project. You've been "in the groove" all morning, making wonderful progress when one of the sales critters scampers in to ask a question about the next release and completely blows your train of thought. Annoys you just to read the situation, doesn't it? It's not just you; everyone works better without interruptions. In fact, researchers say that up to 40 percent of your workday can be lost to interruptions. That's like going home after working less than five hours! Scientists have even named the phenomenon: cognitive overload. Knowing this, the tech lead must make every effort to keep the team working without interruptions. A great way to do this is to use the tech lead as the point of contact for the developers. Always let the tech lead buffer the interruptions, whether they are from the IT staff or the stakeholders.

Constant interruptions are bad but so is isolation. Make sure you are getting the information and interactions you need to stay on track. Keep trying to move back and forth until you find the balance for yourself. You'll know it when you get there.

Jared

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

Sun, 14 Aug 2005

Blog technical issues

I had a group of blog source files get their date time stamps reset tonight. I think I restored it all from a backup and reset the date time with the touch command, but if your blog aggreator thinks I'm spamming you, I aplogize. :(

FYI, I had a Linux box behaving strangely so I bounced it. Apparently the OS hadn't run flushed the disk buffers for a week! I've ~never~ had Linux do this before and it's running on older hardware, so I suspect something on the disk or motherboard is getting flakey, but a week!!? Wow! I lost a ton of Wiki entries but all the blog entries were backed up.

:(

I gotta break down and buy one of those Mac Minis....

Jared

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

Rails with MySql hint

If you've used MySql before, this is just tribal knowledge, but if you're trying out Rails for the first time, you might encounter this. I know two people who encountered the situation this week, so I'm posting it here.

MySql has all networking turned off by default. This is a security measure that makes your MySql much safer from network attacks, but also from your own network use. :) So, if you see this error message:

Errno::ECONNREFUSED (No connection could be made because the target machine actively refused it. - connect(2)): 
    c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.11.1/lib/active_record/vendor/mysql411.rb:47:in `initialize' 
    c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.11.1/lib/active_record/vendor/mysql411.rb:47:in `new' 
    c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.11.1/lib/active_record/vendor/mysql411.rb:47:in `real_connect' 
    c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.11.1/lib/active_record/connection_adapters/mysql_adapter.rb:39:in `mysql_connection'

In /etc/mysql/my.cnf find skip-networking. Comment it out (by putting a # at the beginning of the line).

Rail on!

Jared

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

Test Driven Refactoring

This is something that people have probably been doing for years, but I haven't seen it named and I've found it's easier to remember something with a "name", so TDR it is. :)

If you are a developer or tester trying to get an automated test suite 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 testing framework. It's not impossible to test "untestable" code, but the effort involved in test creation and maintainence 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 5th item. Not only is this very difficult for someone else to understand and maintain, 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 hit the moon on your first attempt. Shoot for a simple pass that exercises basic functionality.

Second, write using some framework (JUnit, MBUnit, whatever). Make the test go as far as you can. When you get stuck, what's the least amount you can add and 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 "boil the ocean" 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 from developers, testers and even managers once you've got a basic automation suite in place.

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

Test Driven Development is faster than test after development.

Here's an interesting idea that makes a lot of sense. Keith Ray's blog entry on the subject is insightful, and it has a nice description of what TDD actually is.

Having an automatable test suite up front makes a huge difference in how quickly you can get everything working ~right~ and how fast you can make major changes later. If you've never tried TDD, try it out with a small project. It's amazing how much code worked almost (but not quite) the way you thought it did.

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

Wal-mart has Ship It! in stock!

Although Amazon still doesn't realize that our book is in their warehouse, Wal-Mart finally has the book listed as in stock and orderable! Since it's our first book, I guess I tend to watch things like this closer than most authors. :)

Here's the link

Although the book has been selling on the Pragmatic Programmer site for nearly a month, it's nice to see it starting to trickle out into the traditional channels...

Now how long before I can find a copy in a local brick-n-mortar bookstore....

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

Ship It stuff
I've set up an online store at Cafe Press with a few bits of Ship It! stuff. There are a few shirts, some coffee mugs, etc. There is also a poster version of the Ship It poster.

Check out the online store and let me know what you think.

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

Lisp versus Erlang

I got this note from Will Gwaltney and it was too good not to pass along!

This guy wrote a poker server in Common Lisp, then switched over to Erlang because of its better performance and feature set. His server can now handle 27,000 simultaneous poker games *on his Powerbook*! Note that he doesn't have the web front end in place yet, but still! He also gets "load balancing, fault tolerance, failover, a database that lets me store objects without writing a lot of code, etc." for free in Erlang.

Several lessons here:

1. The old "Golden Hammer" trap ("If all you have is a hammer, everything looks like a nail"). Don't let your love for a certain technology (no matter how good it's been to you in the past) blind you to its inappropriateness *for a specific task*.

2. Open source *does* do the job. Erlang was developed by at the Ericsson Computer Science Laboratory a number of years ago. Even though open source, it's got the backing of a big company. They're motivated to make is as good as it can possibly be, because they use it themselves.

This link is for the original story.

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

Continuous Integration... Why Bother?

As Ship It! is starting to trickle out into the world, we are beginning to get feedback from readers around the world. As we hear from you about the topics in the book we'll try to post some of the more interesting replies to shine more light on some (hopefully) interesting topics.

M. Fridental asked some questions about our justification for using a Continuous Integration system.

One of the reasons we use a CI system to catch compile problems quickly. M. pointed out that the nightly or weekly builds would catch the same errors, and he's correct.

(The problems) all will be detected during the next release (say, in two weeks), but CI can detect it quicker (say, in two hours). One must decide for himself if the advantage of quick bug reports covers extra costs of creating and supporting separate build environment.

True, but if you've got a lot of code changes during those two weeks you can waste a lot of time running down the problems. The CI system isolates each code change so that you don't have that pain. Most people I've worked with think it's just a part of development, but after a few months of running with a CI system, they can't imagine working without one. I guess that's where I'm at today. I truly can't imagine trying to work without a CI system in the background.

Problems can also be found and fixed by the developer who changed the code. Most CI systems will send mail to all the developers who've changed the code since the last good build.

Haven't we all tried to fix someone else's code at one time or another? It's not that you can't fix it. It's that the developer who wrote the code can usually fix it faster than you can. It saves time.

Last point: in a weekly build, who runs down the errors? Is it the new guy in the shop doesn't know the code well enough to fix the problems? You might dump it on the new guy so he can learn, but what you're really doing is giving him the job you don't want to do yourself.

However, M. Fridental liked what we had to say about using the CI system to run the project's tests.

this testing argument is probably the strongest one for using CI. I must remind my colleagues every week to run test cases more often. With CI I can determine myself how often test cases will run.

If the CI system is running your tests every time the code changes, then functional breaks can be fixed very quickly. If you wait for the end of the week to run a test suite, how do you figure out which change broke the test? You waste more time code diving! Use a CI system and have the changes to your code isolated.

Isolating databases

Eric Starr in Charlotte, North Carolina had a few questions about database isolation...

I have a question about Chapter 1 Develop in a Sandbox (from Ship It!).

From Page 16: "That may sound easy enough, especially in terms of isolating source code (see Practice 2, Manage Assets,, on page 19), but the real trick is to remember that it applies to all resources: source code, database instances, web services on which you depend, and so on."

I understand and practice isolating source code. I have never thought about isolating the database instance for each individual developer What I am curious about is how practical this has been for you given the frequency of database schema changes during the beginning of a project? How do you manage schema changes across a development team when each user has their own instance of the database? Do you put the schema meta data in SCM?

First, I always insist on having a tool that creates the schema. Usually this means a Java program that can read in a schema definition (even if it's just straight SQL) and feeds it to the database... but it could also be Perl, Ruby, whatever. Then the tool and the schema definition can be stored in your Source Code Management system (SCM). This means we can always reproduce our schema on any machine that has the database installed on it by just running the tool. We usually just write something simple (JDBC connections with basic error handling).

Second, because the entire tool can be checked into the SCM software, we manage the schema just like code. When a change is made, let everyone know to update their schema.

Along the same lines, we try to have a script to load minimal test data as well. This way every developer can have a "real" database for coding against without worrying about messing up anyone else's data.

Do you typically use a local instance of the database or a remote instance?

I try to have a local install. Most vendors will provide cheap development licenses... or you can use MySql, or Postgres which are free for everyone. Even if you can't go production with one of the free databases, if you are careful with your SQL, you can code cross platform queries. I've found it to be worth the extra work to have a complete database available to every developer and tester.

Do you typically determine which database to hit using an environment variable and a properties file or some other way?

Yup. I wrote a JDBC connection pool a few years back and I always use that one. :) But the idea is simple... have a Java Property file with your database information in it. Connection URL, usernames, etc. It makes it trivial to switch out databases.

Do you typically populate the database with test data (and remove the test data) using scripts (possibly useful for automated testing so that your data is at a steady/known state at the beginning of every test cycle...you may answer this one later when I get to the chapter about automated testing)?

Yes. In the past I've used Continuous Integration system with an Ant script that would wipe a database, load the test data and then run the tests. If you have the schema creation tool mentioned earlier, this becomes easy to do.

These questions cover the "how" but not the "why" of database isolation. The biggest reason is if everyone shares a database and some of the code you write modifies the data, how does anyone ever know the source of a problem? Is it my code or did Jim corrupt the data again? The last query ran slowly. Did I code some inefficient SQL or was Sue swamping the database again? Isolated instances help you to quickly recognize and understand problems when they occur.

The basic idea is to keep every resource isolated. You will spend more time up front building some basic tools (like the SQL schema creation tool and the data load tool), but I've found that these tools to be worth their weight in gold. They can be re-used across projects and make many useful automation tasks trivial.

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

Continuous Integration in the enterprise environment

Have you wanted to try out Continuous Integration but were afraid it wouldn't scale to your environment? Then this story is for you!

Will Gwaltney and I helped to introduce and roll out CruiseControl (a Java CI system) at SAS (the world's largest privately owned software company). Because we have five million lines of Java code and nearly 300 projects, some people were sure that a CI system would swamp the build infrastructure.

It did take a lot of resources to start up the system, but we dodged that by staggering the project startups.

Once CC was up and running, the load was amazingly light. Even with nearly 1,000 developers involved, we never had a situation that swamped the build environment. People being people, everyone finished up their work at a slightly different time, and that staggered the load.

Read more about CruiseControl at SAS at Mike Clark's blog.

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

So what is this blog about anyway?

I've had a team wide project weblog at work for about a year (a plog) and a company wide weblog (a blog) for about six months. This public blog is the next step. Will Gwaltney and I recently published our first book Ship It! A Practical Guide to Successful Software Projects, so this seemed to be the right time to get a public blog rolling.

I intend to repost a number of my work blog entries (with slight retooling) in the next few weeks, but after that the volume should drop back considerably.

So who am I? I've worked as a developer, a tester and a manager at companies as large as SAS and IBM and as small as a three person startup. During that time I've been entry level, director level and on a few occasions, a consultant. I started writing software in early high school on a Ti994/A and have enjoyed tinkering with technology ever since. I've built a few computers, water cooled a few, but these days having two daughters keeps me too busy to tinker with radiators in the computer room.

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

Just get something running!

Imperfect tests, run frequently, are much better than perfect tests that are never written at all. -Martin Fowler

Kind of says it all, doesn't it? Get it out there and get it running, perfect or not... fix it, perfect it, whatever, later (if you decide it even needs fixing!).

Momentum is a powerful concept... and you'll get more benefit from the first "Hello World" automated test than you ever realized.

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

Measure something to improve it

I've been telling a story for years but couldn't remember where I originally read it. I stumbled across it recently so I thought I'd post the story. It's an interesting insight into human nature.

A manufacturing facility wanted to improve production, so they put people with clipboards on the manufacturing floor to record information.

The first thing they did was turn up the lights. Sure enough, production went up!

The next thing they tried was dimming the lights. Production went up again!

Ignoring their choice of environmental factors to tinker with (the lights?), the lesson is interesting. Production increased because people realized that someone cared. The line worker realized that their work was important. I'm not just a cog in a big machine they thought. Someone is watching my work! As a result, production increased.

Apparently this is called the Hawthorne effect (Wikipedia link). I also saw it cited in Peopleware recently.

Of course, this also leads one to consider the old statement "Be careful what you measure because that's what you'll get."

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

How do you track your source code?

I've had a few people ask me why we included something as basic as source code control in our book. Doesn't everybody use CVS or Subversion they ask. Actually, no, a lot of teams don't use anything.

This conversation was posted on the web...(Google finds ~everything~!)... the guys involved were discussing what their manager wants them to use for source code management.

Apparently they sent the source code out in email... that way if the disk crashes, you can just poll your email from another machine. Here's the link:

http://tunes.org/~nef/logs/haskell/05.02.13

......
20:30:05 The most useful part is the extremely clear explanations of what can happen if you don't do the things it recommends.
20:30:41 "if your hard drive died right this instant, how much work would you lose? if it's more than a day of work, you need to use your SCM better."
20:31:10 SCM?
20:31:16 source code management
...
20:32:07 Anyway, I've been fighting to put everything we change into darcs so that we can instantly rebuild our projects, but I've gotten some opposition.
20:32:12 Ha! Mailinglist is a good idea.
20:32:40 on what grounds?
20:32:45 You send all your code to the mailing list. If your disk crashes you can retrieve your code back from the mailing list.
20:32:54 shapr: What do you use at the moment?
20:33:00 Opposition on the grounds that it's an extra step that just wastes time.
20:33:03 (If anything.)
20:33:09 This is also a reason why when people ask "what is a good editor" I reply "outlook express".

Wow...

First, you keep no history of your changes. A good source code management system (see this page for a list of products) will track the history of a file. Who changed this file? When? Why?

Second, your changes and Mike's changes don't get merged in together automatically. Your changes just overwrite Mikes. :) Sorry Mike! A real versioning system will either lock the file so you and Mike can't edit the file at the same time or it will merge in the changes.

Third, security... are you sending out the source code for your company through email? By the way, how much source do you have? Can you send it all or does that take too long?

Given that products like CVS and Subversion are free and they integrate almost every editor on the planet, there really isn't a good reason to not use source code management software! Keep fighting the good fight guys!

So what can these guys do? I'd suggest trying to show the benefits of source code control.

1. Install Subversion (or CVS) on an existing machine. Preferably not your desktop, but if that's the only choice, use a desktop.
2. Start using it yourself everyday. Get used to the tool and learn to use it. Show that it's not going to slow you down.
3. Show it to your coworkers. Show them how it is tracking your changes, how it can handle collisions, etc.
4. Finally, show it to the boss. Have a week's worth of changes to the code so they can see the merges. Show them how you can pull out last Tuesday's work on demand

It's possible that the boss still won't get on board... if so, I'd run a CVS or Subversion box in the corner and not tell anyone (assuming there is not direct order to NOT do it). :) It's not a radical departure that will hurt anything. Many an obsinate boss will allow something just because the developers want it. Don't underestimate your ability to introduce change.

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

Coding to an Interface by Erich Gamma
I saw two interviews with Erich Gamma today at Artima.com, but the second interview caught my eye. (Okay, they both caught my eye, but I blogged on the first article at work, so I'm trying to do something different!)

The summary reads:

In this interview, Erich Gamma, co-author of the landmark book, Design Patterns, talks with Bill Venners about two design principles: program to an interface, not an implementation, and favor object composition over class inheritance.

What caught my attention? Coding to an interface is a major part of Tracer Bullet Development, which is a major part of Ship It.

One of the big ways we've used Tracer Bullet Development is by defining the interfaces (or APIs) between major parts of your system. That's the design by contract between the developers in each section.

As long as the interface doesn't change, the developers in a given area can go crazy with retooling or refactoring. The developers above and below shouldn't know that anything changed.

These interfaces also give you a great place to code your automated test suites. By testing at the API level you (1) ensure the entire product area still works properly and (2) validate that the code works as intended instead of "working at coded".

There is an entire chapter on Tracer Bullets in Ship It, but this should give you a basic idea... it's nice to see Erich's article and know that we lined up with a smart guy! :)

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

Automated Linux Kernel Testing At IBM
IBM is sponsoring automated tests of the Linux kernel. The Slashdot post is here .

This is a step in the right direction, but a little short of what a complete Continuous Integration system can provide. The IBM system runs within 15 minutes of a release (see here) which is ~awesome~. It would be nice to have a system that also watchs the source code management software (CVS or Subversion) as well. (I don't intend this to be a criticism of the great work done by the IBM team, but rather educational about Continuus Integration in general).

First, your complete CI system only rebuilds when the code changes, and you only incur the overhead of a test run when you need a test run. Running nightly is often a waste of time for most products.

Second, with a Continuous Integration system, you isolate the changes to the code. If ten developers push code on Thursday and the tests break, who fixes them? Or rather, who goes exploring through the code and the tests to figure out whose changes broke the tests?

There are lots of projects, open source and commercial, that you can use for this type of work. I'm a big fan of CruiseControl, which is a Java implementation. See the Resouces page for more Continuous Integration systems.

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

Fri, 12 Aug 2005

Continuous Integration question

We recieved a question from Jerome about how Continuous Integration works in the real world.

Regarding 'Continuous Integration' : building our application takes about than half an hour. Your book mention that after each commit, the Continuous integration system should start a build to make sure the commit didn't break it. I wished your book would mention if this would be a problem : starting a long build after each commit. What would happen if several commits occur during a build ?

No problem at all Jerome! In fact, all the CI systems I've every used plan on this happening. The system will store up the changes that are committed during the current build. Then all those changes are bundled into the next build.

For instance, if there are three developers, Joe, Fred and Mary, and Joe pushes code, a CI build will start. While the build is running, both Fred and Mary commit code. When Joe's build is done then Fred and Mary's changes will trigger a CI build.

Regarding the suggested Issue Trackers (Appendix E) : as you are suggesting Subversion as a source control system and emphasis the fact that the issue tracker should interface nicely with the source control system, why don't you suggest Trac as it natively interfaces with Subversion ?

I wasn't familiar with Trac. I've added it to the online resource page. Thanks for the suggestion Jerome! btw, I also added RT at the suggestion of another reader!

Keep them coming! ;)

Jared

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

Thu, 11 Aug 2005

MBUnit for .NET testing

A co-worker of mine (Susan Bartholow) mentioned a neat feature in MBUnit today and I thought it was share-worthy. :)

First, what is MBUnit? MBUnit is a .NET testing framework. You can use it for testing any of the .NET family of languages. C#, VB, etc. Here's a short tutorial.

Remember, a testing framework with "unit" in the name isn't just useful for unit testing! ;) The various XUnit frameworks are great for functional and integration tests as well.

Second, Susan's tip about the decorator. (A decorator is a feature added to the test framework.) She found a decorator in MBUnit called ThreadedRepeat.

Here's a short description of ThreadedRepeat from the Peli's Farm blog

In MbUnit, other decorators are available. Here I describe two of those:
RepeatAttribute and ThreadedRepeatAttribute. RepeatAttribute will make the
execution of the test repeated the desired number of times in the same thread
while ThreadedRepeatAttribute will launch simultaneously a desired number of
threads that will execute the method. RepeatAttribute create a sequence of
execution, ThreadedRepeatAttribute create a parallel execution.

    [Test]
    [Repeat(10)] // this will make the RepeatedTest executed 10 times
    public void RepeatedTest()
    { ... }

    [Test]
    [ThreadedRepeat(10)] // this will make the RepeatedTest executed in 10 concurent threads
    public void AmIThreadSake()
    { ... }
  

-Enjoy!

Jared

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

Wed, 10 Aug 2005

Do you practice SMART planning?

I heard Andy Hunt speak tonight on "Refactoring Your Wetware at the Triangle .NET User Group. Here's the blurb on Andy's talk:

The raw material of software development is not a language, and IDE, or a tool, it's you. How we learn new technology and acquire new skills is key to our careers. Join Andy Hunt for a presentation that includes The Dreyfus Model (from his popular talk "Herding Raceshorses and Racing Sheep") and a look at how to boost your career by Integrating Brain Modalities, Accelerating Learning, and Managing the Torrent.

There were several good points throughout the talk and here's one of them. When trying to learn something new, practice SMART planning. Be sure your goals are:

• Specific
• Measurable
• Attainable
• Relevant
• Trackable

What plans do you have to improve yourself professionally this year? This quarter? How about this month? And this week? Finally, today?

Without concrete plans, you'll have trouble getting started.

If you don't take those concrete plans and break them down into daily and weekly tasks, it'll be difficult for you to finish anything.

Do you want to learn a new language? Set a goal for yourself to write a "To Do" list by the end of next week. Are you polishing up your development skills? Choose to learn a new pattern by Friday. Testing? Investigate a new XUnit derivative this week.

Take responsibility for your own skillset. Don't wait for nwe skills to just fall into your lap. Take control of your career.

If you don't remember anything else, remember this. If not now, when?

Jared

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

RapidSVN

I got an email today asking me to help out a friend having trouble with TortoiseSVN. Apparently it has trouble co-existing with Symantec's Internet Security 2005. The pre-existing Symantec tool won't start once Tortoise is installed.

In poking around to find another SVN client for my friend, I stumbled across RapidSVN. It's hosted by the good folks over at Tigris, the same people who make Subversion. I'm not sure if the same people wrote it or not. However, the tool ran great for both me and my troubled friend. If you tinker with Subversion, it's worth investigating.

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

Tue, 09 Aug 2005

Joshua Bloch at JavaRanch this week

Will and I had a great time at JavaRanch last week. We spent time in the Process forum.

This week Joshua Bloch and Neal Gafter will be in the Java in General forum discussing their new book Java Puzzlers: Traps, Pitfalls, and Corner Cases.

If you visit the forum and participate you'll be entered in a drawing for a free copy of their new book.

Jared

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

Mon, 08 Aug 2005

Writing for The Pragmatic Programmers

Twice in the last week I've been asked about the experience of writing a book for the Pragmatic Programmers. Since I've been meaning to blog on this topic for some time, I decided it must be time to actually sit down and do it. :)

This thread on Java Ranch is a good place to start. In part it says:

From what I've seen most of the authors either work mostly with Dave or Andy, not both. We worked with Andy for the most part. We've known Andy for years, he's local, and we've reviewed most of the books they've written.

Andy had a ~very~ heavy influence on the style of quality of the book. Will and I are developers, not writers, so our early drafts were kind of bad. Andy met with us on many occasions to retools sections of the book, writing tips, chapter direction, etc. We spent a lot of time in Carolina Cafe across the street from SAS over supper with free WiFi. We knew what we wanted to say but needed help in figuring out how to say it.

The book is ours and it represents our experience and ideas, but we got a lot of guidance and help from Andy on how present them. As you've said, there are some great books in the PragProg bookshelf already, and we had to meet that standard. I honestly don't think we would've made it without Andy's help. (Thanks Andy!)

When I compare some my current writing to the writing I did before the book and I just shudder. It's been a great experience for me.

Here's a bit from a new list I've just joined, the Agile Book Group:

Our day to day writing experience was very different from a normal writers (I'm told). Dave and Andy built a really cool rendering system for the Pragmatic Bookshelf. On a Linux or Mac box we can build the entire book to a PDF that's largely press ready! It's even got cut lines on it. On a Windows box, we could built to an HTML version, which was fine for day to day work. The entire book was in an XML format, stored in CVS (and Subversion towards the end). It was very cool to startup the laptop, do a "cvs checkout", then build a copy of the book, edit for a while, then check in the changes.

How's that? Let me know if there are things you'd like to hear about.

Jared

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

Sun, 07 Aug 2005

Photo from space

I saw blog entry on Graham's Glass's site this weekend.

He's got a link to what he calls "the most complicated photo ever" and I think I agree with him.

Check out the link if you've got a moment to be amazed.

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

Sat, 06 Aug 2005

I messed up and I apologize

I have unwittingly offended one of our readers and I must apologize.

When I first saw David Starr's review of Ship It!, I was quite pleased. He seemed to really like the book and enjoyed what we had to say.

I was especially fond of the parts of the review like if you are a Development Team Lead or a Development Manager, you should be fired if you don't read this book and Ship It! contains everything that I wish I knew about software development exactly 5 years ago.

But we exchanged emails and I asked about the picture with the bunny ears. Hit this link and look to the right hand side. I thought the bunny ear picture was terribly entertaining and thought there must be a great story behind it.

But alas... those were not bunny ears at all!

In fact, those were MSN Butterfly ears!

In this posting David let me know exactly what he thought of my bunny comments.

So here and now Dave, I apologize for not recognizing The Butterfly. I guess sometimes I can be a little hare brained. It won't happen again.

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

Tue, 02 Aug 2005

Do you know your Bus Number?

The topic of a team's Bus Number (or Truck Number) has come up three times in the last two days, so I'm carting it out here.

Taken from Ship It! (page 115):

Raise Your Bus Number

Your bus number is the number of developers you'd have to lose to disable your project.

Whether they quit or get hit by the proverbial bus, losing this many people will derail your project. If you have a single superstar who keeps all the project details to themselves, you have a bus number of one, and that's a problem. If every member of your team can fill in for any other person, then you would have to lose your entire team for the project to be completely derailed. Ideally, you want your bus number to be equal to the number of your team members, but at the very least you should work to raise the number. If the loss of one or two key people can devastate your product, take steps to raise that number.

Tracer Bullet Development automatically raises your bus number. When team members from adjacent layers work together to define their shared interfaces, they are sharing knowledge about each layer's operations. This picture, shared between the two teams, makes it possible for your group's members to move between layers more easily. At a minimum, everyone has a basic understanding of what adjacent layers do and how they work.

If you've never considered your project's bus number, take a few minutes to survey your team. What's your bus number? What steps can you take to raise it?

You can read more about Bus Numbers and Truck Numbers at the famous C2 Wiki

Jared

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

Mon, 01 Aug 2005

Will and I will be on JavaRanch this week

Starting this evening Will and I will be chatting about Ship It! over at JavaRanch this week. If you've got questions or just want to see what everyone else's questions are, or you just want to heckle, drop on by! :) JavaRanch is a great community of Java developers and well worth a visit. The forums are very active with everyone from beginners to gurus participating.

Here's the mail from JavaRanch.

Looking for practical, proven advice for software development projects? Then you will want to be part of our promotion this week. Jared Richardson and Will Gwaltney, authors of "Ship It! A Practical Guide to Successful Software Projects" are in the Process forum this week to discuss their new book. The Process forum can be found here:

http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=forum&f=42

Participate in this week's giveaway by asking the authors a question or two and you may win a copy of their book!

Thanks to The Pragmatic Bookshelf for providing the books!

The giveaway start on Tuesday, August 2nd. The drawing will be held on Friday, August 5th.

Visit our Book Promotion page to see how to win and to see the other exciting promotions coming up.

The Book Promotion page: http://www.javaranch.com/bookpromo.jsp

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

Sun, 31 Jul 2005

Who got the shirts?

I asked people to send in their favorite key practice with the promise of free t-shirts! :)

Continuous Integration was the practice most often picked, even by people who aren't using it yet. Apparently it's pretty easy to see the benefit even if you aren't fortunate enough to be working in a CI environment every day.

Without further ado, here are the winners:

• Hiroshi Sakurai - "I love 'Review All Code' the best."
• David Starr - "With continuous builds, there is no question about the current state of our products."
• Matthew Bass - "My favorite practice: Write & Run Tests. ...writing and running unit tests gives me an insane amount of confidence both that my code works and that it's written correctly."
• David Murry - "I like the practice of compiling continuous builds. This practice, coupled with several others ensures there will be no "surprises" when a new version is put into production. Priceless!"
• Eric Starr (no relation to David!) - "My favorite 'Ship It' practice has got to be #4 Build Automatically. The main reason for this is that I am tired of fixing an issue only to find that the fix gets broken by someone else (and I'm tired of breaking others' fixes by 'fixing' one of my own)."

Thanks for all the mail! I've forwarded on the winning mail to the Ship It! mailing list.

Jared

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

Sat, 30 Jul 2005

We're matching Amazon

Our book Ship it! A Practical Guide to Successful Software Projects is published by the Pragmatic Bookshelf. Traditionally the Prag Prog team have kept all their books at the listed retail price on their web site. Then online stores like Amazon.com sell the book for 30 to 35% off the retail price. This means our book costs $20 on Amazon.com and $30 on the Prag Prog site.

Next week we are running a little experiment. We lowered the price of the book to $20 on the Prag Prog site. So for the next week, we are matching Amazon's price.

This way you (the consumer) gets the same price everywhere you shop and we (the authors) get a lot bigger piece of the purchase price.

The sales numbers themselve will decide if this discount is a good idea or not. We have a Java Ranch book promotion this week that might help, but ultimately you the book buyers will have to tell us if this is an idea worth keeping. If you already have a book, send me mail and let me know what you think. Would this have swayed your purchase decision? Should this be a long lasting discount?

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

Thu, 28 Jul 2005

Free shirt reminder

Just a quick reminder, if you planned on going after one of the shirts, today's your last day.

Here's the original post.

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

Technical Idiot Savants

Andy Hunt gave a talk Thursday night in Reston, Virginia called Refactoring Your Wetware. I got a chance to review the slides before he went and it got me thinking... sounded like it would be a great talk by the way!

Some developers let their company put them in a niche. They learn so much of the company's internal technology that they lose touch with their industry at large. They become very good at a very small set of technologies.

This is a very bad thing for both the company and the developer.

As a developer, you have gained a great many non-transferable job skills. When you decide to move, or when the company lays you and 10,000 other poor souls off, you'll be unemployable. From a personal point of view, this is a very bad situation.

It's also bad for your company. There are a great many smart and talented people across this world and they are doing clever things. Are you learning about the clever things people are doing? Did you know about the ideas behind AJAX before AJAX became a buzzword? Or do you know what AJAX is now? :)

My point is that if you keep informed about your industry in general, you'll continue to learn. And you'll bring that knowledge back to your day job where you'll apply the new ideas. Instead of solving problems yourself, you'll read about how some other smart people solved the same problem.

It comes down to pulling your head up from your work from time to time and looking around at the landscape. You may be working very hard building your road, but are you headed in the right direction? Do you see the canyon ahead that you'll want to avoid?

Don't let you company train you to become a technical idiot savant who can do one thing so very well but is useless for anything else. It may occur naturally in some people, but in developers, it's a learned trait!

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

Justin Gehtland on software

I saw a great quote on Justin's blog.

So, I guess what I'm saying is, Agile Development works for books as well as for software. Get the product in front of readers early and often, and they'll work with you to make the perfect product. Deliver once, at the end, and there are bound to be problems, and lots of unhappy customers who, rightfully, can't understand why the problems existed in the first place.

Check out the entire post here

In Ship It! we talk about Tracer Bullet Development and how it enables you to have an end-to-end running system very early in your development cycle. The abilty to demo the product and get early feedback, for books and software, is the only way to actually deliver what your customer needs, as opposed to what they asked you to build!

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

Tue, 26 Jul 2005

You are responsible for you

I read a great entry today on Steve Freeman's blog.

Steve was quoting Kent Beck, apparently from XP2005

As Kent likes to point out these days, the only thing you can really change is yourself, so doing the best job you can is the only available response; the rest is out of scope.

There's a lot of wisdom in those words. You are responsible for what you do and who you are. If you're not happy with you level of expertise in a given area, don't wait for your tech lead or company to conveniently drop the training in your lap. Buy a book. Peruse via Google. Find the information yourself to improve yourself.

Find habits that you can practice with or without the rest of your team. Improve yourself. Don't stress over the rest. Do the best job you can and sleep soundly when you go home at night.

You can't control the customer, your management or any one of a thousand other potential issues related to your project. But you can control yourself instead of letting the project control you.

Also, Steve talks about a panel he sat on at XP2005 that's a great read. Check it out if you have the time.

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

Sun, 24 Jul 2005

JUnit is not a Unit Testing framework

Okay, after that inflammatory comment got your attention... :) JUnit is a ~testing~ framework. There is nothing in the framework that limits it's use to only unit testing. Given the name of JUnit, NUnit, MBUnit, and others, perhaps unit testing was the original motivation, but don't limit your use of a great tool.

If you're not using an XUnit testing framework for functional, acceptance and integration tests, you've been missing out on great uses for your favorite testing framework. Get all the benefits that you've come to expect from unit tests with your "mainstream" testing. Things like repeatable results, automatic test runs and known product state should be standard operating procedure in your shop... Are they?

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

Thu, 21 Jul 2005

Free Ship It! t-shirts

Those of you who've read Ship It! know about the book's key practices poster. And you may have also visited the Ship It! CafePress store. I decided to merge the two ideas. :)

Look over the key practices poster and let me know which practice you like the best. Include a sentence or two about why you like it. If anything in the book (or the sample chapter) changed the way you use the practice, feel free to include that as well.

A week from today (Friday, July 29), I'll send a free Ship It! t-shirt to the writers of the five best letters. This shirt has the key practices poster printed on the back, so you can wear it to work and use it as a conversation starter... or you can just wear it to mow the grass! I'll announce the five winners here and on the mailing list.

I'll reprint all the entries on the Ship It! mailing list, or you can post your letter directly to the list.

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

Wed, 20 Jul 2005

Podcast interview with Software Development Magazine

If Dave is hip for getting a Rails podcast interview, then Will and I must be hip too! ;) Who-da-thunk-it?

We were interviewed by Mike Riley (for Software Development Magazine) who had some great questions about Ship It!. We talked about things like Tumbleweed Developers, Continuous Integration, and The List. It won't be published for a few months, but I'll post a link when it goes live.

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

Tue, 19 Jul 2005

Test Framework Comparison

This is a short article and introduction to JUnit and several other frameworks, including JTiger, TestNG, and the next version of JUnit. It's a good article if you've got the time.

Test Framework Comparison by Justin Lee.

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

Mon, 18 Jul 2005

Develop in a sandbox

First, the term sandbox isn't referring to a cat's litterbox! It's a small contained play area on your own machine. Your sandbox is your own playpen. Of course, it's possible your sandbox does double duty, but that's another topic... ;)

Developing in a sandbox has several implications. You can build, run, and test the product locally.

James Duncan Davidson talks about how he builds in a sandbox. I like his motivation for automation as well as the descriptions of how they automate. The description of how easy it was replace a workstation when it died was nice. :) That's a real test of your automation practices!

Here's the conclusion:

Just because it looks wild and wooly out here in Rails land doesn't mean that you can't exert an iron hand when it comes to development, packaging, and deployment. And if you think those properties are unique to J2EE applications, here's a little secret: When the people at Sun sat down to embed those terms into the specifications and books, they didn't invent them or the concepts they stand for. They simply codified them in a way which puts them in front of everyone's face. But, regardless of whether they are codified or not, to get to a true level of managing the develop-test-deploy cycle using any framework takes a bit of human effort in set up and maintenance. And it takes some script-fu. But it's worth it. Every little bit.

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

Thu, 14 Jul 2005

It's just too complicated here!

Time and again I hear people say that their problem is too complicated to solve cleanly. The reason their solution is so messy? It's because the problem requires it!

This is, of course, just silliness. Your problem may be difficult. Your timeline may be too short. But you've got to realize that a messy solution is going to cost you needless evenings, weekends, and more stress than your body should have to endure. It's going to cost your company money to patch, fix and refix over and over.

I once met a team of developers who thought their build system was so complicated it needed to be built five to seven times before it could build cleanly. So when a build was required, everyone went to one box that could build and they hit the "build" key in the IDE until the build succeeded.

It took about half a day with Ant to create a robust, repeatable build script that did everything needed. The build wasn't that complicated, but once they had a working solution, everyone accepted the "solution".

Imagine the types of errors that crept into that code base. Remember, none of the developers could build the code! Everyone did the best they could, then checked in the code. Talk about Integration Hell! How many hours and days do you think were wasted in this shop? This system was used by the team for at least six months! Talk about coding up bugs and then wasting days fixing them...

Take the time to solve your problems cleanly and you'll only have to solve them once. Don't tolerate Broken Windows!

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

Wed, 13 Jul 2005

JavaRanch book promotion
Both Will and I are hanging out in the Process forum of JavaRanch the first week of August as a book promotion. We'll answer questions about the book from August second to the fifth. Come by and ask a few questions and JavaRanch might pick you to win a free book! If you've never visited JavaRanch, it's a great Java resource with very active discussion boards.

Of course, you can always drop on the Ship It Google mailing list now if you have book questions... ;)

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

Tue, 12 Jul 2005

Sensory Overload
What happens when you put too much information in front of someone? They overload! Will Gwaltney wrote a great bit on how fighter pilots discovered this phenomena years ago and how it applies to you as a developer today. Check out Will's blog.

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

Mon, 11 Jul 2005

Cancer Triathlon
Hi all. A co-worker of mine at SAS is participating in a triathlon to raise money for cancer research. Please visit the web site and if you choose not to support Laura, support your local chapter.

Greetings!

Scott Greene, my husband Tim's business partner and dear friend, is fighting non-hodkins lymphoma. Tim shaved his head.... which I won't do, but I am training for a triathlon to raise money for The Leukemia & Lymphoma Society as a participant in their Team In Training. Please help by making a contribution. Each donation helps accelerate cures for leukemia, lymphoma and myeloma and brings hope to the patients and families who are on the front lines of the battle against these diseases.

Want to donate or help? Simply visit my web site

--Laura Taillon

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

Thu, 30 Jun 2005

Why Automate Anything?

I saw Eric Armstrong's blog this morning. He posted about a new tool called Jackpot that I'm not sure about just yet. It would have a great deal more value to me if it was being created as an Ant task instead of NetBeans module, but that's another story. :)

What caught my eye was a story he told about why you'd want to automate. The story is ~great~ so I've included it here:

Early in my career, I saw my mentor (a certain David Smith), become outraged when keypunch operators were spending hour after hour making changes to files that could just as easily have been programmed. "Sure," he said to the project manager, "You don't mind doing the job with manual labor, because you're not the one who's doing the work." His reaction reflected a deep-seated appreciation for the value of human effort that turned out to be contagious.

It has been many years since I first heard that, but it's a lesson that always stuck with me: Never do large amounts of mindless, repetitive work if you can possibly get the computer to do it for you.

When you think about it, it only stands to reason:

• The computer will work all day and all night, never taking a break, without complaining.
• The computer will do what you told it to do, with no mistakes, at high speed.
• Once you've taught the computer how do to the task, it doesn't forgets. You can ask it to do the same thing next year, and every year thereafter.

Wow! And that's why we automate! Not only does it make our life easier, the computers are just better at repetition than we are!

What should we automate? Everything we do more than three times is a good rule of thumb. Here are some candidates.

• Product Builds
• Testing
• Building and Testing All The Time

What categories of automation have you found valuable? Send me more!

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

Wed, 29 Jun 2005

The Habits of Highly Effective Developers?

Here's a thought... what are the habits of the most effective developers you know? I know a handful of people that I consider really good. I'm sure you do as well. What are their habits that stand out to you?

I learned the habit of always keeping a priorized list of my work from one of these people. That idea morphed into what I now call The List.

Product design on a whiteboard is another.

Designing products from the GUI backwards.

These guys always know their toolsets. They have preferred editors and environments.

The best developers always have Source Code Management and use it often.

Never be afraid to close your door or turn someone away. Never permanently, but if you are working on a problem and you are deep in thought, or in the zone, send the visitor away.

Always keep informed about the latest technology trends and fads, but never use these new, untested technologies in your core products.

When there's a problem to be solved, these guys grab and don't let go. They don't mind working long hours to solve a problem. But they also hate working long hours for no good reason. Working long hours over time means you can't plan and are disorganized, not that are dedicated.

Send me more!

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

Mon, 27 Jun 2005

Mike Clark's review of Ship It

Mike was kind enough to read Ship It! and post a review on his blog.

Here's the link if you missed it and a short exerpt as well.

...What I love about this book is that I can hand it to any developer or manager and know that the advice is relevant to their project. It doesn't matter if they're already using a formal process or they have no process at all. Without the practices outlined in this book, every project is at risk of not shipping on time to happy customers. And so it should come as no surprise that I'll be highly recommending Ship It! to every project I visit...

Thanks Mike!

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

Thu, 23 Jun 2005

Blitzkrieg Testing

In an ideal world, every class in your software product would have unit tests. Mock Client Tests would validate every usage scenario. You'd catch every break in your product in minutes with your Continuous Integration system and the developer who changed the code would fix the problem quickly.

But we don't live in a perfect world, do we?

We support products that other people wrote … products with no automated tests at all. Sometimes we create products under incredibly tight deadlines and we don't add tests ourselves.

How we got here isn't important though … the important issue is how do we get the critical testing coverage we need? I've already talked about Mock Client Testing. That tells us what types of test to write. But in my mind this is a different question.

A blitzkrieg is an attack that rushes in headlong. It doesn't worry about taking every building and bridge … the soldiers just plow ahead and take the country. The details are addressed later.

Blitzkrieg Testing is similar. Aim for breadth, not depth. If you're testing a portal product that has ten main pages, write a test that logs in, visits a page, verifies the page, and then logs out. You've written the equivalent of a "Hello world!" program for that page.

Next, add the same type of test for every page in your portal ... your preferences page, configurations, content pages, and so on. The point here is to run across the product and create a basic test for as many areas as you can. Don't get stuck in any one area. You don't want to dig in; you want to roll across the country in a tank!

What have you accomplished with this mad dash across your product?

First, you've established a basic test framework. If someone else wants to help fill in your tests later, they've got running code they can use. They don't have to start from scratch.

Second, a "Hello world!" test validates a great deal more functionality than most people think. Quite often other developers (but never you and me!) will make a change to code or a configuration file and they are sure their changes couldn't have broken anything … but somehow things are broken all over the place! These basic tests ensure that the pages still function at a basic level.

Lastly—momentum! Never underestimate the value of momentum. Once you (or your team) have completed the initial dash, it's so much easier to continue in the habit of writing tests. You've also (hopefully) provided the critical mass of tests needed to show the value of automated tests to the doubters in your midst.

What about the high priority problem areas? Just like a real blitzkrieg, the hotspots are never where you think they'll be. Sometimes the enemy just up and runs away! Go ahead and complete your first round of lightweight tests and then see what's still breaking. Where are the real hot spots? Then you can invest the time writing more detailed tests where they're needed most instead of where you suspect they might be needed.

So remember, a Blitzkrieg Test effort is a short-term dash across the product, aiming for breadth, not depth.

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

Wed, 22 Jun 2005

People give up when they can't win

Another great entry in Johanna Rothman's blog, this one titled Impossible Schedules Reinforce No Thinking. Find it here

The gist of the entry is that if you put an unreasonable goal in front of a team, they will lose hope, and give up trying any new ideas that might help. They don't have time to try out FindBugs or CruiseControl . They are too busy trying to meet a goal. They have dropped into "crisis management" mode. They are, sadly, just too busy to think.

It's a good read... as always, read her posting. It's much better than my summary. :)

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

Mon, 20 Jun 2005

Mock Client Testing

What is Mock Client Testing? I think it's the best way to get good coverage on a legacy product or an existing code base. It's also a great way to test on your new code.

First, let's talk about unit tests. By definition, one test involves one unit, usually a single class. They are fast and generally stand alone. They are written to ensure that a given class or object (a unit) works properly.

However, in the context of a larger software program, what does a unit test really tell you? Well, it enforces the social contract that tells you a class does what you expect it to do... or more accurately, it tells you that class does what the writer and test writer intended for it to do. The test doesn't tell you if the class interacts well with your code or if it's doing what you need done.

Don't get me wrong, unit tests are very useful and valuable tools, but often we stop at unit tests. Mock Client tests sit a level above unit tests.

Here's a short description of Mock Client Tests from a sidebar in my recent book Ship it! A Practical Guide to Successful Software Projects

Consider how your product will be used. It can be used by client applications (if you're developing a product) or by lower-level code (if you're writing an API). Write a test suite that emulates the client's behavior. A mock client test uses your product (or a subsystem) just like a normal client would. You have mocked up a client, just like a Mock Object imitates a server or application resource. These are usually categorized as integration tests because they can be run against live systems.

They can be chained together into performance and load tests, or individually they can be used as smoke tests. The concept is quite flexible and powerful! If you have a set of user scenarios, you can put them into a Mock Client Test and verify that they run (and continue to run after you refactor the code base!).

I used the Mock Client Test concept at a biotech company. We created a suite of JUnit tests that exercised most of the functionality in our client program. When a bug made it into the product, we found a way to expose it with an extra Mock Client Test. Before long, the product was rock solid thanks to the test suite and our Continuous Integration system, of course!

We were forced to rewrite key portions of the server code when performance became an issue. Unit tests wouldn't have been useful because many of the classes were eliminated. However, our Mock Client Test suite worked great. The APIs called by the client code didn't change, so the tests could still be run. We used these tests to tell us when the refactored program didn't return the same information as the original program.

In the first test run after the refactoring, our tests caught seventeen bugs. We cleaned those up and then the tests caught twelve. Then five. Then none. The new code went into the field and didn't have a single customer reported defect. We did addtional testing before we shipped, but in this case the Mock Client Tests gave us the information and coverage we needed!

The code wasn't perfect, but the most important parts of the code were clean. The parts that the customer runs is the only code that matters anyway, right?

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

Sun, 12 Jun 2005

Ruby On Rails is Amazing-- and No Fluff Just Stuff
I went to the RTP Software Symposium (also known as No Fluff Just Stuff this weekend... it was a great collection of people, both the speakers and the attendees. If you get a chance to attend, I'd encourage you to make the time.

The conferences run over the weekend so that people who have trouble taking time off from work can still attend. The conference travels all over the US so you shouldn't have to travel too far to attend one. I got lucky and they held one ten minutes from my front door!

One of the presentations was by Dave Thomas. He introduced Ruby On Rails, an open source web framework written in Ruby.

To put it plainly, it was simply amazing. I've never seen anyone take a tool and create as much as he did that quickly. During the last thirty minutes of the talk, Dave created a shopping cart. He (and Rails) created admin pages for editing products, a set of pages for viewing and purchasing products, and a basic shopping cart that would track what you wanted to buy. During the time he created this working shopping cart, he was also taking questions, teaching us Ruby, and stopping to tell a story or two.

I reviewed Dave and Andy's first Ruby book, so I've been exposed to the language, but I've never written any Ruby code. Not a line. But you know what? I didn't need to know Ruby to follow the demonstration or to type in the tutorial from Dave's new Rail's book (which is in beta now). The examples guide you as they go.

It's not often that I'll take time to learn a completely different technology because I think it will save me enough time to be worth it, but I'm tinkering with Rails now. I suggest that you do the same.

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

Mon, 06 Jun 2005

Mailing list on Google Groups

I've created a list on Google Groups you can use as an online community for the group.

Congratulations: you've successfully created your Google Group, Ship It!.

Here are the essentials:

* Group name: Ship It!

* Group home page: http://groups-beta.google.com/group/Ship-It

* Group email address Ship-It@googlegroups.com

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