WorldCat is certainly the largest database of bibliographic data on Earth. Probably the universe, but let’s stick with what we know for sure. Among those 360 million bibliographic records, we figure there must be at least a few duplicates. In a database that size, built by tens of thousands of catalogers in thousands of institutions over the course of four decades, duplicate records are an unfortunate fact.
For most of those four decades, OCLC has also been hard at work trying to reduce the number of duplicate records through both manual and automated means. We began merging duplicates manually in 1983 and recently, specially-trained members of the Cooperative have been merging records as part of our ongoing Merge Pilot. From 1991 through 2005, OCLC’s automated Duplicate Detection and Resolution (DDR) software ran through WorldCat sixteen times, merging over 1.5 million duplicates. That original DDR dealt with books records only. We at OCLC were both painfully aware and constantly reminded of this limitation by you, our users.
Between 2005 and 2010, we methodically developed, tested, and refined a vastly improved version of DDR that could deal with all bibliographic records, not just books. Since we implemented expanded DDR in 2010, upwards of 19 million duplicate records have been eliminated. More than two dozen points of comparison drawn from nearly every part of a bibliographic record get parsed, analyzed, and weighed against each other in the process of trying to identify and merge duplicates. Thanks in great part to the reports you send to us about missed duplicates and the occasional incorrect merge, we constantly work to improve DDR’s complex algorithms.
DDR’s intended purpose is to accurately identify and merge records that represent the same bibliographic resource. But the flip side of that is the equally vital identification and protection of records that represent legitimately distinct resources — records that should not be merged.
We need to balance the need to merge duplicate records with protection for distinct resources.
Click To Tweet
In the development of DDR, we have consistently erred on the side of not merging records when we could not be quite sure that we were merging them correctly. To that end, we have purposely set aside certain categories of records—secured them behind a bibliographic barricade – so that they are not even processed by DDR. Because of the nature of the resources themselves or as a result of cataloging practices and traditions, making the proper distinctions algorithmically has proven too difficult for these protected categories: most rare and archival resources, including anything with a publication or creation date earlier than 1801; all cartographic materials with dates earlier than 1901; all SCIPIO records for art and rare book sales catalogs; Digital Collection Gateway records, and all photographs.
When we introduced the improved version of DDR in 2010, we wanted to let users know a bit about how it worked. But even more, we wanted to arm users with the sword of MARC and the shield of AACR2 and RDA, reminding catalogers about the powers built into both the bibliographic format and the descriptive cataloging conventions to make sure that DDR would recognize differences that justify legitimately distinct records.
A Webinar entitled Cataloging Defensively: When to Input a New Record in the Age of DDR was presented twice in October and November 2010, advising catalogers of valid ways to rebuff the attacks of DDR when sometimes subtle differences in resources allow for separate records.
In the years since 2010, Resource Description and Access (RDA) has become a dominant descriptive cataloging convention and the MARC format has changed in substantial ways in order to accommodate it. Questions from, and conversations with, catalogers within the OCLC cooperative strongly suggested the need for more information about DDR and more specific suggestions regarding particular types of materials.
For the January 2016 ALA Midwinter meeting of the Cataloging and Classification Committee of the Map and Geospatial Information Round Table (MAGIRT), I presented Cataloging Maps Defensively. For the annual meeting of the Music OCLC Users Group held in March 2016 in conjunction with the Music Library Association, I presented Cataloging Sound Recordings Defensively.
The responses to these format-specific presentations have been gratifying. The MAGIRT/ALCTS/CaMMS Cartographic Resources Cataloging Interest Group has invited me to present Cataloging Maps Defensively a second time at the ALA Annual Conference in June 2016. In coming months, I intend to create and make available on the OCLC “Cataloging Defensively” page additional versions devoted to video recordings, musical scores, rare materials, books, and possibly others.
We shouldn’t think of WorldCat as a battlefield, but catalogers can use strategic knowledge of MARC, of the descriptive conventions, and of DDR itself to preserve, protect, and defend records that represent legitimately distinct resources.
What are your thoughts on the balance between eliminating duplicate records and “cataloging defensively?” Let us know with #OCLCnext on Twitter.
This weekend, I posted a new MarcEdit update. This is one of the biggest changes that I’ve made in a while. While the actual changelog is brief – these changes represented ~17k lines of code Windows (~10K not related to UI work) and ~15.5k lines of code on the OSX side (~9K not related to UI work).
Specific changes added to MarcEdit:
I’m created some videos to demonstrate how these two elements work, and then a third video showing how to use the Add Field if not a duplicate (added in the previous update). You can find these videos here:
Add Field If Not a Duplicate
MarcEdit’s UNIMARC Tools:
MarcEdit: Batch Replacement using External Criteria
You can get the changes from the downloads page or through MarcEdit’s automated update tool.
Posting to RadCat
I was co-author with Julie Moore of that chapter in the book. Here are my own remarks about Deanna Marcum’s article “Library Leadership for the Digital Age” http://www.sr.ithaka.org/publications/library-leadership-for-the-digital-age/
I have been fortunate enough to meet and spend some time with Deanna Marcum at a conference in Oslo a few years ago, where we both spoke. I agree with some of what she says, but I disagree with more.
I agree that there are major problems with the public using our catalogs. That should be obvious enough to everybody. Still, I will go on to state that people have always had problems using our catalogs, and this can be traced back to (at least) Antonio Panizzi and the deluge of complaints that met his catalog, finally culminating in nothing less than a Royal Investigation (no small thing!). People listed multiple complaints in that Investigation, and although he may have “won” the argument (to put it in crude terms, he wasn’t fired from his post) it didn’t mean that people stopped having the same, serious problems they had complained about when using his catalog.
With the introduction of computing and keyword, many advantages appeared, but the old problems became even worse. Subject headings had always been the butt of many jokes, even among catalogers themselves, but in the keyword environment, they melted down completely. I have tried to demonstrate how subject headings simply don’t work, even for someone like me who understands how subjects work better than any user could ever hope to. (http://blog.jweinheimer.net/2013/02/catalog-matters-podcast-no-18-problems.html) I think we have to admit that not only are the subjects broken, but the entire authority apparatus is broken as well, mainly because users never even see it when they do keyword searches. For instance, how is somebody supposed to know that if they want to look for writings of “Mark Twain” they have to look under multiple forms of his name? You can’t find out that information through keyword, and you can’t do it at all in tools such as Worldcat.
One additional point that I think is extremely important is the very human desire to take the easiest path. This must be seen in relative terms however: if you don’t have alternatives, any path seems normal. As an example, I just returned from a short trip to Pompeii, and ancient Roman steps are much higher than what we are used to. Given the choice, I much prefer modern steps. I suspect many Romans would have preferred modern steps as well, but they didn’t have the choice, so they saw no problem. If builders today started making steps a Roman height, people would scream bloody murder.
Comparing this to catalogs, when the only option was a card catalog that had author, title and subject cards arranged in alphabetical order (with many exceptions!), it wasn’t seen as much of a burden. Of course, people grumbled about it, just as they grumble about anything, but the instant a simpler option appeared, the public stampeded out the door. Expecting them to use catalogs “correctly” today is like expecting people to go up Roman-sized steps. They just won’t do it if they have any option at all. People have those options today. These are facts and none should be surprising.
Another part where I agree with Deanna Marcum is about how the collection has changed. Digital materials available at the click of a button have changed what is meant by a “local collection.” Information is not one bit better or worse just because it has been printed in a book or journal article than if it is available at the click of a button. The reliability of any information source is completely independent of its format. There are massive amounts of incorrect information in our physical collections. (“Chariots of the Gods?”) Also, if an item is digital, it doesn’t matter to the user if the file is located on a server a few feet away, or if that file is on a server belonging to Elsevier that your library subscribes to, or is on the other side of the world in an open-access server. For the user, what matters is that all of them are equally accessible. This has tremendous consequences for library selection.
Where I disagree with Deanna Marcum is what to do about this situation. Some consider (and she seems to be one) that our library catalogs are “broken beyond repair”; that for information discovery we have already lost our users to the Googles, and it is a waste of time and resources to try to get them back (“In the digital environment, our users are more likely to find digital resources through a Google search than they are through searching the library’s catalog.”) but this seems rather hopeless to me. Although we must admit that the catalog is indeed, broken, I do not think that it is broken beyond repair. On the contrary, I think the catalog can be fixed–but unfortunately, catalogers are busy doing something quite different.
Instead of trying to make the catalog work in a modern environment, catalogers are spending their time with RDA and FRBR, assuming that this in itself will improve the situation for the users, although there has been no genuine evidence for it. In any case, the same problems for the users will remain: the authority structures will still be hidden and/or terribly confusing; the catalog itself will still not be any easier for the public to use and will arguably become even more complicated. Adding in linked data, the basic idea seems to be that our catalogs will be included into some other, much larger “discovery tool” that no one has really discussed in any ways other than vague postulations, and the only final product I can imagine is something far more complex than anything we have seen. Plus, the problems of our authority structures I mentioned above will not be solved merely by changing “textual strings” into URIs. Much more will be needed.
Finally, to make matters worse, any practical implementation of any of this will have to wait decades, and the “information-consuming” public will have completely passed over the horizon by then. We don’t even know what’s going to happen 5 years from now. By that time, we will be so far behind that it really will be hopeless.
All this goes to part of the title of Marcum’s article: “library leadership”. To be honest, I haven’t seen much encouragement in this way either, although it isn’t limited to librarianship and seems to be a genuine malaise in modern society. (I am referring to modern political leaders of almost any country, each of which seems to be experiencing its own crisis in leadership)
What’s the solution? Trying to teach everybody how they “should” search catalogs has proven that it simply doesn’t work. We need to change how our catalogs function by going from dictionary catalogs (i.e. browsing alphabetical lists of words, which nobody does today) to something much more modern. I think best would be trying a whole number of very small, measurable steps forward. For instance, how could we make sure that users will find “see also” references for personal authors and corporate bodies? Those references are absolutely vital for users and catalogers go to a lot of trouble to make them. This should be relatively easy to solve. How many ways could it be solved? Other problems could be dealt with later as we learned from this what worked and what didn’t work.
But we need library leaders to see these as problems that need solutions, figure out a plan and get the funding. Unfortunately, library leaders probably agree with Deanna Marcum that “… our users really want—specialized and individualized help when they can’t find what they want in a Google search, access to more electronic journals and databases, on-line reference services, and access to new types of scholarly information—data sets, blog posts, and multimedia resources”–a completely different scenario that devalues not only cataloging, but the entire library project.
Since the publication of DDC 23, we have extensively revised the Table 2 development for jurisdictions of South Africa, at T2—682-687. The Republic of South Africa consists of nine provinces. The provinces were formerly divided into districts, and editions going back to Edition 19 reflected this organization. The 1996 South African constitution replaced the districts with municipalities. Provinces are now subdivided into metropolitan municipalities or district municipalities. The eight metropolitan municipalities represent some of the country’s largest urban areas. The 44 district municipalities are further subdivided into 226 local municipalities.
With so many differences compared to the previous province-district arrangement, former districts are not given in DDC captions, or in including or class-here notes. Former district names still appear in the Relative Index and history notes in WebDewey, however. Metropolitan and district municipalities are not always coextensive with the former districts; history notes explain such cases.
The names of the municipalities are up to date, such as at T2—68467 Harry Gwala District Municipality, which was renamed from Sisonke District Municipality in November 2015. Each metropolitan or district municipality has a dedicated number, or shares a number with another municipality (e.g., T2—6844 UThungulu District Municipality and iLembe District Municipality).
Additionally, seven of South Africa’s national parks were added to including notes, meaning all 22 of the country’s national parks are represented in including notes, class-here notes, or their own numbers. The Cradle of Humankind World Heritage Site was also added to the including note at T2—68222.
Below is a look at one of the updated numbers, T2—68752, in WebDewey, compared to the same number before the update.
Here are two questions you don’t often see next to each other.
While their circumstances couldn’t be more different, I believe that the motivations for both groups are remarkably similar and comes down to four principles: visibility, reciprocity, creativity and authority.
These are some of the guiding beliefs of a group that has been called “The Selfie Generation.” But they are also those that encourage all of us, more than ever before, to share who we are and what we do using inexpensive, omnipresent digital technology and social networks.
You may remember that, back in the early 1980’s, George Lucas’s sound recording standard, THX, would run a short trailer before its movies with the tagline, “The audience is listening.” They were making the point that the audio experience of a film was as important as the visual experience.
Today, however, the audience isn’t just listening. Or simply watching. The audience is doing everything that media companies are doing, often creating content that, even a decade ago, would have been prohibitively expensive and complicated. We’re writing books and articles, making music, crafting games, filming movies, taking photos and linking it all together in a variety of social media platforms.
Or, to paraphrase Pogo, “We have met the artist, and they is us.”
I think that many adults probably equate selfies with a very… immature… kind of behavior. They are ephemera. Meant to be created, shared and consumed quickly and then (maybe intentionally) forgotten. Duck faces. Selfie sticks. Planking. A fad, perhaps, and maybe an unhealthy one.
But selfies, and the young people we tend to associate with them, are part of a much larger social and technological shift. One that is driven by technology and blurring generational boundaries in the way it has erased geographical boundaries.
Selfies represent a social and technological shift that blurs generational and geographic boundaries.
Click To Tweet
Earlier this month, I presented a keynote at the OCLC EMEA Regional Council annual meeting titled, “Post it or perish: negotiating the borders of social proof and authority.” The theme of that event was “The Selfie Generation.” I pointed out that there are four principles that are important to understanding both selfies and much of the work that libraries do within our communities. And these tendencies aren’t limited only to the “selfie generation,” but reach across demographic groups, more and more, as technology has cut across generations.
Let’s quickly review the principles involved here.
Visibility. Our most popular social networks are visual ones: Facebook, Instagram, Snapchat. Telling isn’t as powerful as showing. “Pics or it didn’t happen” is a popular phrase for a reason. It’s part of what psychologists call “social proof,” and it’s important to us all. Whether you’re taking a picture next to someone famous or capturing proof of an important moment, nothing speaks louder than a visual. We’re hardwired to respond to images in a much more visceral way.
Reciprocity. In a 2015 joint study, the University of Texas at Dallas and CNN found that 61% of teens said that when they go online, one of the main reasons is to see if their posts are getting likes and comments. Social is a two-way street, obviously. It’s embedded in the definition. If someone likes/comments on your stuff, you want to do the same for them. Social scientists call this the “Law of Reciprocity.” We want the audience to respond.
Creativity. A key difference between social media content (like selfies) and other kinds of content is that you make it yourself. According to a Common Sense Media report from November 2015, 3% of teens’ time on social media is spent in active creation: writing, coding, making digital music or art. That may not seem like a lot… but it’s way more than TV, isn’t it? It’s part of what makes these platforms so compelling: that we don’t just have to be in the audience, we can be on stage. We have a deep desire to create.
Authority. This is the one that’s most easily related to what we as librarians, scholars, educators and authors do. In the past, because production and bandwidth were expensive, editors and publishers and other “gatekeepers” provided the authority. Now, there is no scarcity of media channels, and publishing is as efficient for one copy as for thousands.
Last October, Instagram – the photo sharing service – celebrated its 5th anniversary. CNN reported on the event with the headline, “Untangling Instagram’s growing web of influence.” They noted that the site had 400 million regular users, half of whom are under 25.
Instagram provides an excellent example of a service people are using creatively to increase their visibility, practice reciprocity, and thereby increase their authority. The CNN article shows how the service is impacting the worlds of fashion, art, travel, food… even activism.
Historically, libraries played (and still do play) a similar “gatekeeping” role to editors and publishers. They curate collections. And we trust that those materials have passed some kind of test for value, appropriateness, accuracy—in short, we trust the authority of the library.
Can libraries fit into this new world, in which authority doesn’t come from scarcity but abundance? We see signs that it’s happening already.
Visibility. Libraries are working with partners through OCLC and other organizations to get their materials into more online services, within the workflows people already use. Examples include “Find in a library” links from places like Google Books and Goodreads.
Reciprocity. Libraries are working to put important, local content online, using services like CONTENTdm. This isn’t just about providing resources—it’s about honoring and promoting the people, ideas and accomplishments of the communities and institutions being served.
Creativity. Library spaces are changing to inspire and enable creativity among users. Makerspaces are cropping up in many libraries. Partnerships with local arts organizations blur the boundaries between library and gallery.
Authority. How can libraries play an appropriate “curatorial role” in a world of infinite links and sites and files and videos and pictures? Linked data may be part of the answer. By providing easily shared, canonical pathways to accurate information, linked data helps connect the library world to the selfie world. Linked data helps turn traditional authority into social proof.
Linked data connects the library world to the selfie world, turning traditional authority into social proof.
Click To Tweet
People still want the same things they always have wanted. They want to be creative, connect with friends and colleagues, and get recognized for their work. While the changes in how this is happening may be scary to some, the motivations are the same. This is great news for libraries, actually. Because libraries are great at helping connect people to a larger world of information, community and success.
We just need to be humble enough to take a few lessons from teenagers with smartphone cameras.
Posting to RDA-L
I also haven’t had time to look at this until only recently. My first question was: who is this for? When I first saw the term: library reference model, I was hoping that it would somehow be aimed at and include reference and other public services so that we could finally discover if the models fulfill their perception of what the users need.
This doesn’t seem to be the case however, and the purpose of LRM is to consolidate FRBR, FRAD and FRSAD into a single model. Then, I guess, Bibframe (if it is ever accepted) will have to be modified again to accept this new, complete reference model; then library systems will have to adapt again (or not).
If nothing else, the terminology in FRBR-LRM will have to change. It is quite disturbing as it swings from words that seem more appropriate for a graduate seminar in philosophy (e.g. res, nomens) to the poetic descriptions noted by Robert Maxwell, an expression defined as “A distinct constellation of signs conveying intellectual or artistic content,” although I suspect that too, relies on semiotics.
It seems as if our grandchildren may have long grey beards when it is all done. But at least librarians will know that after the passing of all of those decades, through the good times and the bad, the public will applaud us because it will be clear that it was LIBRARIANS who had been at the very forefront all along, and together we will survey the new world from the Radiant Heights of Information Retrieval!
Sorry, I couldn’t restrain myself from appropriating old Soviet propaganda language! It’s Friday, after all and a holiday weekend as well.
Happy Easter to all.
Posting to Autocat
On 4/22/2016 6:48 PM, Nathan Rinne wrote:
Thanks for the response – that makes some sense. That said, wouldn’t local institutions, in general, for a variety of reasons, including financial, prefer to go with some kind of default option as opposed to having to decide how each subject is going to display?
This is the really tough part. It’s no secret that I am very skeptical of using linked data in the catalog. What I (and Stephen) have described does not require linked data–there are other solutions that are both much simpler and far cheaper. Still, since the cataloging community is traveling down that path, I think that linked data can be useful toward solving *one aspect* of using authority data within the catalog.
That said, although I can *intellectualize* how the new “heading/card” that I have described can function, I don’t have the slightest idea how it will work in reality, or even if it can. As one example, see an LC record I chose at random: https://lccn.loc.gov/2005910731 (I am excerpting from the record)
Personal name Wilson, Robert Mills.
Main title They also served : wives of Civil War generals / Robert Wilson & Carl Clair.
Published/Created [Philadelphia] : Xlibris Corp., c2006.
LC classification (partial) E628
Related names Clair, Carl.
Generals’ spouses–United States–Biography.
Generals’ spouses–Confederate States of America–Biography.
United States–History–Civil War, 1861-1865–Women.
United States–History–Civil War, 1861-1865–Biography.
This is a fairly normal record and not especially complex. How can using a series of “cards” for each heading work in reality, or it could be that each part of the heading would have a separate card? (i.e. United States would have a card, and Confederate State of America would have another) No matter what, there would be lots of cards here, and it will make the Google example of Confucius look like a baby’s game in comparison.
If not “cards” what else would work? Add to this the facets, that the user will have to be able to search the catalog using the headings, and (probably) do something else to search for information from outside the catalog. That’s one of the ideas of linked data, after all.
Try as I might, I cannot imagine how a record like this, which is normal but already rather complex for a user, can become anything but substantially more complex with linked data. It blows my mind. This isn’t saing that it can’t work, but it will not be easy at all.
So Nathan, while I can intellectualize this I harbor the same doubts as to whether it can work for a living, breathing member of the human race!
OCLC has been working a lot with linked data in recent years, and we have described some of that work at a very high level in this space before. That work continues, but now we are also adding an educational component to that work. Since we want our member libraries to be able to take advantage of all of the linked data that is becoming available—both from us and from the world at large—we want to help library software developers understand the tools and strategies for consuming linked data.
We are at a watershed moment in terms of library linked data. For the past few years, we at OCLC and others have been predominantly involved in the technology as a research and exploration activity. That was important, of course, so that we could come to some clear conclusions and standards before moving into projects that would affect library workflows. We’ve seen a lot of great work done that demonstrates possibility.
Now it’s time to begin making those possibilities real. Much of the most exciting work in library linked data will be done “out there” by the same types of technologists and innovators who began building the early web back when hardly anyone knew what a “.com” was. It will be done by individual librarians working on one-off projects or fun weekend tech demos. It will be done by programmers and catalogers who want to address some specific, local needs of their community.
It will be done by you. And we want to help.
Recently, Karen Coombs, Senior Product Analyst at OCLC, held a very successful pre-conference session about using Linked Data at the annual Code4Lib conference. With 62 attendees, her session was by far the best attended and the participants were very engaged. Given the level of interest in the topic and Karen’s success in putting together a useful course, we will repurpose the content to educate and empower even more library developers. It’s time to move from talking about linked data to putting it to work.
It’s time to move from talking about linked data to putting it to work.
Click To Tweet
Toward that end, over the next few months we are planning a series of blog posts and webinars. The blog posts will be published on the developer network and will precede webinars on similar topics. By offering this series we hope to enhance the ability of library developers to use and interact with linked data generally and with OCLC’s Linked Data resources and services specifically. Two recent posts provide information on working with graphs without a SPARQL endpoint and manipulating output with FILTER, OPTIONAL and UNION. Future posts will focus on other output options, JSON-LD basics and both server and client side linked data consumption. You can register for all three webinars here. Don’t wait… the first, on querying linked data, is coming up April 27.
I’m going to a webinar on library linked data! Are you? http://oc.lc/FiFqIC
Click To Tweet
If you are a library developer, we hope that you will find these educational offerings useful. The more coders who know how to interact and publish linked data, the quicker we can move to a new world that many of us believe is well on its way.
Remember back in the early 90’s when the web was weird and new? When someone would point you to a web site and – GASP! – there was a picture alongside the text! Or where sounds came out of your computer (if you had a speaker hooked up). Or when you filled in your first online form and got a response in email? That’s where we are with linked data. The foundation is there. The initial set of tools has been built. It only remains to be seen what we (and you) will build with them.
Find out more about library linked data:
Certain things are wonderful because they are unique. Artwork, musical performances, memories, the important people in our lives. In these cases, we treasure differences.
That is not true, however, for software development. While a service or a feature may perform a very specialized task, the background infrastructure isn’t helped by inconsistencies. Every time you add a different piece of hardware, operating system, software platform or process, you multiply the number of ways you’ll need to maintain your code, impacting quality and driving costs up.
In the technology realm, these inconsistencies are referred to as “snowflakes.” I like to refer to the process of eliminating these inconsistencies as melting snowflakes. Because, just like in real life, snowflakes may be interesting, but they’re not great for software development—they often make you slow down or slip up when you want to move quickly.
Different tools for different jobs. That makes sense in a lot of contexts. Trying to drive a nail with a screwdriver is unpleasant at best and probably dangerous—and takes a lot longer. In the early days of computer programming, we had lots of tools (hardware platforms), lots of blueprints (programming languages) and lots of different kinds of supplies (data formats). We used them in whatever combination made sense to solve a specific problem for a specific set of users, often within a very specific set of circumstances.
Think of it this way: the tools, blueprints and supplies used to build a small beach cottage for a family of three are very different than those used to build a skyscraper with thousands of apartments. Even though the task—build a place for people to live—seems very similar.
That was, in the “old days” of computing, a feature. This tool, this program, this platform has been optimized for a specific use in a specific environment.
Today we have a situation where almost everyone’s computing environment has been tremendously homogenized…
Click To Tweet
Fast forward to today, though, and we have a situation where almost everyone’s computing environment has been tremendously homogenized because of the internet. It’s as if we all moved from that little cottage to the big city, but many of us are trying to build skyscrapers using toolsets we brought with us from the beach. Imagine how much longer that would take, how much more expensive, and how frustrating.
Too many specialized tools, too many variances in development, too many snowflakes.
When I discuss this subject with nontechnical folks, they almost always get the problem with “horizontal snowflakes.” That is, using different tools to build different applications and services. They can see the benefit of using the same systems and processes across all of a company’s software. That’s because as software consumers, we’re accustomed to thinking about how we use software.
Equally important for those who make software, though, are the environments in which it is created and maintained:
So to complete “Program 1,” you may have to move through a variety of environments in which snowflakes can multiply. For example, if you’re running test code on a slightly different system than that used to do development, you increase the chance for errors that will then need to be ferreted out in multiple places. By making all our environments as similar as possible—by hunting down and removing snowflakes—we can dramatically eliminate downstream errors and improve the velocity with which we write, test and produce quality software.
Which, in turn, means faster response to customer needs, faster quality improvements and faster implementation of improved standards and benchmarks.
OCLC has a very rich history of software innovation and development. In many cases, that meant we were able to develop specific solutions for specific types and sizes of libraries, different library departments and even very exact job requirements.
You can see where I’m going with this, can’t you?
That’s right. With 40+ years’ worth of development experience, we’ve collected a lot of tools. As I said earlier, the ability to develop highly differentiated applications was, until recently, a positive thing. A feature of good development practices.
It’s sometimes easier to focus on the equipment and technology portions of your IT plans. We’ve implemented a new data center strategy and have been doing major equipment and infrastructure upgrades over the past year. Those efforts seem substantial and easy to quantify. But improving our overall software development processes is, in fact, even more important. Because whatever and wherever the equipment is, fewer snowflakes means more speed and better turnaround times for our members.
We want to get you where you’re going faster. And that’s easier on a sunny day and a nice, dry road.