This week I (re-)read the Anti-Patterns book, which I first read more than 10 years ago. The idea of Anti-Patterns is that there are various unproductive behavior modes in software engineering which result in similar problems, and can be treated in similar ways. This book is well worth a review now and again.

 I think the anti-pattern most relevant to the netCDF libraries is Project Mismanagement, for which I blame no one other than myself. ;-0

It's interesting that the solution to this anti-pattern, risk analysis, is something that is already underway for future netCDF releases.

To anyone tired of waiting for the configure script to run: try the -C option.

This creates a configure cache (config.cache) which stores the result of each test. When a test is to be run, configure first checks the cache, and if the answer is there, the test is not run. This helps a lot when rerunning configure, but also running it just one time. This is because configure reruns a lot of tests multiple times.

This also speeds up the libtool and udunits configure runs, which will use the answers from the netcdf configure run if they are available.

Here's a great demo, less than 5 minutes long, of Tools UI and using NcML: http://www.youtube.com/watch?v=w-Df4Np7tLA

In the upcoming 4.1.3 release at the end of this Summer, there will be a permanent change in how the fortran library is packaged.

In olden times, before shared libraries came along, the netCDF F77 API was packaged up with the C library. This meant that the same binary .a file served as a library for both C and Fortran 77. This was a somewhat unorthodox method of proceeding, but it worked well for netCDF until shared libraries came along.

 With shared libraries, the packaging of the F77 API with the C API has an odd side-effect: when compiling a C program, the linker wants to know where the fortran shared libraries are, even though there is no fortran code involved. Naturally we are not going to make our C users suffer this sort of indignity. After all, if they wanted to associate with Fortran riff-raff, they would not be C programmers!

 To fix this, we introduced the --enable-separate-fortran option in configure. When turned on (and it was turned on by default for shared library builds) the fortran 77 API is packaged in a separate library. Fortran users now have to link to -lnetcdff -lnetcdf instead of just -lnetcdf. (Note the extra "f" on the fortran library name).

 This works so very well that I am taking out all ability to build the fortran 77 and C library together. Starting in 4.1.3, a separate fortran library will always be built. The motivation for taking this feature out is to simplify the build system. There are numerous places where we have to do one thing for a combined library, and another for separate libraries. And this also doubles our test cases (although I don't actually check both build styles on all platforms anyway, as that would in impractical).

But as soon as I merge my branch into the trunk, this and some other configure options will go away, and the build system will be considerably simpler, which makes it easier to maintain and get correct on all platforms.

This week I read "Life Would be Easy If It Weren't for Other People" by Connie Podesta and Vicki Sanderson. (Thanks to Leslie in the NCAR library for getting this and any other book via interlibrary loan!)  I had heard about this book years ago - it comes highly recommended in the world of corporate project management.

The book is very good and worthwhile to read for engineers and especially their supervisors (a broad hint to Ethan!)

 It outlines four styles of communication: assertive, aggressive, passive, and passive-aggressive. It reminds the reader repeatedly that the assertive form of communication is the only one that leads to long-term solutions to problems. Unfortunately, the other three are more frequently used. ;-)

We are constantly training and being trained by others as to which communication style works best. If we reward people for negative communication, they will continue to provide it. If we respond assertively, we not only have a better chance of solving the ultimate problem - we also make negative communication less effective. Most people will respond by changing to more positive communication modes.

NetCDF is not and never has been a one-person enterprise, since even before the first release of the software, more than 20 years ago. I am happy to say that within the netCDF team, positive and assertive communication is the normal mode. Without that, I don't think we would have enjoyed the product success that we have.

The real value of this book is in helping me see how my own communications can be made more effective and helpful.