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.

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.