As with so many things, the theory of Software Engineering and the Practice tend to differ greatly. Jeff Atwood has his Recommended Reading for Developers list on his Blog, and I do agree with several of the books he posts. I’ve nearly finished reading Code Complete, and I’ve it includes many good guidelines on what constitutes good software, and how to make it happen within a programming team. Pete Goodliffe’s Code Craft contains many similar suggestions, but with more of a “from the trenches” kind of feel. Fred Brooks’ The Mythical Man Month identified a great number of problems that still plague software to this day, nearly three decades after it was written.

With all these books available describing “Software Engineering Best Practice”, and with their tendency to agree of 90% of their key points, why is it that we still have such an enormous amount of lousy software? This isn’t even a Microsoft vs. Unix problem any longer, even though most best practice in this field tends to follow Unix’s Seventeen Rules, there is still plenty of bloated ugly software for Unix. Even rhythmbox, which I’ve contributed small amounts of code to, failed in part to meet the goal of those rules, in placing it’s Podcast code into the mainline program, instead of abstracting it out as a plugin (to be fair to ryhthmbox, there is a bug open to take care of this problem). Programs should be as absolutely small as possible, and clean plug in architectures are the best way to add functionality beyond the ‘core’ functionality the software must serve.

Ben Collins-Sussman recently made an exaggerated point about an 80/20 split between developers, basically saying the 80% of developers program for a living, and 20% live to program. Ignoring the ensuing debate about the perceived elitism between his post and Atwood’s, it’s an interesting point. Some people are just more apt to grab ahold of the newest technology and try it out and try to make it shine, while the job developers aren’t inclined to seek out new tools. There is nothing wrong with either approach, but there is a lot of elitism on the part of the ‘20%’.

Collins-Sussman was posting primarily about how Distributed Version Control Systems, like git are not accessible by the ‘80%’, and therefore most of corporate developers. Now, I love git, I think it’s a great tool. I would never use git for corporate development, for several of the reasons Collins-Sussman blogs about. It makes more sense for there to be a central repository for corporate source, both from a security and integrity perspective. I would argue that the reasons that DVCS doesn’t make sense for corporate software, is because it is trying to solve a different problem.

DVCS is particularly well suited for open-source development, because you’ve got a lot of developers who are greatly geographically diverse, who may not be able to provide reliable hosting for a source repository, and who typically want reasonably complete features before they share their patches. This is where git, in particular, shines. It allows a developer to take full advantage of source control without fidgeting with the changes on a server that may or may not be available. It is fully possible for a large project to be successfully managed via git without having a server set up at all. There may be a lot of commands, but it is quite a paradigm shift, and some new language will need to be adapted.

I would argue that Subversion, while a good answer for teams of software developers (though I don’t think it’s Windows integration via TortiseSVN is really all that good), I believe it lacks features that hinder it as an SCM for open source projects, namely the ability to work on something locally, with the full benefits of source control, without a network connection or the need to share unfinished ideas or code. Apparently Subversion is working on adding features that allow for more and better offline editing, but right now, they aren’t there, and that makes me wonder if subversion is really appropriate for open source development.

Collins-Sussman seems to indicate in his post that both the DVCS’ on the market, and the more traditional VCS’ should be trying to ultimately serve the goals of all users. My only question is why. Both methods of managing source solve different problems for different arenas, and if they try to become one-size-fits-all applications, we will end up with hopelessly bloated and insecure systems. Certainly, implementing features inspired by one system or the other is okay, provided they make sense within the model you’re software is encouraging.

Bruce Schneier posted a conversation between himself and Marcus Ranum about security in ten years. The foregone conclusion: Things are going to get bad. Very bad. We’ve been locked in this ‘patch-and-pray’ development model for decades, and people have become so accustomed to poorly designed and insecure software that they don’t see any other way things can be. Schneier even goes on to talk about how this model will be utilized to enforce a code-signing system, and the day that happens will be the death of software as we know it. When all the doors are locked, software will stagnate and die, and innovation will go out the door with it. Imagine what a company like Microsoft could do if they could choose not to allow a developer’s software to run on their platform by refusing to sign it?

It’s time software developers began to actually practice best practice. To design with security in mind, to design small simple packages that can be combined to solve fantastic problems. To resist feature creep. Features are the enemy. Commercial developers try to lock consumers into an endless cycle of upgrades, that continue to add 99 features they’ll never use for a single one they might. It’s not fair to single out commercial software, however, some open source projects fall prey to the ‘one-more-feature’ mania. The software industry has dug itself into an awfully deep hole by focusing on jack-of-all-trades software, and it’s bad for software and business in general.

Now we’re talking about Software-as-a-Service, and locked platforms. Rather than solving the fundamental problems in software today, we’re just trying to offer a false sense of security, and greater vendor lock-in. The future is going to be frightening.