Programmer Musings

Interesting Ads

The company SourceGear makes tools for software developers, mostly in the version control area. The company's founder is Eric Sink. Based on his blog and book, Sink seems to understand both business and technical issues.

In 2007, I saw a reference to their new advertising campaign styled as a comic book. At the time, they had t-shirts made featuring the villain The Evil Mastermind. The shirts looked amusing and the concept seemed worth a shot. I had seen similar ads before and they seemed okay.

I've been seeing the ads all year in programming magazines, and I admit they're good and really different. I've liked the way they use the Evil Mastermind to point out some of the inane non-technical hurdles we as developers need to jump through. They also have their t-shirt promotion running again (still?). If you are willing to meet TEM's demands, you can have a t-shirt for free.

So, here I am, paying for my shirt with an action picture of me.

Anyone who knows me knows how much I hate being in a picture, but this was worth it.

Since I don't currently work in the Windows realm, I can't really say anything about their software; but the ads are great.

The IP Goose, revisited.

A couple of years ago, I wrote in The IP Goose about some effects that too strict an IP policy can have on developers. In the intervening two years, I've had some other insights that I believe are important.

First of all, I stand by my original essay. Companies should be able to protect the software they have hired people to write. They should have some protection against an individual taking the information they have learned to take business away from them. A carefully crafted IP agreement can do that.

In the previous essay, I also described how practice is needed to improve skills and increase knowledge. I still believe that development outside of work is needed to practice, learn new things, and keep unused skills from fading. Unfortunately, I've also come to believe that the effects of a draconian IP policy can be more damaging than I first thought.

Habit

One important part of practice is consistency. As long as you continue to practice anything, you tend to improve or, at least, maintain your skills. Obviously, if you stop practicing, the skills and knowledge begin to degrade. More importantly, you also start to lose the habit of practice. The longer you are not practicing, the more effort is needed to get back into the habit of practicing and the easier it is to backslide. This tends to make regaining the skill you are practicing even harder.

I'm sure many of you have seen this effect in different fields: martial arts, sports, music, cooking, etc.

Well, the time off from practice caused by a draconian IP agreement will have the same effect on your programming as an enforced absence from skiing or judo would have on your performance in those areas. Subtly, priorities have shifted. There's always something else that needs to be done. You haven't had time to practice for x months, what's another couple of days? It takes quite a while to overcome that inertia, and that whole time your skills continue to degrade.

Long Term Effects

I think that an overly strict IP agreement not only has a detrimental effect on our skills while you work under it, but also a long-term degradation in your ability to practice.

I worked for a while under a really strict IP agreement. Following the letter of the agreement meant that any software I touched would belong to the company. Working on Open Source projects was obviously out of the question. If I wanted to work on a project on my own, I had to contact the appropriate person in the company's legal department and obtain permission, in advance. If necessary, I had to get sign-off from my supervisor that the project was in no way related to my work with the company. Needless to say, quickie little projects to try out a new technology or technique were no longer worth the effort.

It has taken quite some time to regain the habit of working on projects on my own time. I was able to get back to the little stuff pretty quickly, but bigger project require a lot more effort to start and work on than they used to. Fortunately, I still enjoy writing software, so I have a strong incentive to keep working at it.

Review of Managing Humans

Managing Humans
Michael Lopp
Apress, 2007

Michael Lopp (also known as Rands) describes his take on managing software people. This book is very different from the few other management books I've read. Part of the difference is that Lopp writes all of his examples as fiction. He admits this at the beginning. Rather than tell embarrassing tales about people he has managed, he creates some fictional employees based on his experiences and uses them in equally fictional examples.

This could come across as unrealistic or cartoonish, but Lopp manages to pull it off. Like some of the best Dilbert strips, you have to admit that if these stories aren't true, they should be. If you've worked in this industry for any length of time, you've probably met (or been) several of these characters.

Another odd point for me is that Lopp seems to truly like what he does. This book is not about helping a non-manager survive in a management role. This book is not about a necessary stop at first-line manager while climbing the corporate ladder. This book is not even about keeping those workers in line, so you can get the big bonuses. This book is written by someone who really seems to enjoy the challenges of working as a software engineering manager and who wants to explain how you could like it too.

In the first section, Lopp does a pretty good job of explaining what you need to know about your manager and what he needs to know about you. He explains that most managers aren't actually evil. He also spends a bit of time explaining managementese.

Lopp also explains how managers lose it, the importance of saying no, and the real importance of information flow. He talks about pride and panic, resigning, layoffs, and hiring. He also identifies several special kinds of personalities that you will encounter at work and how to learn to listen and talk with these personalities without going mad.

Overall, I think this book is the best document I have read on managing in the software industry. Granted, I haven't read a large number of these, but it seems to make sense even to someone with little interest in a management position. More importantly, I think it make make me a better employee, by making it easier to understand my managers.

If you are a new software manager or you are looking to make the move into management, this book is a definite must-read. If you would honestly like to know what in the world your manager does even if you are not interested in doing it yourself, I would also recommend reading the book.

Review of Smart & Gets Things Done

Smart & Gets Things Done
Joel Spolsky
Apress, 2007

This book represents Joel Spolsky's approach to hiring programmers. Smart & Gets Things Done is based on Spolsky's weblog, like his previous book, Joel on Software. In this book, Joel brings together his various writings on hiring software developers. Not surprisingly, Joel bucks traditional wisdom on the subject by stating that you should be hiring only the best and ignoring all of the rest.

Now, many companies will publicly agree that you should always hire the best. They may even post slogans or motivational posters saying that We only hire the best. Joel takes a different approach. He honestly suggests that if you can't find the best, you are better off continuing to search than to hire someone who is less than the best. Although he doesn't say it explicitly, the text does hint at the fact that the best for his company may not be the best for your company. However, he does pretty much ignore the whole do they have the right keywords approach to hiring.

Joel mostly focuses on his view of what the best looks like, how to convince them to work at his company, and how to keep them once they are in the door. A lot of what he says will look wonderful to most software developers. I suspect that many hiring managers and human resources people will hate his advice. As someone who develops software for a living and who has been part of the hiring process with a handful of companies (large and small), I think Joel's ideas have some merit. I'm not sure I can agree wholeheartedly with everything he says in the book. Amusingly enough, I think the spots where I disagree are probably very different from where a manager or HR person would disagree.

All in all, the book is a quick read. Joel's writing style is always clear and readable. He brings up a number of interesting points, not all of which are on his weblog. In fact, it was a pleasant surprise to find that this was not just a re-edited version of articles from Joel's weblog. There is actually a bit of new material in there as well. Even without the new material, the book form may be easier to digest than getting this material from half a dozen scattered essays.

If you are involved in any way in hiring software development staff, you probably want to read this book. If you are looking for a job, this book might give you something to keep in mind while considering company offers. My only real complaint about the book was the fact that most of the material is already available on Joel's site, and I consider that to be a minor issue.

The Concept of Technical Debt

I have recently being seeing references online to the concept of Technical Debt. The concept is an attempt to explain to business and management types some of the downside of overly complicated designs, lack of testing infrastructure, and quick-and-dirty code written to meet a deadline. In the past, I've had trouble explaining the difficulties working with this kind of code. Some management types have dismissed cleanup effort as a waste of valuable time. I have often been told that we don't have time to waste on the theoretical benefits of elegant code. One time that I got this response, I was talking about the practical downside of violating encapsulation. This is not a theoretical benefit to the maintenance programmer searching a large code base for the spot where instance data has changed unexpectedly.

In the past, I have had the fortune to work with a few people who understood and worked to clean up the nasty corners of a code base. In each of those cases, we were able to reduce the time spent on maintenance and extend the code to support new business requirements. Despite the successes, we often had to contend with people who claimed that it could have been done anyway and that the cleanup was wasted effort.

I now believe that the problem was an inability to express the problem in language that the business could understand. Technical debt may be the language that we need. It may also help stave off the more aggressive or idealistic programmers (including myself) that have taken a strong stance against any form of technical debt.

I recall the first time I understood the business need for some technical debt (although I didn't think of it that way at the time). I was arguing with the founder of the company about a really nasty hack that he wanted me to put in a piece of code. This guy was not just a management type, he was also a prolific programmer. After quite a bit of explanation of each of the downsides, he finally said: I know all of that, but we will have to live with it to satisfy this customer. At that point, I realized that he not only understood the problem, but he also personally understood the pain we would incur from this decision. He also realized that we might be able to fix it later, but the debt (and interest) was acceptable for business reasons, at this time. I feel the understanding I gained in that discussion truly improved my programming ability.

It may help to rephrase the debate in terms of the amount of technical debt the company can afford and how to efficiently pay off technical debt at appropriate times. The talk Get out of technical debt, by Andy Lester, does a really good job of explaining the costs and how to reduce technical debt. On the other side, James Shore talks about the benefits of temporarily assuming debt in Voluntary Technical Debt, as well as the concrete cost accrued because of this debt.

Like financial debt in business, technical debt can be used as a tool to solve a problem in the short term. But also like financial debt, if you don't pay off the debt in a timely fashion, the interest can eat your business. This concept of interest payments for technical debt is not perfect, but I think it might help to explain the problems that we programmers actually see with those issues covered by the term technical debt.

A lot of the businesses I've seen and worked with appear to be in technical debt up to their eyeballs. Some of the companies wonder why they cannot make much technical progress with their code. What they don't see is that this is similar to borrowing all of the money they possibly can from the bank and any other investors they can find and then wondering why all of their profit is going to fees and interest.

Hopefully, this analogy will help us to make progress towards better code that doesn't suck the life out of programmers and companies.

Geek Gauntlets revisited

I recently finished reading Eric Sink on the Business of Software. I had read many of the essays before and, in general, I like what Sink has to say. I'll freely admit that he knows a lot more about the business of software than I probably ever will, and I'll normally take his opinion over my own on any subject in that area...However, I found that one of his essays (Geek Gauntlets) made some arguments that I didn't agree with. As I thought about it, I realized that the essay makes the same mistake he was accusing programmers of.

I would suggest you read his essay to be certain you understand his point rather than just taking my interpretation. Sink makes some good points and explains some realities of business very well in the process. The point where I believe he goes wrong are two examples of programmer bias. Let's start with the first:

Commercial Version Control

According to Sink, a programmer at Gnomedex once asked him why anyone would buy his commercial version control system when CVS is available for free. In the essay, Sink dismisses this person's question as a case of bias and states that we need to learn to see things through the eyes of the customer. He assumes that technical people just don't understand why a customer would ignore a good technical answer that is freely available. I find this reaction frustrating because I can see asking the same question. Not because I have anything against the SourceGear Vault software, but because I want to understand what the customer wants.

In all honesty, I don't completely understand the customer's decision to go with the commercial tool. But, I do understand some of it. The problem that the customer is trying to solve is only partially a technical problem (version control), it is also partially a business problem. Some of these requirements are important to know:

• software must interface well with their current development environment
• possibly large amount of revision history in a format compatible with Vault, but incompatible with CVS
• knowledge and abilities of the customer's staff
• corporate standards
• features may be provided by Vault, and missing from CVS
• customer support, including hand-holding
• a corporate face on the product

Some of these reasons are technical, the CVS development team might want to consider making changes to support these features if the need is great enough. But most of them are non-technical issues that cannot be solved by any technical means. In many cases, the business reasons trump the technical reasons. Just stating that companies obviously make money in this field, therefore the question is ridiculous, does not help this programmer or a wider audience understand these issues. I would be interested in knowing which of these issues (and others) really seem to influence customer decision in his experience.

In many ways, those of us who choose technology for our livelihood find it hard to understand these kinds of issues. But, those in business are also often blind to technical issues. I wasn't there, so I don't know if the programmer's intent was obvious in his tone and Sink was justified in this viewpoint. But, I did find his (reported) reaction somewhat less than helpful.

Passport

In his next example, he describes a case where the company was considering the possibility of adding support for Microsoft's Passport into their software. One of their developers made the comment that "Passport makes my skin crawl". Sink argues that the developer's reaction was biased and unhelpful. He goes on to point out that if the customers want it, we need to lay aside our bias and implement the customer's requirements.

I remember looking at Passport some time ago, and what I saw made me agree with that developer. (I have not looked at it recently, so I don't know if those opinions are still valid.) I have also been in situations where the customer wanted something that I felt (or knew) was a bad idea. Following Sink's advice seems to imply that I should have just shut up and done what the customer wanted.

In one case that I can think of, I was working with a company that provided financial information from a number of sources on websites that we built for large customers. At one point, one of the customers demanded that I remove the copyright notice that identified one graph as coming from a third party. The customer really wanted this, but I was pretty sure that we couldn't do that. (I didn't know all of the details of the contract allowing us to display the data.) I refused and passed the information on to our project people.

After quite a bit of discussion and checking, it was determined that if I had done what the customer wanted, I would have placed my company, not the customer, in legal problems. Although this was not a technical issue, I applied my knowledge to overrule a customer's desires.

Although this does not seem to relate to the example in the essay, consider this. Let's say for the sake of argument that the developer had been correct and that Passport was a really bad idea. Let's also consider the possibility that he was overruled and that the Passport compatibility was added to the software anyway. Now imagine what would happen if a flaw in the Passport login system had compromised the customer's server allowing their repository to be accessed or damaged. What if the compromise had allowed unauthorized access to the corporate network. Who will be blamed? Do you think it will be the customers who asked for this functionality? Do you think it would be Microsoft? Or, do you think that Sink's company would take the hit?

Part of what the developer was doing was identifying a risk. He may not have done that in an business-like manner, but it was a risk to be identified. As such, it was entirely appropriate to be discussed in a meeting to determine if the technology should be considered. This risk should have been researched and determination made on whether it was a problem or not.

Conclusion

It might not seem like it, but I do agree with much of what Sink says in his essay. However, I think it might be worth considering that knee-jerk business reactions are no better than knee-jerk technical reactions. Sometimes we have to do things that we don't like to make the customer happy. Other times, we need to be able to use our technical knowledge to prevent customer requests from leading to later disasters.

In several of his other essays, Sink states that the technical knowledge is critical to running a technical company. Many of his decisions are based on both technical and business knowledge. The examples in this essay suggest that business understanding and customer desires must always overrule technical issues. I am simply arguing that the real answer is more complex than that. Any decision is a set of tradeoffs. Although we (as technical types) tend to favor the technical issues, we need to be aware that business issues are sometimes more important. Just as importantly, real technical issues sometimes cannot be ignored just because the customer wants it.

Review of Eric Sink on the Business of Software

Eric Sink on the Business of Software
Eric Sink
Apress, 2006

Eric Sink has been writing on the Business of Software for quite some time. This book shows that not only does he know something about the business side of things, but he's also familiar with the technical side. These essays do a pretty good job of explaining issues like positioning, hiring, marketing, and pricing to those of us who are baffled by business concepts. Unlike some heavier texts I've read on this subject, Sink does a good job of introducing the topic without getting into too much detail.

Sink's writing style is clear and easy to read. He uses humor well. And his explanations sound good and plausible. (Not knowing the business side very well, I tend to take his word for it.<shrug/>) In addition to being informative, the book is a relatively quick read. He does a very good job of explaining that, in the business world, the technology issues are not the most important parts of a business (despite what we who write code might think).

If you have seen his weblog, you know that his writing is clear and his opinions are well thought-out. You may not agree with everything he has to say, but every essay will at least provoke thought. Unfortunately, if you've read his weblog, you probably don't need this book. Except for short introductions before each essay and a different organization, this material appears to be the same as his weblog.

This is not necessarily a bad thing. If you prefer reading a book to the on-line experience, the book is a really good read. The book is organized by topic, unlike the weblog, so it is easier to learn more about a particular topic.

If you have never read Sink's writings on line and are thinking about getting into the business side of software, this is a great book to ease you into the weird world of business. If you are already very familiar with his weblog, you may not get much out of the book.

Review of The Career Programmer, Second Edition

The Career Programmer, Second Edition
Christopher Duncan
Apress, 2006

If you are thinking of The Career Programmer as an insight into the best techniques and technologies for becoming an ultimate Alpha Geek, you will be sorely disappointed. However, if you've spent some time dealing with the realities of software development in real companies, much of what Duncan says will be of use to you.

The book is divided into three parts. The first covers the mostly depressing reality of software development. People new to the field may think Duncan is being overly pessimistic in this section. Although he covers the issues with his own brand of humor, I think it is safe to say that he is not exaggerating much (if at all) in his descriptions. I have not seen all of these extremes in my own career, but I've seen enough to recognize where he is coming from.

The second section covers tactics to help cope with the issues in the first section. This is the section that justifies the subtitle of the book guerrilla tactics for an imperfect world. This section does have a lot of really good advice. A large portion of his approach involves learning about corporate realities (such as politics) in order to protect yourself and make effective changes in your environment. I did find quite a bit of his advice to be interesting and plan to apply some of it in my own career. However, I believe that this section suffers from two flawed assumptions.

1. The solution to all of our technical problems is sign-off.
2. Politics is a skill anyone can learn.

These flaws do not invalidate the section, but they do make some of the advice harder to follow in reality than in his descriptions. Let's take these items one at a time. On the technical side, Duncan seems to have a strong belief in a Waterfall-style approach to development. He seems to believe that moving toward this style and getting sign-off at each stage will shield us from changes and some of the levels of insanity in the development process. My experience has definitely been different than his.

Like programming, I think political maneuvering is part skill, part talent. No amount of training will make a programmer out of someone with no talent. Likewise, no amount of studying politics will make many of us good at it. From the book, it appears that Duncan has some natural talent in this area and, therefore, enjoys more success than I would in a similar circumstance. In fact some of the traits that make us good programmers, make political skills harder to learn. However, this is not a valid excuse not to try, He is correct in saying that if we don't try, we will be forever at the mercy of those who do play the game. This section provides the starting points we need to begin.

One of the side effects of these assumptions is that Duncan tends to not explain a few of the political approaches as well as someone like me needs. In many cases, he seems to point in a general direction instead of giving more of a map to follow. This would probably work better for someone with more business savvy. Despite those complaints, I found very little in this section that I would directly disagree with. In fact, his advice about choosing your battles and the chapter on Corporate Self-Defense are probably the most important parts of the book for me.

The final section steps up a level and discusses dealing with your career as a whole. This is where he discusses what to do when slinging code is no longer fun enough to put up with the rest. Duncan describes several scenarios to determine what to do next, including

• changing jobs
• moving to management
• moving to QA
• moving to consulting
• starting your own company
• changing fields

For each of these options, he covers some of the advantages and disadvantages. It helps quite a bit that he seems to have made most of these changes at one time or another. However, he does not really make recommendations, because each reader will have a different view of which tradeoffs are acceptable.

Overall, I think this was a good book for me to have read. I think it may not be appropriate for really junior programmers. The depressing thing is that I think the advice would have been most useful to me when I was really junior, but I would not have been willing to believe the advice. Someone who has been batted around by the corporate world for a while is more likely to be able to make direct use of this material. Unfortunately, I'm afraid some of the material is not complete enough for those of us that lack Duncan's personality and people skills. People with a lot of experience may find that the book doesn't go into enough depth to cover their realities.

Despite all of that, I would recommend the book to any professional programmer. Just keep in mind that you will not be able to read the book and completely change the realities of you daily life tomorrow. Interestingly, I would also recommend portions of the book to other technical staff who are not necessarily programmers. Much of this advice applies just as well to technical writers, QA people, and engineers.

Review of Micro-ISV: From Vision to Reality

Micro-ISV: From Vision to Reality
Bob Walsh
Apress, 2006.

This is not the sort of book I would normally read. I'm usually more interested in the technical side of software than the business side. I found this book to be particularly difficult going partly for that reason. But, before I get into what I didn't like about the book, let's look at the positives.

Walsh manages to give the most complete overview that I've ever seen on what you will need to start a small software business. I'm an unabashed techie. One reason I've never attempted to start a business is that I know that I have big gaping holes in my skill set where business skills are concerned. Walsh's approach is the only one I've ever seen that gave me some reason to believe that I might actually be capable of starting a business. It also gave me a good idea why I probably never will.

Instead of pithy phrases and advice, Walsh focuses on explaining what sorts of information a technical type will need to learn to start down this path. He also gives plenty of information on where and how to track down the information you need. Instead of attempting to spoon-feed us the business information we need, he shows how to learn business skills just like any other skills we have learned throughout our careers. In other words, this book does appear to be focused on helping technical people (who basically learn for a living) to see what they will need to learn to start a business. This seems to be a much more reasonable approach than others I've seen.

Despite the intelligent approach, I found the book to be an incredibly hard read. It was not the writing, which was quite clear and readable. It was the subject. I found it very hard to focus on the material. If I were more interested in starting a business, that might not have been an issue. I also had some difficulty with Walsh's reliance on interviews for many of his points. In a smaller quantity, I think it would have been helpful. But, at some points, it felt more like the testimonials you see in informercials. I am just not normally convinced by that approach. I would have been more comfortable with a few more numbers and a few less stories of people who are succeeding in this field.

The second to last chapter was really difficult because of the sheer number of interviews focusing on Microsoft business support services. It's nice to know that those services are available, but there were enough of those interviews that it began to feel more like a commercial for Microsoft than I would have preferred. Fortunately, that was mostly concentrated in part of one chapter. Most of the interviews seemed more informational than that set.

The final interview of the book was also a little overdone in my opinion. Walsh interviewed Joel Spolsky for an amazing 10 pages of text. In addition, Joel did the foreword for the book. Now, I find Joel's insights to be interesting and he's a good writer. But this was a significantly bigger chunk of text than any of the other interviews. Frankly, if I wanted Joel's opinions, I can get them in many other places. It did not seem necessary to devote quite so much time to them here.

Despite my criticisms, I think this is probably a really good resource for any technical person who is thinking about starting a software business. This will either give you a leg up on the information you will need to know, or convince you that you are not cut out for this kind of life. Either way, the information may be exactly what you need.

The IP Goose

One of the problems with being a software developer these days is company Intellectual Property agreements. I understand that companies want to protect the time, money, and expertise that they have invested. But some of the agreements I have seen go way past reasonable concern. Some IP agreements take the position that any programming a developer does should belong to the company. This includes software that was developed off company premises, without company resources, and in fields that have nothing to do with the company's business. On the face of it, this seems a bit overboard.

Just to be clear, I do not suggest that companies give up all IP agreements. A company needs to be able to protect the work that they have commissioned. They also need some form of protection against an unscrupulous individual taking their proprietary knowledge and going out to compete with them. On the other hand, taking too hard-line a stance can have consequences. I'd just like to suggest that companies consider the tradeoffs involved.

Consequences

So what are some of the consequences of a too-strict IP policy? The simple answer is that these agreements discourage programmers from programming in their free time. These kinds of agreements also make it impossible for a programmer to work on any open source projects. These projects normally require that any code a programmer submits to the project be unencumbered by any IP agreement. If everything a programmer touches belongs to the company, the programmer cannot work on open source projects.

Many management or legal types might take the position that protecting company assets is more important than a programmer's ability to program in his or her free time. Unfortunately, this is a very short-sighted view. This viewpoint ignores some important facts.

• Programmers improve through practice.
• Open source projects are a great way to improve skills.
• Many programmers have (programming) interests outside of work.

Practice

Although many non-programmers don't realize this, a programmer requires specialized knowledge and skills to program well. These skills can only be improved through practice. Some people are born with more inherent programming aptitude than others, but all programmers need practice to enhance and maintain their skills. Really good programmers often find themselves writing code even when they don't have to. Interestingly, it seems to be less important what you are working on, than that you are continuing to use those skills.

Programming on different projects, with different groups of people is a great way to extend the programmer's skills and knowledge. Different experiences tend to make the programmer more flexible in his approaches and more aware of best practices. Open source projects are a great way to see how other people develop software and to be exposed to other methodologies and approaches. The more experience a programmer develops, the better his or her skill set.

Projects

One thing that would probably amaze the legal and management types that craft those IP agreements is that many of their programmers will tend to work on completely different kinds of programming outside of work. This makes it less likely that the software the programmer develops will have any relation to the company's business. There are some exceptions to this, but many of us program differently for fun than we do for work.

Although some programmers will work on work-related code in their free time, the work generated could be protected by much more restricted agreements than many companies generally use. Moreover, in many cases the programmer in question intends to provide the completed product to his employer anyway, but needs to work on it outside work hours for political, personal, or (in rare cases) technical reasons.

Word of Mouth

One important point that many companies forget is that programmers do discuss work environments with each other. Any company that employs tactics that make our work less fun or interesting will find that the word will get out, making it more difficult to find and hire the best. Conversely, a company that recognizes the tradeoffs involved in the IP agreement may find word of mouth makes it easier for them to hire better programmers.

The Goose

I remember a fairy tale from when I was young about a goose that laid golden eggs. It sometimes seems that many people have never heard this story. One version of the story can be found here. The important part of the story is that the farmer lost the steady flow of gold eggs by trying to get everything at once. In a way, this is similar to the strict IP policy. By trying to capture all of the output of each programmer, the policies may prevent a steady stream of innovations that come from better skills and wider knowledge.

Some very big companies have begun to realize the benefit of this approach. In recent years, IBM has been providing support, cash, and personnel to open source projects. This has allowed them to reinvent the company and has helped to make IBM a place where good programmers would want to work. I don't know what their IP agreement looks like, but I would guess that they have put more thought into it than many companies.