Jared's Weblog

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


Jared Richardson 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

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:

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.

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