Slashdot Mirror

I've spent a lot of time working with many different teams and trying lots of different estimation techniques, and I've had the best success with the ones that let the team work together to come up with an estimate they all believe in. My best results came with Wideband Delphi, which I've been able to use in both Agile and non-Agile projects. I've actually got a chapter on estimation in one of my books -- you can download the PDF of it.

Also, Mike Cohn has a lot to say about planning Agile projects on his blog -- definitely highly recommended reading if you're trying to plan projects.

Whenever I help teams improve the way they estimate their projects, one of the things I've really concentrated on is that planning is about more than estimation. I've got a blog post about it (The Perils of a Schedule) -- a big part of planning is making commitments, and estimation is the way to make those commitments easier to stick to (or less likely to break).

I've spent a lot of time working with many different teams and trying lots of different estimation techniques, and I've had the best success with the ones that let the team work together to come up with an estimate they all believe in. My best results came with Wideband Delphi, which I've been able to use in both Agile and non-Agile projects. I've actually got a chapter on estimation in one of my books -- you can download the PDF of it.

Also, Mike Cohn has a lot to say about planning Agile projects on his blog -- definitely highly recommended reading if you're trying to plan projects.

Whenever I help teams improve the way they estimate their projects, one of the things I've really concentrated on is that planning is about more than estimation. I've got a blog post about it (The Perils of a Schedule) -- a big part of planning is making commitments, and estimation is the way to make those commitments easier to stick to (or less likely to break).

I've spent a lot of time working with many different teams and trying lots of different estimation techniques, and I've had the best success with the ones that let the team work together to come up with an estimate they all believe in. My best results came with Wideband Delphi, which I've been able to use in both Agile and non-Agile projects. I've actually got a chapter on estimation in one of my books -- you can download the PDF of it.

Also, Mike Cohn has a lot to say about planning Agile projects on his blog -- definitely highly recommended reading if you're trying to plan projects.

Whenever I help teams improve the way they estimate their projects, one of the things I've really concentrated on is that planning is about more than estimation. I've got a blog post about it (The Perils of a Schedule) -- a big part of planning is making commitments, and estimation is the way to make those commitments easier to stick to (or less likely to break).

I would go further than just publishing the code used in scientific research. I would build the code by running it a real open source project. In fact, I've done exactly that, and it worked out incredibly well. I believe our open source approach lead to better science, and also better software.

I worked with researchers from MIT and Columbia on a research project that involved gathering and analyzing a large amount of publication data. The results of the study are about to be published (you can read the working paper at the lead researcher's website).

We intended the code for this project to be released from the beginning, so we ran it as an open source project. I followed the basic formula from Karl Fogel's excellent (and free to download) book, Producing Open Source Software: set up a website for the project, created lots of documentation, tried to make it as easy as possible for someone to get up and running, made the source available via Subversion, and made it easy to contact us.

Quality was really important for us, so we put a lot of effort into testing. I definitely believe that the fact that we intended the project to be open source from the beginning helped with that. We weren't treating the code as some piece of throwaway or replaceable lab equipment. I'm convinced that treating it as a real product of the research caused us to take the development and the quality much more seriously than a lot of researchers. I've since heard from other researchers who are starting to use the software as well, and everyone who sees it feels that it came out really well.

There was another scientific benefit that should definitely appeal to anyone who lives in the publish-or-perish world of science research. We published a paper specifically on the project (Azoulay P, Stellman A, Zivin JG. PublicationHarvester. An open-source software tool for science policy research. Research Policy 35 (2006) 970-974. -- there's a link to the PDF on the lead researcher's website.)

It's funny -- I wrote an article a few years ago with Jennifer Greene for O'Reilly ONLamp called What Corporate Projects Should Learn from Open Source. I'm now convinced that science research projects can also learn a great deal from open source as well.

When Jenny Greene and I were working on Applied Software Project Management, we put a lot of effort into coming up with a way to document the practices that we wrote about. We wanted to make them really easy to understand, because we didn't people to have to learn to read something heavyweight or cumbersome.

We ended up using "scripts" (think scripts that an actor uses, not scripts that a shell script uses) that just explain each process or practice step by step. We got a lot of mileage out of adapting the format that we used for use cases -- you can see an example here -- it's a pretty standard way of writing down use cases, but we'd never seen it used for practices. But it actually ended up making a lot of sense.

That format worked really well for us: we used it for estimation (using Wideband Delphi), inspections and code reviews, developing specs, planning for risks, and a bunch of other practices. You might get some mileage out of it too.

When Jenny Greene and I were working on Applied Software Project Management, we put a lot of effort into coming up with a way to document the practices that we wrote about. We wanted to make them really easy to understand, because we didn't people to have to learn to read something heavyweight or cumbersome.

We ended up using "scripts" (think scripts that an actor uses, not scripts that a shell script uses) that just explain each process or practice step by step. We got a lot of mileage out of adapting the format that we used for use cases -- you can see an example here -- it's a pretty standard way of writing down use cases, but we'd never seen it used for practices. But it actually ended up making a lot of sense.

That format worked really well for us: we used it for estimation (using Wideband Delphi), inspections and code reviews, developing specs, planning for risks, and a bunch of other practices. You might get some mileage out of it too.

When Jenny Greene and I were working on Applied Software Project Management, we put a lot of effort into coming up with a way to document the practices that we wrote about. We wanted to make them really easy to understand, because we didn't people to have to learn to read something heavyweight or cumbersome.

We ended up using "scripts" (think scripts that an actor uses, not scripts that a shell script uses) that just explain each process or practice step by step. We got a lot of mileage out of adapting the format that we used for use cases -- you can see an example here -- it's a pretty standard way of writing down use cases, but we'd never seen it used for practices. But it actually ended up making a lot of sense.

That format worked really well for us: we used it for estimation (using Wideband Delphi), inspections and code reviews, developing specs, planning for risks, and a bunch of other practices. You might get some mileage out of it too.

When Jenny Greene and I were working on Applied Software Project Management, we put a lot of effort into coming up with a way to document the practices that we wrote about. We wanted to make them really easy to understand, because we didn't people to have to learn to read something heavyweight or cumbersome.

We ended up using "scripts" (think scripts that an actor uses, not scripts that a shell script uses) that just explain each process or practice step by step. We got a lot of mileage out of adapting the format that we used for use cases -- you can see an example here -- it's a pretty standard way of writing down use cases, but we'd never seen it used for practices. But it actually ended up making a lot of sense.

That format worked really well for us: we used it for estimation (using Wideband Delphi), inspections and code reviews, developing specs, planning for risks, and a bunch of other practices. You might get some mileage out of it too.

When Jenny Greene and I were working on Applied Software Project Management, we put a lot of effort into coming up with a way to document the practices that we wrote about. We wanted to make them really easy to understand, because we didn't people to have to learn to read something heavyweight or cumbersome.

We ended up using "scripts" (think scripts that an actor uses, not scripts that a shell script uses) that just explain each process or practice step by step. We got a lot of mileage out of adapting the format that we used for use cases -- you can see an example here -- it's a pretty standard way of writing down use cases, but we'd never seen it used for practices. But it actually ended up making a lot of sense.

That format worked really well for us: we used it for estimation (using Wideband Delphi), inspections and code reviews, developing specs, planning for risks, and a bunch of other practices. You might get some mileage out of it too.

When Jenny Greene and I were working on Applied Software Project Management, we put a lot of effort into coming up with a way to document the practices that we wrote about. We wanted to make them really easy to understand, because we didn't people to have to learn to read something heavyweight or cumbersome.

We ended up using "scripts" (think scripts that an actor uses, not scripts that a shell script uses) that just explain each process or practice step by step. We got a lot of mileage out of adapting the format that we used for use cases -- you can see an example here -- it's a pretty standard way of writing down use cases, but we'd never seen it used for practices. But it actually ended up making a lot of sense.

That format worked really well for us: we used it for estimation (using Wideband Delphi), inspections and code reviews, developing specs, planning for risks, and a bunch of other practices. You might get some mileage out of it too.

This turns out to be a problem space with some really interesting conclusions. I spent some time over the last few years working with researchers from MIT, UCSD and NBER to come up with ways to analyze this sort of problem. They were focused specifically on medical publications and researchers in the roster of the Association of American Medical Colleges. They identified a set of well-known "superstar" researchers, and traced the network of their colleagues, as well as the second-degree social network of their colleagues' colleagues among other "superstars".

I built a bunch of software to help them analyze this data, which we released as GPL'd open source projects (Publication Harvester and SC/Gen and SocialNetworking). I've gotten e-mail from a few other bibliometric researchers who have also used it. Basically, the software automatically downloads publication citations from PubMed for a set of "superstar" researchers, looks for their colleagues, and then downloads their colleagues' publication citations, generating reports that can be fed into a statistical package.

They ended up coming up with some interesting results. Here's a Google Scholar search that shows some of the papers that came out of the study. They did end up weighting their results using journal impact factors, but the actual network of colleague publications served as an important way to remove the extraneous data.

This turns out to be a problem space with some really interesting conclusions. I spent some time over the last few years working with researchers from MIT, UCSD and NBER to come up with ways to analyze this sort of problem. They were focused specifically on medical publications and researchers in the roster of the Association of American Medical Colleges. They identified a set of well-known "superstar" researchers, and traced the network of their colleagues, as well as the second-degree social network of their colleagues' colleagues among other "superstars".

I built a bunch of software to help them analyze this data, which we released as GPL'd open source projects (Publication Harvester and SC/Gen and SocialNetworking). I've gotten e-mail from a few other bibliometric researchers who have also used it. Basically, the software automatically downloads publication citations from PubMed for a set of "superstar" researchers, looks for their colleagues, and then downloads their colleagues' publication citations, generating reports that can be fed into a statistical package.

They ended up coming up with some interesting results. Here's a Google Scholar search that shows some of the papers that came out of the study. They did end up weighting their results using journal impact factors, but the actual network of colleague publications served as an important way to remove the extraneous data.

I'm about to finish my fourth book for O'Reilly, Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders (which should be out in stores by March).

As far as tools go, my coauthor, Jenny, and I wrote our first book using Microsoft Word, but could just as easily have been using OpenOffice, Pages or any other word processor. One thing that was enormously useful was EndNote for managing the bibliography. Our next two books were in O'Reilly's Head First series (PMP and C#), and we wrote them entirely in Adobe InDesign. (People think that there's a whole team of people designing and laying out Head First books -- it was just us, our editor, and an awesome but overworked graphic designer, Lou, who helped improve our layouts once we had them in reasonable shape.) InDesign isn't exactly the easiest tool for a book author, but it was sufficient. But it made me really appreciate word processors!

A few things that really became clear to me over the course of working on these books:

a) Pay attention to what you're delivering to your editor, and what they'll do with it. Publishers have their own set of templates and production stuff to get camera-ready copy together. Head First was a very interesting lesson in that, because Jenny and I actually produced a lot of camera-ready copy ourselves. But for most books, whatever you turn over to your publisher will get transmogrified into their own internal format.

b) The production editor people I've worked with and talked to (not just at O'Reilly, but at other publishers, too) have been extremely competent, and it's their job to take whatever it is you give them and make it work. It needs to be copyedited, typeset, and reviewed, and sent to a printer. I highly recommend getting to know them, and being as flexible and agreeable as possible (they generally won't ask you to compromise your vision for the book -- it's generally about technical stuff, like how to deal with footnotes, references, images, etc.)

c) You asked about version control. One of the best authors I've ever worked with, Karl Fogel -- he's a contributor to Beautiful Teams, and also just a great guy -- wrote a fantastic book called Producing Open Source Software, which you can buy from O'Reilly or download for free from the website. (Anyone who's interested in starting or contributing to an open source project absolutely needs to read that book. Disclosure: I was a technical reviewer for it.) In true open source fashion, Karl made his version control repository for the book available, and that's a good model to copy. Jenny and I didn't do anything quite so formalized; we just shared folders, and that was sufficient for us (even with hundreds and hundreds of image files for each Head First book).

d) This is the most important thing: make sure you have a clear idea of what it is you want to write! It's easy to get started on a project, only to have it trail off because you don't really have a whole book's worth of material. The more you can outline, the more research you do, and the more you prepare, the better the book will be.

Now, that's all assuming that you have a publisher lined up and a contract signed. If you don't, I highly recommend reading through the excellent Writing for O'Reilly section on their website. They walk you through all of the steps of proposing a book and the mechanics of actually working with a publisher -- and from everyone I've talked to, it's very similar