I made a documentary a few years ago about the cultural history of the nuclear weapons programme. One of the most interesting interviews I had was with a guy called Martin Harwit. Harwit, a gentle, unassuming and softly-spoken man, was director of the National Air and Space museum in Washington, DC, but was rudely ousted in 1995.

Harwit had attempted to mount an exhibition showcasing the Enola Gay, which was the B52 airplane that dropped the first atomic bomb on Hiroshima. As part of that exhibition, he tried to ask whether the bombing was justified. His approach called down a rain of fire. He was blasted for historical revisionism by the politically powerful veteran community, and the board had little opportunity but to let him go.

Whether America was right to drop the bomb was a question that I addressed in the movie, but the reason I'm recalling the interview now is because of something Harwit wrote in his book, An Exhibit Denied: Lobbying the History of Enola Gay. 

The spectre of the Enola Gay's public display caused a tussle before Harwit's moral inquiry even began. The exhibition was mounted because 1995 was the 50-year anniversary of the bombing, and veterans were anxious to see the plane exhibited that year. 

Archivists had other ideas. They wanted the job done properly. They knew that in 500 years, when historians examined the aircraft, they might ask an array of arcane, academic questions. For example, what materials were the alloys in specific engine parts comprised of? Investigating minute details such as these and acquiring or rebuilding complex parts for complete veracity takes a great deal of time and effort. They may not have been interesting for veterans who wanted to see their bird fly one last time, but skimping on such tasks for short-term satisfaction puts the whole archival endeavour at risk.

The more I think about the quandary facing archivists preparing the Enola Gay exhibit, the more I worry about our digital existence. Increasingly, our lives are articulated digitally. We share our experiences with others online, and carry out more of our transactions in binary form. The amount of information that we create is accelerating exponentially. "Between the birth of the world and 2003, there were five exabytes of information created," said Google CEO Eric Schimdt recently. "We [now] create five exabytes every two days."

Archiving this stuff is going to be really difficult, in a way that the Enola Gay's archivists couldn't begin to imagine. For one thing, there's the physical media involved. Information may become increasingly stored in the cloud, but it must still be held on physical media, in some data centre somewhere. 

Estimates for the longevity of this physical media vary, but all of them point to instability; eventually, data storage decays. It turns out that tape, which is increasingly becoming an archival medium rather than a backup one, is particularly prone to damage because of the way that robotic tape libraries work. In order to access the information that we store today centuries hence, we'll need media that stands the test of time. 

Then, of course, there are the formats and the systems to consider. Microsoft Word might be ubiquitous enough today, but what about in 50 years? 100? Will we understand it enough to read it? And will we have access to systems that we can read it on? PCs are unlikely to be the same - or to exist at all - in a hundred years. How will we run software programmed according to Von Neumann-based architectures on a liquid quantum computer sloshing around in something like a coffee cup, or a DNA-based computing system grown like a plant?    

There will be ways around this, for sure. We'll probably be able to emulate existing systems easily, especially given the incredible computing power that we'll have. And perhaps we'll be able to store exabytes of data on the head of a pin. But that still leaves another problem: storing today's information in a way that will be meaningful tomorrow.

Part of the problem with the incredible volume of information that we're creating on a daily basis is that we don't know which bits of it we'll need to access tens or hundreds of years hence. Generally, archival theory calls for us to store all of our information, in the form that it was produced, but our capacity to produce data is vastly exceeding our ability to keep it all. And because that information is presented in different ways to different people on a minute-by-minute basis, the challenge becomes even more difficult. 

Access YouTube from Japan one minute, from France a minute later, and from the US 60 seconds later. Access it while logged in with a particular account. Then with another. Each landing page will be different. Megabytes of information are added each second, that change the entire database, and the user experience. How do we document that? And how do we begin to relay these nuances to tomorrow's archivists in a way that is understandable?

Harwit was accused of rewriting history in 1995, when he dared to ask questions. But 15 years later, we're rewriting history thousands of times a second, and everyone's will be different. The revisionism is only just beginning.

I teach project management and estimation workshops. Every time I teach estimation, someone asks, "How can we get the perfect estimate?"

You can't. Estimates are guesses. And, if you are multitasking, every estimate you have is wrong. Guaranteed.

But you still need to figure out when things will be done. Instead of estimating how long a task will take, I prefer to estimate how many small things I can complete in a week. And, I make sure I get to done on each task before I take on another task.

One of the problems of estimating large tasks is that we tend to estimate in units that are too large. If you estimate in weeks, you'll be off by weeks. In days, you'll be off by days. In hours, you'll be off by hours. Over the course of a project, even estimating in hours can obscure the actual duration remaining for the project.

Instead of using scope as the base, I use a timebox. Instead of asking, "How long will this take?" I ask, "What are all the small tasks required to complete this piece of scope?" Then I see how many of those will fit into a week.

If you're working with other people, and are using a Delphi method for estimation, you'll discuss your estimate. You'll hear things like "If Danny does it, it's only a 3. If I do it, it's a 5." I always take the upper estimate. Why? Because if Danny is so good, he's not going to be available. He'll have questions to answer or some other task that's a higher priority. I'll do it anyway. And, if I practice doing these tasks I'm not so good at now, I'll get better pretty quickly.

Think hard about whether you want a good estimate or if you want the work done. Estimating at the beginning of the project is often a waste of time. The more work you get done, the better your remaining estimate will be. 

If you want to know how to estimate without using time units, here's how I do it:

For my work, I block out half-day chunks of time. I find that I can do some tasks in that half-day chunk (1, 2, or 3), and finish enough on any one thing that I can safely mark it as done enough and go on to the next task.

Some days, I have tons of little things to do: return calls, make lists, prepare to do something. Some days I have larger tasks: write a blog entry, draft a workshop, write a ton of email. Some days I have quite large tasks: draft 1 of a piece of a chapter, draft 1 of an article, draft 1 of a report.

Most weeks, I have a mix of things that are small, medium, and large. I no longer worry or estimate how long any of these things will take. I know about how many of the small, medium, and large tasks I can finish in a week. I can make my lists taking that into account.

If you are a developer or tester or BA or technical writer or a whatever (don't want to leave anyone out :-), you can do the same thing. Here's my recipe:

1. Make sure you've taken any task larger than a half-day chunk and broken it down into smaller tasks. That's why you see draft 1's for articles. I can write a draft in less than a half-day. I can't finish all the editing and have a great article at the end of a half-day. So, I don't try to do so.
2. Be clear on what done means for a particular task. If you don't know what done means, you can't get there. You'll either "finish" without getting to a reasonable stopping point and then you worry, or you can't finish in less than a half-day chunk.
3. Do just that one task until it's done. Commit to it. Finish it.
   

Now you have a little recipe for getting the tasks done. Here's how you apply it to your estimation. When someone asks how long something will take, you look at all your little tasks. Make sure they small, medium, or large, where large still fits in a half-day. You get no more than 10 half-days in a week. How many of these tasks can you do in a week? Add them up, and there you have your estimation without having to define how many hours a given task is.

If you're part of a project team, and want to try this on a larger scale, I particularly like the Fibonacci series (1, 2, 3, 5, 8, 13, 20) for estimating how large and complex a task is. As a team, use a Delphi approach (everyone gets together and as a group agrees on a number. For me, and when I teach my estimation workshop, any task larger than a 13 means "we have no clue and 20 is as good a number as any other number." When you hear someone is a specialist and can finish something earlier,  take the larger of the two values.

Other folks use t-shirt sizing: XS, S, M, L, XL, 2XL, 3XL. I don't like that as much, because, in my experience, teams don't learn to break tasks down enough, and have too many M, L, XL tasks. YMMV.

Now, it doesn't matter if you work in iterations or not. Take a week. As a group, ask "How many of these tasks can we do in a week?" Discuss the question. Arrive at a number you can all live with. You're done!

Remember that estimates are guesses. They are likely to be wrong, especially if you use time-based units. That's because we are either optimists or pessimists and because we never have ideal hours, days, or weeks. Try this and see what happens to your estimations.