Chris Baus

A reflection on the cost of change (or why I write software in my free time)

I have a great day job, and I am certain it is not possible to find a better work environment. It is the type of job developers dream of. The software is interesting and challenging. My colleagues are among the smartest people in the world. We are respected in our field, and I feel we make a small difference in the market, and, well, that's why I got into this field in the first place.

We've been very successful with what we've done in past 5 or 6 years, but with success comes change. As companies grow they have a responsibility to their owners, customers, and employees. It is a complex ecosystem. It isn't fair to take unnecessary risks with software that directly affects the lives of not only all my fellow employees, but many of our users as well. As with many technology products, we've opened up markets that simply didn't exist before. For us that includes one and two person shops consulting to huge corporate and government customers. We provide the tools they need to do their job. If we didn't deliver a competitive product, those who have been most loyal to us, would suffer the most losses.

It is my responsibility as an employee to do what is best for the company. Change is continuously getting more expensive for our software. Every change needs to be backward compatible with software we developed 6 years ago. Every change must go through QA, as changes can not negatively affect other aspects of the software. Marketing and support must understand how the change affects our current and potential customers, and our documentation must be updated.

As you mature as a developer, the most important lesson you learn that can not be taught by any CS program is that it is nearly impossible to under estimate the cost of change. I can not emphasis this enough. Change is expensive, and you only learn this after years in the trenches of commercial software development. If I do not respect the cost of change, I am simply not doing my job as a senior developer on the project. Understanding the cost of change and relaying that to management is one of my most important functions.

So here lies the conundrum for both developers and software companies a like. For companies, the inability to change often comes at a disadvantage in the market. Change is far less expensive for smaller companies, which are not required to generate significant and consistent revenue. So if a feature is required by the market, it is likely that smaller company can afford to implement it before the larger. The smaller the company is, the less it has less to lose. Ok, ok, yes this is an aspect of the now classic Innovator's Dilemma. But you really have to experience it to believe that it is true.

Good developers tend to be highly creative types. We like to try out new techniques, and investigate technologies before others see them as important (hell there are a lot of people that still see blogging as hogwash, while we know they are wrong). There is a thrill in doing something new, but the thrill often involves a lot of risk. The risk that the technology just doesn't do what we expected (as with a new programming language). The risk that the market doesn't evolve (typical .com problem). And the risk that the software just won't work, even if developed with proven technology. These risks often can not be accepted by companies which must deliver consistent revenue.

The last point is the most difficult for us developers to accept. Why we all have the utmost confidence in our skills (a requirement to maintain your sanity in this industry), for those that must decide to invest in a project, there is the non-trivial possibility that the software won't work, or it won't work in the time frame that the market demands. If a change or feature doesn't get approved, it often isn't because that change or feature isn't innovative, it just isn't clear to management that the change will produce a reasonable return on investment, and your time is an investment, whether you see it that way or not. Also the time invested also has opportunity cost which might be better spent on a another project.

So the conundrum is, "How do I do the best job possible as a software engineer, while maintaining my sanity and being true to my inner creative side." For those of us that can swing the time, the answer is simple: take on a side project. Almost all the best developers I know do something on the side. This might include writing articles for technical journals, attending user group meetings, acting as a member of the C++ committee, or working on an Open Source project. My side project is writing HTTP security software (ok and blogging). This type of software makes no sense for my employer to pursue, as it wouldn't be an obvious best use of their time, nor do they have the marketing channels to sell such a product. And that's what makes it interesting to me. It fills a gap in my personality, and it doesn't compete against my day job.

I am not alone here. Look around at the developers you most respect. How many projects are they working on? I suspect you'll find they have something else going on, as all the best developers crave alternative outlets for their skills. So from a fellow software developer, take my advice: never sign a contract that prevents you from working on side projects (regrettably I once signed a contract that basically said my employer owned my thoughts (I don't know about you, but those are worth a lot to me)), and if you have the time, take up a side project.