Well now, there's something to get your brain churning. Last week I was at an e-discovery forum and one of the speakers (who was quoting someone else -- I must have had my thoughts on the latest message on my Motorola Q) made that observation. I've probably butchered it, but the point is the same.
So if you think about how some companies handled toxic waster last century, you know that many just dumped it wherever. It went into the ground, it went into the water, it went into landfills. No one cared. There was no real regulation and no real penalty for not taking care of it. The stuff just seemed to accumulate faster and faster. It was expensive to deal with and you couldn't store it forever. And doggone it, it was hard to reduce and make safe.
Fast forward. Email. Sound familiar?
Toxic waste continued to accumulate until people got sick and the plaintiffs' lawyers realized that they had the makings of a bonanza. Then the government got involved. It made some hard rules, forced companies to clean up their mess (and fined them for good measure), and made sure that it didn't happen again. And companies tried to fix things. They went looking for their messes. They fought over who was responsible for cleaning something up. They paid the fines. And some companies went out of business. But most of the problem eventually got solved and most of the toxic waste issues have been dealt with. But then not every company created toxic waste.
On the other hand, we have email. Every company has it. And very few manage it well. So now you have piles and piles of electronic waste all over the enterprise. People stumble on disks in closets. Someone leaves and a manager has thousands of emails to review. People mix business with personal correspondence. Business correspondence takes place outside the enterprise. The stuff is accumulated at nearly vertical rates. And the lawyers are circling. The court system in the United States is starting to take notice. Rules have been written that require companies to be forthcoming about where their stuff is. Some companies have been punished for not producing what they had. And the cost of find and produce this stuff keeps growing.
Now enter greater concerns about privacy. Here's a very similar line of thinking from Cory Doctorow:
"Personal data is as hot as nuclear waste -- We should treat personal electronic data with the same care and respect as weapons-grade plutonium - it is dangerous, long-lasting and once it has leaked there's no getting it back." (Posted in The Guardian.)
One of these days we're going to need a Superfund for all those emails...
Thursday, September 18, 2008
ATR: The Bucket List
Over on the Records Management Listserv, there is a small battle raging. Now in the past, I'd jump in and hammer out a long-winded posting that would drive a whole lot of people batty. So now that I have my blog, well, you'll find something a bit more reasonable to read.
The elder statesman of the profession, Bill Benedon, FAI, CRM got things started earlier this afternoon with this:
"Appears the rush is on to take over the scheduling process with buckets. A few very interesting articles have appeared pushing this concept. I know what it is all about and I'm agin it. But I would like to see a RIM definition of bucket(s). Buckets come in all sizes as we know and at times they can overflow. So you buget-teers out there. Since this is now part of the RIM literature, let's hear a definition. Is this really new or just and expansion of the "series concept" or the "functional" approach to scheduling."
Now no one who has had a run in with Bill will ever confuse him for the kindly grandfatherly type when they have been at odds with him. I say that with all due respect and I know that challenging Bill means that you better be on your "A game". It's ultimately a good thing. So for much of the late afternoon and early evening, while I was still slaving away at the Day Job, a small battle was going on. It was just a small battle, but it was late in the day, so I suspect that the battle will be joined again in the morning.
Bill's original post points out the three major approaches to records retention schedules. Once upon a time, every retention schedule was based upon the record series. This approach goes back to the foundations of records management in the archives field, where description of records down to the document level have often been commonplace. record series are extraordinarily granular and are typically created at the department level of an organization. They can be hundreds or thousands of lines long. They are obsolete as soon as the next organizational change takes place or whenever some new type of record is created. But, in a manual system of paper records, they are an effective way to find a particular record. Unfortunately, they are a bear to keep consistent and expensive to maintain over time.
At the other end of the spectrum, are the "big buckets" that likely prompted Bill's original post. This approach tends to be more in vogue with people who never have to try and find anything or who have never sweated over some legalese to try and determine the proper retention period for something. This approach effectively works from the standpoint that there are only a handful of frequently used retention periods. Records are tossed into a bucket that corresponds to the length of time that the record should be kept. This keeps maintenance to a minimum because no one really ever has to change anything. People will be able to determine how long something needs to be kept. In theory, that could make sense. Problem is, no one really knows. Absent a control to the contrary, most people will keep everything for as long as they can. The others will toss everything as soon as they can. A few in the middle will figure out what is correct. The buckets will also tend to make it very difficult to accurately find anything.
In the middle are functional schedules. An organization is distilled down to the core functions that it performs. Accounting / Finance, HR and Benefits, Real Estate and Facilities, Administration, Law, Manufacturing, R&D, Health & Safety, and so on. These functions avoid matching the business units of the company one for one. In other words, if a company has a consumer division and a business to business division, it really shouldn't matter what is being manufactured or sold at a broad level. The variable here, however, would be in heavily regulated industries where there is likely a significant difference in retention periods for products in the regulated industry and those in an unregulated industry. The benefit to the functional schedule is that it allows the organization to expand and contract without having to perform massive revisions of the retention schedule. The downside is that it still allows a certain amount of choice by the end user and poorly described records are still subject to loss. But the trend seems to be for most organizations to move towards the functional schedule and simplify their retention schedules.
The question is whether or not the end users are in a place to accurately select the right line item and consistently describe the records.
The archivist in me pines for the old days when we had these great detailed lists of records. every department had a nicely customized retention schedule that described just the records in that department. when you wanted a paid invoice, you knew you could search for "Paid Invoices" and the right invoice would be found in a box very quickly. Under the functional schedule, those paid invoices will be in the "Accounting" line item and you have to hope that the person sending the records offsite took the time to indicate that the records were paid invoices from a particular year and organized in a particular way.
But at the same time, if we have any hope of getting our electronic records under control, we have to make things easier for the end user. They are not going to drill down through hundreds of departments and tens of line items to find the particular thing assigned to their department. If the end user can't click through the proper identifiers in a couple of seconds, it just won't happen.
The elder statesman of the profession, Bill Benedon, FAI, CRM got things started earlier this afternoon with this:
"Appears the rush is on to take over the scheduling process with buckets. A few very interesting articles have appeared pushing this concept. I know what it is all about and I'm agin it. But I would like to see a RIM definition of bucket(s). Buckets come in all sizes as we know and at times they can overflow. So you buget-teers out there. Since this is now part of the RIM literature, let's hear a definition. Is this really new or just and expansion of the "series concept" or the "functional" approach to scheduling."
Now no one who has had a run in with Bill will ever confuse him for the kindly grandfatherly type when they have been at odds with him. I say that with all due respect and I know that challenging Bill means that you better be on your "A game". It's ultimately a good thing. So for much of the late afternoon and early evening, while I was still slaving away at the Day Job, a small battle was going on. It was just a small battle, but it was late in the day, so I suspect that the battle will be joined again in the morning.
Bill's original post points out the three major approaches to records retention schedules. Once upon a time, every retention schedule was based upon the record series. This approach goes back to the foundations of records management in the archives field, where description of records down to the document level have often been commonplace. record series are extraordinarily granular and are typically created at the department level of an organization. They can be hundreds or thousands of lines long. They are obsolete as soon as the next organizational change takes place or whenever some new type of record is created. But, in a manual system of paper records, they are an effective way to find a particular record. Unfortunately, they are a bear to keep consistent and expensive to maintain over time.
At the other end of the spectrum, are the "big buckets" that likely prompted Bill's original post. This approach tends to be more in vogue with people who never have to try and find anything or who have never sweated over some legalese to try and determine the proper retention period for something. This approach effectively works from the standpoint that there are only a handful of frequently used retention periods. Records are tossed into a bucket that corresponds to the length of time that the record should be kept. This keeps maintenance to a minimum because no one really ever has to change anything. People will be able to determine how long something needs to be kept. In theory, that could make sense. Problem is, no one really knows. Absent a control to the contrary, most people will keep everything for as long as they can. The others will toss everything as soon as they can. A few in the middle will figure out what is correct. The buckets will also tend to make it very difficult to accurately find anything.
In the middle are functional schedules. An organization is distilled down to the core functions that it performs. Accounting / Finance, HR and Benefits, Real Estate and Facilities, Administration, Law, Manufacturing, R&D, Health & Safety, and so on. These functions avoid matching the business units of the company one for one. In other words, if a company has a consumer division and a business to business division, it really shouldn't matter what is being manufactured or sold at a broad level. The variable here, however, would be in heavily regulated industries where there is likely a significant difference in retention periods for products in the regulated industry and those in an unregulated industry. The benefit to the functional schedule is that it allows the organization to expand and contract without having to perform massive revisions of the retention schedule. The downside is that it still allows a certain amount of choice by the end user and poorly described records are still subject to loss. But the trend seems to be for most organizations to move towards the functional schedule and simplify their retention schedules.
The question is whether or not the end users are in a place to accurately select the right line item and consistently describe the records.
The archivist in me pines for the old days when we had these great detailed lists of records. every department had a nicely customized retention schedule that described just the records in that department. when you wanted a paid invoice, you knew you could search for "Paid Invoices" and the right invoice would be found in a box very quickly. Under the functional schedule, those paid invoices will be in the "Accounting" line item and you have to hope that the person sending the records offsite took the time to indicate that the records were paid invoices from a particular year and organized in a particular way.
But at the same time, if we have any hope of getting our electronic records under control, we have to make things easier for the end user. They are not going to drill down through hundreds of departments and tens of line items to find the particular thing assigned to their department. If the end user can't click through the proper identifiers in a couple of seconds, it just won't happen.
Monday, September 8, 2008
OTR: Traffic Signs
I'm going to have an Andy Rooney moment here.
In the town next to the one in which I live, there is an intersection where traffic laws are violated by the minute. (Go to Google Maps and search for 2 West Burlington Ave., LaGrange, IL and click on the StreetView function. Look at the intersection with LaGrange Rd.) If you are traveling east or west on Burlington Ave., at LaGrange Road, you will find not less than four no left turn signs in each direction. The rationale, in one direction (eastbound), is that turning left would put you stopped on the railroad tracks on the other side of the tracks, or force you to run a red light over there (which is what happens all the time). In the other direction (westbound), there is simply no turning lane and waiting for oncoming traffic would back up traffic behind you unnecessarily. In addition, there are signs (westbound) that prohibit right turns on red and permit right turns on green arrow only. Again, these signs are disregarded with abandon.
Now I have lived in this area for 35 years. The traffic rules for this intersection have not changed in those 35 years. And yet, I can sit and watch people disregard those signs almost every time I go through that intersection.
So I have to ask -- are people just that oblivious to signage or are they just so "me" focused that they aren't going to let a little thing like a traffic law prevent them from going about their business?
And here's another one. The other day I was pulling out of a shopping center parking lot. The entrance has been engineered to only permit a right turn out of the lot -- and prohibits people from turning into the lot at that entrance from the other side of the street. There's no stoplight, so traffic crossing opposing lanes is supposed to go to the next stoplight to turn in. I'm sure that there is a traffic engineering term for that sort of entrance / exit, but I couldn't tell you what it is. (I did find this drawing that is similar.) However, as I was about to hit that exit, some clown comes flying in my exit lane from the other side of the street! And flips me off when I blast my horn at him! Had I been a couple of seconds faster, he would have hit me head on. Guess the No Left Turn and Do Not Enter signs weren't intended for him...
Thanks for obliging me in my Andy Rooney moment.
In the town next to the one in which I live, there is an intersection where traffic laws are violated by the minute. (Go to Google Maps and search for 2 West Burlington Ave., LaGrange, IL and click on the StreetView function. Look at the intersection with LaGrange Rd.) If you are traveling east or west on Burlington Ave., at LaGrange Road, you will find not less than four no left turn signs in each direction. The rationale, in one direction (eastbound), is that turning left would put you stopped on the railroad tracks on the other side of the tracks, or force you to run a red light over there (which is what happens all the time). In the other direction (westbound), there is simply no turning lane and waiting for oncoming traffic would back up traffic behind you unnecessarily. In addition, there are signs (westbound) that prohibit right turns on red and permit right turns on green arrow only. Again, these signs are disregarded with abandon.
Now I have lived in this area for 35 years. The traffic rules for this intersection have not changed in those 35 years. And yet, I can sit and watch people disregard those signs almost every time I go through that intersection.
So I have to ask -- are people just that oblivious to signage or are they just so "me" focused that they aren't going to let a little thing like a traffic law prevent them from going about their business?
And here's another one. The other day I was pulling out of a shopping center parking lot. The entrance has been engineered to only permit a right turn out of the lot -- and prohibits people from turning into the lot at that entrance from the other side of the street. There's no stoplight, so traffic crossing opposing lanes is supposed to go to the next stoplight to turn in. I'm sure that there is a traffic engineering term for that sort of entrance / exit, but I couldn't tell you what it is. (I did find this drawing that is similar.) However, as I was about to hit that exit, some clown comes flying in my exit lane from the other side of the street! And flips me off when I blast my horn at him! Had I been a couple of seconds faster, he would have hit me head on. Guess the No Left Turn and Do Not Enter signs weren't intended for him...
Thanks for obliging me in my Andy Rooney moment.
ATR: ARMA on YouTube
You just never know what you're going to find on YouTube. Looks like someone from ARMA in Dallas / Fort Worth posted a promotional video for ARMA.
Wednesday, September 3, 2008
ATR: Email is so... 1970?
I spent a chunk of time reviewing my email storage recently. I needed a bit more space. I needed to do a better job filing. And I wanted to clean up the detritus of years of email.
But what I walked away with is a sense that email has just made everything bad about snail mail happen much more quickly and without the pain of creating the communication.
In 1970, if you wanted to send a communication to 100 people, you had to type out the memo, then duplicate it in some fashion, then address the memos and send them on their way. It was a slow and expensive process. In the end, each recipient had a unique copy of the memo and could do what they chose with it. Sound familiar? In those thousands of emails that I looked at, I can't tell you how many were replies and forwards. I can't tell you how many appeared to be the same note, sent to a bunch of people, each with a unique reply that led to numerous additional threads and permutations. And each message, each volley, meant another unique document stored across the email platforms of every recipient. Just. Like. Paper.
Email is everything bad about paper-based communications, on an exponentially larger scale. If we are sending the same exact communication to 100 people, why do we need 100 copies of the same document? Can't we just create one copy, place it in a common repository, and let everyone go look at the original? Can't people reply in a manner that allows everyone to see all the replies in a single thread? If they need a local copy, we keep track of the fact that they made a local copy. If they work in another organization, we'll make sure that they get a unique copy for their record, if needed. But they do these things when they deal with the document, not far down the road.
That, to me, is what the promise of this cloud computing thing is all about. We'll see.
But what I walked away with is a sense that email has just made everything bad about snail mail happen much more quickly and without the pain of creating the communication.
In 1970, if you wanted to send a communication to 100 people, you had to type out the memo, then duplicate it in some fashion, then address the memos and send them on their way. It was a slow and expensive process. In the end, each recipient had a unique copy of the memo and could do what they chose with it. Sound familiar? In those thousands of emails that I looked at, I can't tell you how many were replies and forwards. I can't tell you how many appeared to be the same note, sent to a bunch of people, each with a unique reply that led to numerous additional threads and permutations. And each message, each volley, meant another unique document stored across the email platforms of every recipient. Just. Like. Paper.
Email is everything bad about paper-based communications, on an exponentially larger scale. If we are sending the same exact communication to 100 people, why do we need 100 copies of the same document? Can't we just create one copy, place it in a common repository, and let everyone go look at the original? Can't people reply in a manner that allows everyone to see all the replies in a single thread? If they need a local copy, we keep track of the fact that they made a local copy. If they work in another organization, we'll make sure that they get a unique copy for their record, if needed. But they do these things when they deal with the document, not far down the road.
That, to me, is what the promise of this cloud computing thing is all about. We'll see.
Tuesday, September 2, 2008
ATR: What is a Record?
I'm thinking... hard. We had a presentation today on what comes next in the wonderful world of IT and it looks like we may be off to the cloud and this whole Web 2.0 thing. Now I have never been one to chase the buzzword du jour, but I sense a bit of stickiness in the media hype right now.
I've got some ideas about what the new world may look like, but it starts with thinking about records in a slightly different way. The way I see it, a record is fundamentally two things: something that is communicated and something that has a business purpose. ISO 15489 says that a record is "information created, received, and maintained as evidence and information by an organization or person, in pursuance of legal obligations or in the transaction of business". The approach that I'm taking indicates that the record has to be communicated in some fashion, which in my mind implies that it is transmitted to someone or something. So arguably, a "note to self" that is recording by pen on paper and put into a file folder is likely not a record, as such (it may well be evidence, however). And that old bugaboo, the voicemail message, now becomes an object that we're going to have to seriously consider keeping as a record.
So why mess with this definition? Well, in this brave new 2.0 world, we will have to start thinking in terms of objects when we talk about unstructured information. And we will need to think of all these 2.0 tools like blogs and wikis as mechanisms for communications and collaboration for these objects. If you think about it, email is simply a push mechanism for a document that is either the body of the document or attached. A blog is a way to broadcast an object (either passively or actively through RSS feeds). A wiki is a way to collaboratively edit a document. And those are examples with text.
My sense is that, in the fairly near future, a person will create an object for business purposes. Perhaps they have a question about something. They will authenticate themselves and designate the audience for their object (individuals or a group of other authenticated persons). The object will be stored and the audience will be notified that there is an object that they need to review. They will follow a link to a single instance of the object and see how the sender wished to be communicated with in return. Perhaps they want the object edited (a wiki). Perhaps they want a discussion (threaded discussion). Perhaps they have a finished product and want comments around their object (a blog). There are many scenarios. What will be consistent is that the object creator will deliver the object to a repository with information about who should see the object, who *may* see the object, who can edit it, what sort of record it is, and any other attributes or metadata that might be helpful.
Other users will have a browser dashboard that allows them to see a worklist (effectively, what has been pushed to them for information or actual work), a reading list (items that they have subscribed to or placed into ongoing searches, newsfeeds, a calendar, and whatever other widgets make sense for their daily jobs. They'll have something that notifies them of items to follow up on. And we'll have to make some fundamental changes to how we work. When you connect to that object, you'll have to do something. Reading and setting it aside for later will require you to decide when it will resurface for work. The good news (at least in my little fantasyworld) is that once you take an action, that action will be stored in the cloud and Inbox clutter goes away. Search will need to be much more effective.
Perhaps they will have a "presence awareness" window that allows the user to see who is available -- and allows textual, voice or video communications. Perhaps their voicemail will be stored as an object and made available for review.
At the end of the day, the user will need to be much more decisive about what is a record and what sort of record the object is. The user will have to make a few more decisions about what they create and receive. And our "connectedness" will need to be nearly seamless. If everything exists in "the cloud", you have to be able to get there to work.
Records management will need to adapt. We will be in the attribute or metadata business and we will need to work with a lot of other folks to develop processes to authenticate information, ensure security, and ensure disposition. The good news is that we'll have a virtual central file room; the bad news is that the end user will have far more power to decide what to keep and what to throw away. So we'll also have to do more compliance monitoring.
So that's what is in my head tonight, keeping me from my pillow...
I've got some ideas about what the new world may look like, but it starts with thinking about records in a slightly different way. The way I see it, a record is fundamentally two things: something that is communicated and something that has a business purpose. ISO 15489 says that a record is "information created, received, and maintained as evidence and information by an organization or person, in pursuance of legal obligations or in the transaction of business". The approach that I'm taking indicates that the record has to be communicated in some fashion, which in my mind implies that it is transmitted to someone or something. So arguably, a "note to self" that is recording by pen on paper and put into a file folder is likely not a record, as such (it may well be evidence, however). And that old bugaboo, the voicemail message, now becomes an object that we're going to have to seriously consider keeping as a record.
So why mess with this definition? Well, in this brave new 2.0 world, we will have to start thinking in terms of objects when we talk about unstructured information. And we will need to think of all these 2.0 tools like blogs and wikis as mechanisms for communications and collaboration for these objects. If you think about it, email is simply a push mechanism for a document that is either the body of the document or attached. A blog is a way to broadcast an object (either passively or actively through RSS feeds). A wiki is a way to collaboratively edit a document. And those are examples with text.
My sense is that, in the fairly near future, a person will create an object for business purposes. Perhaps they have a question about something. They will authenticate themselves and designate the audience for their object (individuals or a group of other authenticated persons). The object will be stored and the audience will be notified that there is an object that they need to review. They will follow a link to a single instance of the object and see how the sender wished to be communicated with in return. Perhaps they want the object edited (a wiki). Perhaps they want a discussion (threaded discussion). Perhaps they have a finished product and want comments around their object (a blog). There are many scenarios. What will be consistent is that the object creator will deliver the object to a repository with information about who should see the object, who *may* see the object, who can edit it, what sort of record it is, and any other attributes or metadata that might be helpful.
Other users will have a browser dashboard that allows them to see a worklist (effectively, what has been pushed to them for information or actual work), a reading list (items that they have subscribed to or placed into ongoing searches, newsfeeds, a calendar, and whatever other widgets make sense for their daily jobs. They'll have something that notifies them of items to follow up on. And we'll have to make some fundamental changes to how we work. When you connect to that object, you'll have to do something. Reading and setting it aside for later will require you to decide when it will resurface for work. The good news (at least in my little fantasyworld) is that once you take an action, that action will be stored in the cloud and Inbox clutter goes away. Search will need to be much more effective.
Perhaps they will have a "presence awareness" window that allows the user to see who is available -- and allows textual, voice or video communications. Perhaps their voicemail will be stored as an object and made available for review.
At the end of the day, the user will need to be much more decisive about what is a record and what sort of record the object is. The user will have to make a few more decisions about what they create and receive. And our "connectedness" will need to be nearly seamless. If everything exists in "the cloud", you have to be able to get there to work.
Records management will need to adapt. We will be in the attribute or metadata business and we will need to work with a lot of other folks to develop processes to authenticate information, ensure security, and ensure disposition. The good news is that we'll have a virtual central file room; the bad news is that the end user will have far more power to decide what to keep and what to throw away. So we'll also have to do more compliance monitoring.
So that's what is in my head tonight, keeping me from my pillow...
OTR: Where Did All the Computer Books Go?
So here's a new feature, "OTR". OTR means "Off the Record", which will be does for topics which have little or nothing to do with records management. Might be opinion, might be a musing... whatever. I've had a few of these along the road, but I'll label them going forward to match my other posts.
I have a reading habit. Actually, I have a book-buying habit. I chain-read. I'll have three to five books started at any given time and often never get around to finishing most of them. I'll glean out some interesting stuff, set the book aside, and pick something else up. I generally will pick up a bit of mind candy (something in the Tom Clancy genre) for trips away from home. I'll see an interesting business book, and give that a run on the airplane. Lately, I've been dabbling in history books -- several on Lincoln and more on Chicago history, even picking up a paper-bound set of Bessie Louise Pierce's History of Chicago.
But I've always been a sucker for computer how to books. Lately, it has been various test-prep and "body of knowledge" books for some certifications that I'm considering in my new areas of responsibility. If nothing else, they point out the competencies that I need to strive for.
Anyway, when I stroll to the back corner where you find the computer books these days (usually hard by the business books), I've noticed fewer and fewer linear feet of computer books. And the ones that are there are looking long in the tooth. You get a smattering of program-specific manuals, plus a few books for various computing languages, a bit of theory, some security stuff, and a couple shelves of general computing books. Ten years ago, they didn't have enough shelf space! Could it be that we're all experts now? Or is do-it-yourself programming a thing of the past? Or are all the answers on the Web?
I'm guessing that the dot com bust has a lot to do with the relative shrinkage here. The demand for people to learn Web-programing and website design from a book has declined. You get trained more formally now.
But it is still amazing.
Back to thinking about cloud computing and this whole "2.0" thing. Steve Bailey's book should be on its way from the UK any day now. More to come.
I have a reading habit. Actually, I have a book-buying habit. I chain-read. I'll have three to five books started at any given time and often never get around to finishing most of them. I'll glean out some interesting stuff, set the book aside, and pick something else up. I generally will pick up a bit of mind candy (something in the Tom Clancy genre) for trips away from home. I'll see an interesting business book, and give that a run on the airplane. Lately, I've been dabbling in history books -- several on Lincoln and more on Chicago history, even picking up a paper-bound set of Bessie Louise Pierce's History of Chicago.
But I've always been a sucker for computer how to books. Lately, it has been various test-prep and "body of knowledge" books for some certifications that I'm considering in my new areas of responsibility. If nothing else, they point out the competencies that I need to strive for.
Anyway, when I stroll to the back corner where you find the computer books these days (usually hard by the business books), I've noticed fewer and fewer linear feet of computer books. And the ones that are there are looking long in the tooth. You get a smattering of program-specific manuals, plus a few books for various computing languages, a bit of theory, some security stuff, and a couple shelves of general computing books. Ten years ago, they didn't have enough shelf space! Could it be that we're all experts now? Or is do-it-yourself programming a thing of the past? Or are all the answers on the Web?
I'm guessing that the dot com bust has a lot to do with the relative shrinkage here. The demand for people to learn Web-programing and website design from a book has declined. You get trained more formally now.
But it is still amazing.
Back to thinking about cloud computing and this whole "2.0" thing. Steve Bailey's book should be on its way from the UK any day now. More to come.
Subscribe to:
Posts (Atom)
