Making software architecture choices analytically with CodeTrend
Modern software gets assembled from parts as much as it gets built from scratch. It used to be you just picked your operating system and programming language and went to it. Nowadays you need to pick your data store, your development tools, your framework and its plugins and all sorts of libraries independently. These choices are difficult and important.
A big part of the difficulty is even knowing what choices are available. All too often the decision is made entirely based on what a key developer has used recently. This is important, don’t get me wrong — if your current team isn’t productive, the project will not go well. But if your current team happens to be experts in something that nobody else in the world uses, you might be heading for a dead-end.
These choices really matter too. Anybody who’s been in the industry has run into so-called “legacy codebases” which is a term that literally means old, but in fact gets applied to any piece of software that is no longer considered “good” for whatever reason. Some very old codebases are still doing great. But some become “legacy” less than a year after birth. Another common feature of legacy codebases is that they’re hard to maintain, and require very expensive investments to replace.
For these reasons, I think that some of the most critical choices in software projects is the choice of technologies upon which it will be based. Despite the importance of these choices, rarely are they considered very carefully. The trade-offs are difficult to categorize, and thus get dismissed all too quickly as subjective, and thus inappropriate for strict analysis. There is definitely a strong subjective component to it, which is why personal experience is so important, but there are analytical ways to look at the choices.
A few years back I wrote a popular article comparing two web development frameworks I was considering using: Django or Ruby on Rails. In it I argue that popularity is a critical measure of any software technology for many reasons. The more people are using a technology, the better it will be. People using it means questions will already be asked and answered on the googles. It means more bugs will have already been found and fixed, and more features will have already been added. For open source software the mechanisms for this are obvious, but the same results tend to happen with closed source systems assuming the organization maintaining the code is rational. It also means it will be easier to hire people who know how it works. Fortunately, popularity of software is relatively easy to measure analytically.
I have spent a lot of time researching these issues before making technology choices and realized that this manual process is wasteful. To that end, I have started an open source project to simplify the systematic comparison of software technologies. It’s called codetrend.org which is where you can start researching right now. It’s all open source and the data are creative-commons licensed. You can start adding to the data today by categorizing technologies, and if you know Ruby on Rails, I’d love help adding features.
As an example of it in use, here’s a comparison of the aforementioned web frameworks counting number of posts on everybody’s favorite developer Q&A site StackOverflow:
This shows that they are both quite popular and growing, but Rails clearly has more activity than Django. (For the record, I recognize and explicitly dismiss the counter-argument that rails might be more confusing or worse documented leading to more questions — questions always come up during use, good / bad / easy / complex / rtfm / brain-buster / whatever.)
I also like to think of CodeTrend as filling a niche that StackOverflow has chosen to ignore. Questions on SO that ask “which is better __ or __” get quickly closed as inappropriate. They keep coming up, and are very useful resources, even though they’re against the rules. I hope CodeTrend will someday be able to fill that need explicitly. There’s a ton of work to do to make that possible, so if you’d like to help out, I’d sure appreciate it. Together we can provide a resource for the entire industry.