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

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.


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


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?


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.



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!


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!



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
Justin's posts
Dion's entries


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!


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.


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!


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:

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.



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.


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.


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



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

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:

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!

If you live near Reston or Charlotte, please come out and see what No Fluff/Just Stuff is all about. I've attended NFJS myself and found it to be a great experience.

Have fun!


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.


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? ;)


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.


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


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'
and so forth and so on, then you probably need to turn on MySql networking (assuming MySql is running of course).

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

Rail on!


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.

Build Continuously
Test Continuously
Fast Feedback Leads to Fast Fixes

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

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:


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


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! ;)


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.

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

    [ThreadedRepeat(10)] // this will make the RepeatedTest executed in 10 concurent threads
    public void AmIThreadSake()
    { ... }
This is a quick decorator that can help get you started with some basic threaded testing. You can simulate multiple users or a heavier load. It's a great way to leverage your existing test suites. Talk about code re-use! :)



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:

But this doesn't just apply to targetted learning. It also applies to your project planning, your personal goal setting, etc. It's just good sense on many levels.

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?


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


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.


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.


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


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:


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