The Dangers of Loosing Digital Weight

There two articles that inspired me to start off the year with a new blog.  The first is Dorie Clark's blog on hbr.org about the importance of publishing ideas and the second is Ryan's Block's guest article on the NY Times BITS blog about thinning his digital footprint.

With these two things in mind, I've decided to seriously play with Google's group of hosted services (mail, calendar, etc...).  Following Ryan's advice about closing out dormant accounts and following the terms of services for a few consolidated providers more closely, Google seemed an appropriate choice for me.  I've had an email account there for years but never really used it much.  After growing bored of running my own email services, I choose to forward everything to my gmail account and perform the experiment of living with the web interface.

Thee is another trend that plays into this consolidation of services -- BYOD.  I develop software for a living so I'll likely never be able (or desire) to abandon a laptop.   However, I'm a solid fan of Android and a happy iPad owner.  So I find myself utilizing more and more devices.

Back in the 90's, cross platform meant making Unix/Linux and Microsoft platforms work well together.  But even then it was apparent that cross platform was about access to data.  Today, the plethora of devices (iOS, desktop OS, android) and cloud services (AWS and Google) constitutes a new definition of cross platform.

The question which has yet to be answered is what is the lesser of two evils -- consolidating more personal information with a single provider so I can pay more attention to any potential misuses? or spreading details among many providers which are impossible to track but none of which would have sufficient information to do any real damage?  Is the latter even feasible?

For now I've decided to trust a single provider and to minimize the amount of data I make available.  And the final question is whether these services will make my life more enjoyable and less cluttered.

What does a microwave oven and a job in software development have in common? They both offer a means of near instant gratification. When comparing to other engineering disciplines, civil engineering for example, the time to closure on a project can be enormously shorter. Immediately someone will quote the development cycle for Windows Vista, cite Fred Brook, or quote a passage from “Death March”, but these focus on the grander project scale and not on the individual developer sense of accomplishment. The time from inception to implementation can be remarkably short when we examine thinks on a micro (and not macro) scopic level. Implementing a lock manager may be a part of the overall system, but it an achievement in its own right.

This immediate sense of gratification can be addictive. Combine this with the direct consumer contact in open source projects and you can see why many developers fall into the trap of being directed by bug reports and not overall system evolution. There is a time in the development cycle to fix bugs, and there is a time to focus on pushing features forward. There are times when refactoring a component will address bugs and add functionality. However, as a general rule the bug fix phase and the feature work phase should be partitioned into separate cycles.

To put this another way, don’t clean your room when you should be writing your history report.

(Originally published on 6/9/2009 on www.plainjoe.org)

Does community based software development violate the GPL? The obvious answer is of course not. But walk with me for a few minutes and you’ll see why I asked the question.

In my conversations with various open source developers, I find a varying degrees of belief as to what constitutes a legitimate open source project. Most people would agree that throwing source code up on sourceforge, github, or some other hosting site does not give the code a right to be called a project. After all, a project should be living or have some evidence of past life. The numbers of abandoned code trees on sourceforge.net alone is staggering (don’t ask me to quote a number that seems to increase like the US national debt). But is the code still open source?

There are many open source licenses; I would agree with those that say there are too many. The Open Source Initiative hosts a widely accepted definition of open source. For my purpose, I will refer to the GNU project’s Software Freedom Definition, paraphrasing the four freedoms here.

• Freedom to run the program.
• Freedom to redistribute the program.
• Freedom to study and modify the program.
• Freedom to improve the program and redistribute your improvements.

According to this definition, every abandoned code tree on sourceforge that is licensed under compatible terms with the GNU software freedom definition or the OSI’s open source definition is open source, and yet there is no activity.

Which leads me to the crux of my opening question. No one debates whether or not code released by an individual under some random license is open source. But what about commercial entities that release their archives? I’ve heard many people mutter in the dark corners about Sun and Open Office. I’m no fan of Sun, but whatever you may think, current OpenOffice releases are under version 3 of the LGPL. Therefore is it by definition open source software. You may not like the community but that does not disqualify the nature of the license.

Once you require participation in a community in order to legitimize code as open source, you have added an additional requirement outside of the GPL as sure as the dreaded three clause BSD license. Can open source software exist without an open development community? Yes. All that is necessary to fulfill the spirit of the GPL or BSD licenses is for one person to release their code so that others can utilize the freedom granted. Can a software development community exist without open source? Yes, but probably only the sense of a holding tea parties or book readings. Both of which can be fun but rarely generate anything useful.

Open source is about the freedom to fork. Community is about the freedom to merge. Please don’t sacrifice one at the expense of the other.

(Originally published on 5/27/2009 on www.plainjoe.org)

For eleven years now, I’ve been part of the Samba Team, the core group of developers that lead, develop, and release Samba (http://www.samba.org/). It has been a wonderful, at times stressful, experience for me. However, during April of this year I decided it was time to step down from my position within the team. There are lots of events that played a role in my decision, not the least of which is my involvement in the development of a new open source SMB/CIFS server as part of the Likewise Open project (http://www.likewiseopen.org/). But I was also curious about experiencing Samba development without upstream commit access and see how far the distributed development model with git could go.

The real question for me as I look back on the past decade is, “What have I learned?” There are the obvious technical things like the Windows printing architecture, authentication protocols, and a slew of DCE/RPC operations. But what did I really learn?

One piece of knowledge that I hope I have gained is to never allow your identity to be determined by the code or project you work on. In the end, it is just code. It should be code that you are proud of, but like all things it will eventually be replaced or fade away. Someone will rewrite what you have written or it will simply be removed from the base as it becomes unnecessary. These events are inevitable and should be seen as the cycle of life reflected in code. Letting go that emotional ownership allows one to view things in a more objective light and avoid feeling threatened by logical assessments of the code’s value by others.

Secondly, there is something to learn from everyone. Engineers of all types have a strong tendency to be opinionated at the expense of not asking ourselves, “What wisdom can I glean from this comment?” Never cease to listen to the ideas of others. Humility will not fail you.

I read once that the human brain can only truly grasp seven concepts at once without resorting to an additional memory mechanism. For myself, if I can only remember these two and put them to daily use I believe I will be the better for it.

(Originally published on 5/9/2009 on www.plainjoe.org)

Lately, I’ve been reading books on programming style and techniques. The most recent addition is “Software Exorcism: A Handbook for Debugging and Optimizing Legacy Code” by Bill Blunden. I have not found a tremendous amount of new material in the book, but there are a few interesting examples. It’s the author’s voice however that is of relevance in this case.

I’ve had the privilege to work on four books, three of which were separate titles. My positive opinion of writing for O’Reilly is entirely due to the gifted editors assigned to work with me. During both “LDAP System Administration” and “Using Samba”, they drilled into me the need to be concise in my wording. They put my prose on a diet. I can honestly say that at the time the books were published, they were the best work I could produce.

The problem I have with Blunden’s book is the use of personal speaking style when writing. It becomes a distraction to me and borders on pretentious at times. Technical topics should be covered with a rational, Spock-like approach. Because this seems counter intuitive to anyone that has had to do any public speaking, most first time writers fall into the trap of translating those oratory experiences onto paper. I did myself in my first book. I believe that the tendency to “wax poetic” is an attempt to over-compensate for our own fear of inadequacy, that someone will question our right to teach others or will know more than us.

As software developers, we spend a create deal of time designing and writing new code and then an equal amount of debugging that code (or possibly someone else’s code). Modern compiles include a variety of options to help optimize good code and eliminate bad code.[1] Removing defects like the use of uninitialized variables and unreachable code should be pursued with deterministic precision. Of course, there is still room for personal creativity. Whether you use “for (;;)” or “while(1)” in C, the end result is the same.

Eric Raymond once told me he believed that most good developers possessed ability to be good writers. I am by no means an ESR fan, but I think on this point he is correct. The reason is that the same drive that forces us to consider all the possible ways to write an algorithm and then choose the most efficient and elegant one can also be applied to the technical explanations we write in our native language. In prose, as in code, content is king.

[1] I have a love-hate relationship with gcc’s -Werror.

(Originally published 5/8/2009 on www.plainjoe.org)