Methods for Evaluating CMS and ECM Platforms

I’ve been evaluating nearly a dozen different CMS and ECM platforms, both OSS and commercial, for a little over a month to support an upcoming project. The experience has been very interesting, especially in regards for the need to carefully test the platform programmatically and in requirements definition.

A “Content Management System” and an “Enterprise Content Management” platform have a few important characteristic differences. Most CMS vendors focus of producing a platform that acts as both a web site framework and a secure document repository. The focus in this case is more on the the website than the document repository. ECM vendors focus more heavily on the document repository, methods for accessing it and may have some limited web platform support.

Security and search functionality are critical components in both platform types, though their goals are incredibly different and the implementations profoundly impact performance. The goal of security is to filter out content that the user may access from the general content. Search lets the user search his accessibly pool of content for specific keywords, dates and document characteristics.

Dynamic content types are also a pretty common feature. This is merely the ability to create a database representation of the content item (aka file) and attach a series of metadata fields. You may want to create a “Header” document type that goes at the top of all content pages. You may also want to have several different header documents that vary in some definable way and you may want to rotate through them using some criteria that matches the user’s profile. You could accomplish this by creating a custom header document type and associating a series of keywords that would be used as search criteria for matching a header to a user’s profile.

Full text search and document conversions are somewhat common too, especially in commercial applications. Full text search can search within Word, Powerpoint and a number of other document types. The document conversion feature converts a source document into a completely different format, such as converting a Word document to PDF or HTML.

Workflow is another common feature. It provides the automation necessary to ensure that all those people that must review a document have done so. This is similar to a bug tracking system which changes the owner of a bug when the resolution state changes. Like the bug gets automatically reassigned to QA when a developer marks the bug as fixed.

The origin of these two technologies is relatively interesting. ECM platforms predate the mass adoption of the web. There are 15 year old ECM platforms still being sold, though their names have changed. The focus of the ECM is more toward document management at the desktop while CMS is focuses on web delivery.

ECM is very similar to a source control system such as CVS, SVN and VSS with rich search, workflow and security features. User’s check documents out of the system when editing and then perform a check-in. The desktop integration is often tight, to the point where it may directly integrate with Windows Explorer. Version information, author and revision information are all tracked upon check-in too. The only noticeable difference from most typical source control is that ECM relies on file locking when editing.

ECM platforms often have a very extensive API for integrating it with a number of different languages and applications. Some have native language support and a web services interface. As a result, an ECM is much more of a back-end application similar to a database.

ECM also has extensive security that can map down to individuals within a corporations organizational structure. Sharing documents and restricting access to the right people is usually pretty important. The ECM platforms generally provide access control lists or similar mechanisms. However, the ECM implementation deals with very large volumes of files, like several hundred thousand to several million distinct documents with multiple revisions. Security can really kill a large system’s performance yet many ECM vendors perform very well. They made security and performance a priority.

CMS platforms are more focused on document consumption and usually have a smaller scale. This is not to imply that a CMS can’t handle a million documents. Throw enough hardware at a problem and you can solve anything. However, the goals of most CMS platforms is not as grand as the ECM.

A CMS may still have some measure of workflow, security, back-end and API support but it is far more limited than an ECM. The big difference is that the ECM may include a mediocre customizable user interface that you supposedly would expose to external users while the CMS has a highly customizable front-end that actually looks good.

Security though is often an after-thought or highly limited. Drupal and Joomla! have very limited notions of public, private and registered-user content but you have to install a plug-in to get a richer ACL structure. The problem is that then search and security become separated such that the search results must later be filtered by security (or visa versa). Security strategies that perform these two distinct security operations are often pretty slow. The performance hit is hardly noticeable if you have just a few dozen documents though but get a few thousand or million and you are pretty screwed.

The ECM platforms unify search and security, sometimes resulting in a single query being passed to the DB, which requires less ECM code executing and gives you faster results. This is a generalization of course, there are more than a dozen ECM vendors out there and each have different performance characteristics, but all are geared toward large repositories with complex security schemes.

Again, the goal of the CMS is to present content while the ECM is focused on managing it. The CMS UI is often highly customizable through mechanisms like skins, themes, and in-application UI editor functions. There is also a notion of communities, so depending upon your login you get dropped into a different community which has a different look and feel than other communities on the same server. The CMS may expose deeper enhancements by letting the user modify the actual source of the CMS or through a plug-in model. ECM’s sometimes expose a kind of cheesy custom scripting language that sort of works but it is really limited and primitive when compared with the ability to alter the source of the CMS.

Something important to note is that while CMS and ECM platforms are competitive, they are also complementary. It is often easy to modify the CMS to work with the ECM. The effect is that document loading, search and some security are delegated from the CMS to the ECM. The work is non-trivial, especially if you must expose a security management UI to the web user. This UI would have to merge the CMS and ECM models and almost certainly must be custom written. Still, that’s a lot less work than writing an entire CMS or ECM. The resulting application has the UI and user management features of a CMS and the strong document management of an ECM.

The evaluation process of a CMS or ECM is obviously requirements driven. Specifically, you need to have a good idea of the number of documents and the security model you need to support. Failing to figure out these two requirements will lead you to selecting the much less expensive and more impressive looking CMS platforms. Why? The CMS platforms perform very well with small numbers of documents and simpler security models.

The evaluation process is pretty straightforward but your order of operations and methodology should vary according to your requirements. The model I followed was similar to this:

• Preparation
• Get the number of documents that the final implementation would support.
• Understand the security model from a business perspective.
• Download a variety of CMS platforms.
• Download or get a trial version of the ECM platforms. Note: Most ECM platforms are expensive and are generally not worth the hassle of evaluation until you have eliminated the OSS CMS platforms.
• Write a lot of code to test the API features.
• Evaluation
• Build a command line, parameter driven, application to upload a collection of content items. The application should track the time it takes to upload each document. Dump the timing data out in CSV form so that you can load it in Excel and verify that you do not see a significant linear performance degradation.
• Upload thousands of documents in a flat folder and broken up into folders. For example, upload 1000o files into a single folder and then create 10 folders and upload 1000 files into each. You may see significant performance differences between the two schemes. It may also be worth while to create 1000 folders and add 10 documents to each. Be sure to check when the file actually becomes available. Many systems perform an indexing process against the keywords and sometimes the content itself, which can delay the availability of the content item.
• Add the ability to upload documents and associate one or more keywords from a list you specify. Test the time for the upload process and how long it takes before the CMS existing search functions can find the content item by keyword. You also are testing how long it takes for a search operation to finish.
• Add security binding features to your document upload tool that follows the model you think you may have to implement. Be sure to create a truly representative model in terms of users and number of security descriptors your final application would use. Generally, creation of security groups, ACL’s or whatever the security mechanism is pretty easy to do manually though it is tedious. You are again testing the upload time, keyword time, security, indexing and user specific search for content items that the user should and should not be able to see. Remember that the speed of the results of search in this system will be representative of the actual production system.
• Do another upload of content using 2 or more machines. Not all CMS and ECM systems actually handle multiple clients performing updates. You are checking for the performance degradation as a result of multiple uploading tools. You are also checking that the CMS does not crash nor corrupt your document database. This sounds like it wouldn’t be a problem, however, some CMS platforms actually don’t handle this scenario.
• Create a command line application that can perform document search by keywords and update and delete documents. This is a very crucial component as you want to measure search operations. You will also want to modify existing documents and metadata to verify that indexing and document availability work correctly. You will also need to check that deletions work as some systems actually don’t handle large deletions all that well and can corrupt your database.
• Assuming that you’ve done everything mentioned above, try upload a very large number of documents, hundreds of thousands over the course of a weekend or a vacation. Large document uploads and the resulting indexing process may take a very long time. This will help you to gauge system requirements and give you an idea of how long a large import on a production system may take.

These tests sound incredibly tedious and lengthy, arguably they are excessive too. It depends on how critical the CMS or ECM is to your company. A CMS or ECM can become a core component of your application and it should be able to scale up to your production level requirements. The challenge is that you may not find out about the platform’s limitations for months, or even a year after it has gone into production. By that time it is too late to make major changes beyond getting more and more hardware to “solve” the scalability problem. However, early testing can eliminate a lot of these problems.

Addendum

I’ve included a list of various CMS, ECM and portal platforms. I’m including portal systems because the often include CMS or ECM functionality.

1. Portals
• Liferay
• JBoss Application Server
• Apache Portals
2. CMS
• See OpenSourceCMS.com for an exhaustive list.
• Drupal
• Joomla!
• Mambo
• PHP-Nuke
• Plone
• XOOPS
• Zope
3. ECM
• Alfresco
• Apache Jackrabbit
• EMC Documentum
• IBM FileNet
• Interwoven TeamSite
• Microsoft SharePoint
• Oracle Universal Content Management
• Nuxeo

Commercial Software and the Useful Salesperson

It’s the Friday before Memorial Day and most of it was spent evaluating a commercial ECM’s (Enterprise Content Management) API. It has been a very long time since I’ve been able to bang away at a commercial API and see how it does. It was really nice, exhilarating may be pushing it, but it was really nice.

It was nice simply because the API and the samples were documented. Most of my friends and colleagues love OSS but we all have the same complaint: the documentation sucks. I end up particularly annoyed whenever I have to use a new OSS major component framework at the scale of Mondrian or Jackrabbit. They are big, powerful, really useful and the documentation can be pretty weak. Even established platforms, like Liferay, have terrible documentation but they are cheap so developers use them.

I sometimes think I use OSS platforms for a different reason: I don’t like talking to sales people. I don’t like talking to really any salesperson. It doesn’t matter if you are an articulate, friendly, genius of a salesperson who is really trying to solve my problem rather than fill a quota, I still don’t want to talk to you. It’s the adversarial nature of the sales process where I must negotiate the price or go through an extensive evaluation process such that I get pinged every few hours about how it is going. I don’t want that kind of contact.

It turns out that I needed all that contact. There were areas of the documentation and the API that were not as thoroughly described as one would hope. The salesperson, while it felt invasive, actually got me the information and made it easier to evaluate his platform. All that contact kept me from banging my head against the desk or getting frustrated that the documentation was weak in those few areas.

As I said, I was looking at a big ECM package and had spent a lot of time trying different applications both commercial and OSS. The OSS ECM platforms had an advantage that they were initially inexpensive: no licensing cost but I could get support services. The downside with all of them was that the documentation was always weak. This is especially problematic if you plan on using the ECM has a content repository for a website.

First, why would you ever use an ECM for a website? Some people have systems that require an elaborate editorial workflow that has many people editing and reviewing content until it ultimately gets published. A good workflow system makes content available to the appropriate person as soon as the upstream person finishes his task. A writer finishes some content and passes it on to the tech editor who makes some adjustments and then passes it to the copyeditor. The active editor relinquishes control of the document and then the next person gets notified and takes over. Its not very different from a bug tracking system and changing a bug from “open” to “fixed”, which may result in control of a bug moving from the developer to a QA person, who automatically gets a notification. The workflow streamlines the publishing process.

Great ECM platforms provide a long list of features like security, which I hate writing because it’s a subject packed with pitfalls related to performance. Security almost always negatively impacts performance. It’s a gate between you and the content so its going to slow you down much like the TSA guy making sure you have a boarding pass.

Security is often not at the front of everyone’s mind when working with an ECM. Most people have a hard time figuring out what content needs to be simply published or shared. Complex security models deal have a variety of security domains or contexts which determine the access to the content item.

Here’s a good example: let’s say you are building a course management system like Blackboard and you need to build a system that allows a user to be a Teacher’s Assistant in one class and a student in another. The two courses may share content items. In one case the user should only see the content item according to the rules for students while in a different simultaneous context the rules are different and maybe more permissive. Writing a context sensitive content security layer is not difficult, however, writing one that performs well and works with search is challenging and time consuming.

Back to the evaluation process. The salesperson kept bugging me and I was busy looking over documentation and building test cases. I was losing time conversing with him rather than evaluating the ECM. So I decided to write a long list of technical questions that only a consultant would know the answer and thus give me some free time to work.

No dice: he got back to me in an hour letting me know that a consultant would be sending me the answers. Two hours later I had the answers along with sample code. So I wrote a follow-up, something deep and long winded like “given the following requirements, show me the code that would implement the corresponding security model.” Ha HA! I had him now! It would require design now and that was pretty time consuming. I now had plenty of time to finish my evaluation.

Yeah, that turned out to be a pointless attempt. These ECM companies have done these system a hundred times over. A boilerplate implementation showed up two hours later. It had everything, even really nice queries and documentation references. I was annoyed because now I was being distracted with code that I had asked for that would make my life remarkably easier and let me evaluate the product faster.

Wait, did I just say that? Am I really annoyed that they actually went off and wrote a very large portion of the code I would need to integrate the ECM into my product following my business rules? Does my evaluation still matter?

Ten minutes later I was beaming. I still had some evaluation work, like testing how much content can go into the system and how long before it will become available. The big benefit was that I had a clear template on how to do the integration. I could just make the minor changes to their layer and try it in the product itself. Shaved off weeks of stumbling around hoping that my implementation was right. That was hugely beneficial to the product and the company.

The evaluation process was clearly streamlined thanks to the salesperson that I didn’t really want to talk to. I feel a little conflicted.

Working Hours

A forty hour work week is 2080 hours of work per year or 260 8-hour days. A fifty hour work week is 2600 hours of work per year or 325 8-hour days. A sixty hour work week is 3120 hours of work per year or 390 8-hour days. Working 8 hours a day, seven days a week is 56 hours of work per week or 2912 hours per year.

There are about 8765 hours in a year according to Google. Sleeping the average 7.5 hours of sleep per night takes 2737.5 hours per year.

The forty hour work week leaves a person with 3947 hours of time remaining for other activities. The fifty and sixty hour guys have 3427.5 and 2907.5 hours of time remaining, respectively. That's almost 10, 9 and 8 hours of free time per day, respectively.

When the hours are typed out in that way it would seem as though one could easily balance work and life into neat boxes on a Gantt chart. A block for 7.5 hours is allocated to sleep, 10 hours to non-income generating activities and the remaining 6.5 hours are all about work. To be clear, that last bit assumes that you work 7 days a week 6.5 hours per day, weekends are simply removed from the equation entirely.

Let's consider that same Gantt chart with weekends. The hours become 37.5 for sleeping in a 5 day work week, 40 hours of work in a week, and 48 hours for the weekend leaving 42.5 hours of free time in the work week or 8.5 hours of free time per day. The fifty hour guy has 6.5 hours of free time per work day and the 60 hour guy has 4.5 hours of free time per work day.

"Free time" is a loaded term, it really means non-income generating time. Out of that time comes activities like eating, bathing, cleaning, commuting, shopping, kids (if you have them), other maintenance activities and recreation.

Now these stats may sound a little unlikely: how many software engineers really work more than 50 hours a week? Well, according to the Bureau of Labor Statics, a branch of the U.S Department of Labor, 17% of software engineers in 2006 were putting in more than 50 hours per week.

There is a famous survey from 1996 of lawyers that asked whether the surveyed attorney would take a 10% pay cut in return for 10% more free time. Attorneys can have incredibly busy lives depending upon the kind of law that they are trying to focus upon. A 50 or 60 hour week can be very reasonable and in fact 37% do. But how many would trade the long hours for less pay? 84.2% of attorneys in one survey would love to slash their pay in favor of more time off.

One aspect of software development, especially early in one’s career, is to work a lot of hours on a lot of projects to get exposure to as many technologies, algorithms, design patterns and styles of software development. All this exposure in the early years can be beneficial in a similar way as an attorney or a doctor being packed full of information during their job’s rights of passage. We have no more or less a difficult and thought requiring job, though we usually can’t account deaths to our mistakes.

There is a point of diminishing returns though. How long before a new developer starts to build the same components over and over again? EJB’s are an example of a technology that nearly every Java developer has implemented a few times and then understands the underlying issues and difficulties. Are you going to learn very many new insights if you keep writing dozens more? Does the work stop being one of new learning and become rote repetition?

It is entirely possible to get a 40 hour work week but it usually comes with a price. Bigger companies and non-profits often require fewer hours than small companies and startups. The downside is that there is far more bureaucracy, slower schedules and sometimes less innovation. On the other hand, there is a push for greater software correctness, design and process. Startups are often not so good on the design and process side of things because they are in a rush to get their product out the door so they can have income. That is only my opinion on design and process, though I’m pretty sure I could find a survey to back that up.

Bigger companies do not necessarily pay any better or worse than other companies, however, their option packages are generally small and irrelevant. Big companies are often public companies too, but a public company can only sell shares at a small discount or hand out a relatively small number of options. The difference is that they are worth something, but the likelihood of becoming a millionaire at a public company as an engineer is pretty slim.

A startup may give a pretty sizable number of shares to its early employees which results in a chance at making a pile of money. The downside is that it is very likely that the options will be worthless as only a very small number of startups go public or are bought out at a profit.

Option packages and employee stock option programs (ESOP) at big companies are usually a good deal. An ESOP is usually discounted so you buy at say 10 to 15 percent below market value, which means you can often flip the stocks, rather than hold them, and get a great return on your investment.

There is an important distinction though between big companies and small companies for senior developers. Big companies can afford to pay well beyond small companies for senior developers. By senior, I mean developers with more than 15 years of development. These developers often top-out the salary range in small companies, while large companies may have significantly larger salary caps.

Salaries alone do not motivate developers, project complexity and responsibilities are often very important for attracting developers. That’s obvious though, pay a creative person a lot of money to do a boring and repetitive task and he’ll still quit. It is simply a matter of time. Give that same developer an interesting job and he will quit too, but he may stick around for years.

Free time comes into play when a developer reaches a point in his life when he is happy to trade salary for free time. Going to a big company or a non-profit may result in an initially lower pay level but much more free time than the average startup. The questions are where are you in your career and how important is it to be able to other things than work?

Some developers look down on these conversations, and interestingly enough, so did the partners of various law firms mentioned in the survey. The complaint is that good lawyers have to love the work and so they want to put in the extra hours. This is what separates the average lawyer from the great lawyers, accord to some of the partners. It’s the level of commitment, not necessarily the actual contribution or quality of work that mattered.

I think we see something similar in the software engineering. There is a “keeping up with the Joneses” attitude related to hours worked. “Land of the overworked and tired” talks about a situation in DC during the summer in which office workers all were dressing up for work because everyone else was doing it. The unspoken communal rule was to dress up and so everyone did it.

We see this in our own work places too. Hours-worked is a great example where people put in really long hours because everyone else is doing it. The problem is that quality of work and start time can become irrelevant in measuring how good of an employee you actually are. Consider that a developer shows up at 6 in the morning and leaves every day at 4. He’s been at the office for 10 hours. Compare him to the developer working from 10 until 7. The other developer has been at the office for 9 hours. A great manager will see the difference and acknowledge that the early morning fellow is really putting in the hours. A mediocre manager may miss that entirely and see the developer working into the evening as the more committed.

However, it is unclear who is actually more productive. It could be that the person with the shorter workday is producing more bug free code than the person putting in the additional hours. It could be argued that a person working long hours is not working as efficiently as a person working shorter hours. It could also be that the longer hours person has been assigned much more work. It could be that the longer hour person is goofing off more or less than anyone else. It’s not possible to tell which is the better employee from hours worked at all. It’s a bad metric.

An argument for working longer hours is to get a promotion, better projects, learn something new, avoid some other activity, get ahead of schedule and as an attempt at getting more salary. The positive is that you may be more productive and making a valuable contribution to the company. It’s really important to love the work and derive real pleasure from it such that the work is its own reward. The negative is that people may not notice or care and thus the positive feedback and esteem that you were hoping for may not occur.

There is a risk that once you work so many hours voluntarily that it can become an expectation. Consider that if you work a 55 hour week every week that eventually your task assignments shape themselves around that schedule. Let’s say that you always get 40 hours of task assignments but work 55 hours. You exceed expectations by accomplishing an additional 15 hours of work on your own initiative and applauded for it. The problem occurs when you are tasked 55 hours of work the following week. At that point you have a new bar to reach each week. Others may still receive 40 hours worth of work though. Now your longer hours are expected but no one else is working as hard as you. Your peers are working 28% less than you and you are getting paid the same as if you were working 40 hours. In theory, the company may reward you for your efforts at review time.

Small companies generally require more hours than larger companies as mentioned a dozen or so times so far. You get better pay depending upon how far the company has come and you may work on something really interesting. The issue of making more money is that it often comes with some kind of externally driven status. You get a slightly neater watch or an expensive car. You get to save more money or have a snazzy couch. The time you are expected to work could easily be 50 hours a week but most companies still go into crunch. How long that crunch lasts for is important.

A crunch in a small company may mean working the 8, 9, 10 or 14 hours a day for 5,6 or 7 days a week. Compare that to a crunch at a company that requires only 40 hours a week. There may very well be a serious issue with ordering people to work the really long hours at a big company. They may raise the hours to 50 or 60 hours too but you started at a much lower number of scheduled hours per week.

In the small company we had a person doing the 2600 hours a year and then working more hours because of a crunch. In the big company, we talked about a person working 2080 hours a year and then raising because of a crunch. No matter how you slice it, the person at the 40 hour a week job is still working fewer hours generally and so has more free time.

There is this steady drive to make more and more money and the easiest way to accomplish that is to hitch up to a small company and work the additional hours. At some point you can look at the salary and ask whether they are paying so much because you are an incredibly skilled developer or because they are compensating you for the additional hours.

There is a moment when your life turns and you realize that you have missed too may weekends, summers, seasons and years. That the big money stops being so worth while and that all you really want is to spend some time barbecuing with family and friends. At that point, maybe it’s time to take fewer hours for less salary and do what so many attorneys wish for.

Ruining a Nice Day

I’m going outside of software development on this one. Sorry, but I got to do it.

I read pretty much everything Seth Godin posts and agree with a lot of it. There is a kind of optimism in his writing that nearly always brightens my day. He’s also pretty chatty, he’ll argue with you via email if you challenge him or are just curious about something. His standards are high too, which is always refreshing when you hear someone talk about their need for great quality and customer service.

Today I read “Sucking all the juice out” where he makes the argument that we need to remove roadblocks to creativity and innovation. I really can’t disagree with him that we need the ability to be daring and do interesting things. We really need to be able to challenge our readers or users with interesting ideas and not bland it out or dumb it down. So many software products have their user interfaces made so simple that a drunken chimp could run it even though it may add unnecessary steps or operations in an effort to keep things simple.

Installation or process wizards are a great example of the simple UI where the wizard may have a single input element on each step. You may have 10 steps to input just 8 UI fields. The missing 2 steps are the welcome and finish steps. Those 10 steps could be narrowed or reduced to a single dialog too. We keep it simple and sometimes too dumb. Power users get annoyed at the wizard concept, but we (software developers) typically don’t write for the power user.

But that’s not what struck me about his entry. The above insights came much later. I was preoccupied by a different notion entirely and one that really annoys me. “Annoys” is too weak to describe the the state of mind I was in. I was in a foul mood for most of the day over the writing of an individual.

He wrote that a copyeditor did her work very well and in executing her job, she ruined his work. He felt that her job was the fault: that her job required her to ruin his work. Before continuing, please do read his entry, what he says and how he says it is important.

What bothers me is simply that no one ever wants to hear that their job is an intentional spanner in the cogs of the world. No one wants to hear it that their purpose is to remove the spice from life. The insult to the injury is when this information comes on Friday morning and you know you have to work with the guy on Monday.

I could imagine that this individual got a few calls from people asking “Hey, did you see Seth’s blog today? What’s up with that?” I can also imagine that an otherwise good day went promptly down hill from there.

Copyeditor is pretty entry level job, a lot like a tech support person. A copyeditor fixes grammatical and spelling mistakes. They sometimes rework sentences and paragraphs to improve clarity. They often do a pretty good job of it too. One can argue that the editing process mitigates the artistic license of the author and changes the lyricism and flow of the text and the conversation. One can also argue that great writers don’t need sentence fragments, odd word order and other gimmicks to write engaging and thought provoking works either.

Tech support people are a similarly maligned group of people in that callers are incredibly annoyed when the tech support person fails us and some people are even more annoyed when the support person solves the problem. I was a tech support guy for several years during the early 90’s and have several interesting tails of users working on a problem for more than a week and finally giving up by calling tech support, where the support person solves the problem in under 5 minutes. It does drive some people bonkers when an entry level tech support guy succeeds at fixing something the caller has failed to accomplish. Sometimes the caller is even hoping that the tech support person will fail as it is some kind of vindication.

There are a lot of jobs that may be seen as tedious or beneath us that still need to be done. We see a lot of people do a terrible job at them too. We run into the sales clerk that reads the sign back to us or announces obvious physical characteristics about products after asked specific questions like “what are the differences between these two washing machines?” We experience the bank teller that complains when we use incorrect terminology rather than just correcting the mistake and finishing the transaction. We deal with the kitchen installer that argues that “they don’t make mistakes like that” until confronted with pictures that clearly shows they forgot to cut the hole to expose the existing electrical outlet in the back of the kitchen cabinet. The barista that is more interested in getting the line to move than in making a cup of espresso worth standing in line for. The BBQ joint that puts chicken breast on a sandwich with some sauce and calls it “pulled chicken” (pulled out of the freezer maybe). We see mediocrity, or just bad work, nearly every day to the point that great work is sometimes seen as the remarkable edge condition.

While Seth may argue that the job is the problem, the person that he works with might be sitting there feeling pretty low. She worked hard and was met with a line like “If they have licenses for copyeditors, she should have hers revoked.” It bothers me when the well-respected, and well off, treat colleagues with contempt for their good work.

Damning her with faint praise by saying her job is the problem, not her work is simply ridiculous. He has written so many books at this point that he should know how to work with a copyeditor and know that their job is to make the author and the publisher look good. Her job is to keep the focus on the content rather than the mistakes. I doubt she went home happy and I’m pretty sure Monday was a hard thing to face.

So now I close with the simple notion that many of us are really lucky that our jobs and lives panned out the way they have so far. We should not think ourselves to be so great that that we perceive ourselves to be infallible. We should be thankful that there are people willing to check our work and to make us greater as a result. When those errors occur, those differences of opinion, we should work to show our side and present our changes to the person that failed us rather than whining to the world.

And before you ask, yeah, I bugged him about it and I didn’t like the results so here we are.