Software Ghettos – A Form of Technical Debt

A few years ago I was talking to a senior Java engineer. He was asking me about Django and Python. Having never used the stack himself, and thinking that ‘scripting languages are just toys’, he was skeptical of this new framework and its potential. I went on to explain that Django is pretty neat, the admin feature is a real time saver, and Python as a language just makes sense in so many ways (dictionaries, lists, etc). Then I explained how I had recently met someone at a meetup who only knew Python. This person was using Python for everything, including web services, worker queues, and even business logic! Java shines in those areas of course, and people with Java centric backgrounds often do not realize the serious competition Java has from scripting languages!

Then he coined the term: Django Ghetto

In a sentence:
Man, using python for all that? That guy is working in a Django Ghetto!”

I don’t have a problem with an all Python shop. Scripting languages make sense for many businesses.  I do think it is important for developers to know multiple languages and platforms.  This gets a person beyond being a fan boy/girl for one technology because it is all they know. However, the point about the ghetto is interesting, and I do think as professionals we should be aware of software ghettos.

Software gehtto

My definition of software ghetto:

The more low quality open source projects your project depends on, the more ghetto your project is.”

What is a low quality open source project?

  • Low commit rate
  • Few developers
  • No unit tests
  • No documentation (or worse hard to follow documentation)
  • Narrow platform support
  • The project itself depends on many other low quality open source projects
  • Lack of direction
  • Snooty developers who think their way is the only way – also known as the ‘its free, screw you’ mentality

This is a very common situation in many plugins for CMSs like Drupal / WordPress / Joomla. It can also happen in projects written using popular frameworks. Inevitably the community works on the NEXT version of the framework, abandoning the current version, and forcing you to upgrade. It is not necessarily a bad thing to stay current but there is a cost to upgrading. I would argue the cost of not upgrading is ultimately much higher.

One issue I have with using lots and lots of dependencies (maintained or not) is the added complexity in keeping it all running smoothly as one unit. Just remember: You may very likely be the ONLY one in the world running your specific combination of dependencies (down to the release version), in your specific environment. When you start throwing high load at the server, or trying to get the UI to work across 5 major browsers, that is where the real work starts.

The other issue I have with dependencies is related to human nature. People share open source code on Github or Bitbucket for the joy of it or to get some street cred, but generally not for income.

The irony is, as a project succeeds, bugs are logged, feature requests start pouring in, and soon enough it becomes a job. The original idea the developer nurtured has grown up, left the nest, and what is left behind is a pile of maintenance tasks. Most developers are not up for doing maintenance for free, even on their own code. Some do stay committed and are able to grow a healthy community of contributors, but that is the exception unless they have a benevolent manager or other sponsor for the project.

The kind of projects I hesitate to adopt are the small to medium size scripts or libraries that solve a specific problem really well, at a current point in time. These are more like ‘examples’ than real projects. There a tons and tons of these on Github related to HTM5/Canvas, Node.js, and just about any other current software trend.

What I look for: a sane group of dedicated contributors (a corporation or two backing the project is okay with me), top notch documentation, an active forum, and a complete set of unit tests. My solution is to also be prepared to refactor/swap things out down the road. Object oriented principles can help avoid tight coupling, but that takes extra time to setup. On the UI, with JavaScript/CSS it is not really possible.  If you really want to use the project, but are not sure it will be maintained in 2-3 years, be prepared to own the code yourself.  Save a copy of it somewhere to be safe.

Photo by cactusbones on flickr.


This entry was posted in Application Development, Business, For New Developers and tagged , , . Bookmark the permalink.

Comments are closed.