Today I was doing a bit of casual reading and came across an article discussing the inherent tension between wanting to try out new technologies in projects, and sticking to tried and tested frameworks and libraries that we’ve used previously. This article was really interesting, as it basically suppressed the experimentation of revolutionary architectures in a production environment, whilst positioning the audience to strictly consider enterprise-tier twenty-year-old solutions whenever money is on the line. It got me thinking about how we select technology to accelerate development of our projects.

Something that I’ve noticed in the past few months is how little we sometimes understand or are aware of the downsides of using a particular design pattern, and how it could potentially impact on our project. It worries me. As much as it’s good to get excited and talk about the shiny pros of adopting certain ways of architecting a solution, it is so important to have an in-depth understanding of the potential technical debt that you could run into down the track.

The rapid pace of change with which our industry is undergoing has led to a whole host of technologies being iterated on and replaced, sometimes challenging old practices, and propelling new practices. Don’t get me wrong, it’s really cool that we have more ways of optimising information systems for the constraints and attributes of the domain within which we work, but alongside the known constraints there are also a myriad of unknown constraints which may bite back down the track when we’re already twelve months into the project and we’re locked into using bleeding edge libraries with only a hundred or so Stack Overflow threads.

I’ll give two examples to illustrate the issue, one I’ve seen around the industry and one I have personally fallen victim to.

I. NoSQL

The first is the rise and rise and rise of NoSQL databases. I've come very late to the game on this one, and I know that the discussion around SQL vs NoSQL has been done to death so I'll keep it brief.

A wealth of resources exist around how to implement a NoSQL schema to model your entities, and finding the limitations of NoSQL-like databases like MongoDB is literally a Google search away. But I’m still surprised to find that many people either aren’t aware of or don’t fully understand the implications of using a NoSQL data store in a business context where ACID [1] is still integral to the success of pretty much every information system.

If you don’t have this, then you’re sort of fucked when it comes to extending the system or expecting it to stand up on its own feet for longer than a year. I’m fortunate to come to this debate a few years later than everyone else so have time to observe the failings that have been made, but I still suspect that not many enough have read the case study into Diaspora’s troubled usage of MongoDB. I strongly recommend you read it.

II. AngularJS Performance Issues

The second is my own usage of the AngularJS framework in a semi-complex application. I've had a project this semester in which we had to implement a new, responsive and mobile-first session booking UI for my university's language support service, UTS:HELPS. We quickly ran into serious performance issues using ng-repeat with custom DOM elements. The system would become slow upon loading more than ten or so programmes, a fairly common and expected use case for the application. I was aware of this issue (which is commonly cited in AngularJS vs x.js articles as the two thousand watcher limit), but I didn't understand the implications it would have on our non functional performance goals.

Further down the track we ran into even more problems with it, many of which are documented in some excellent essays around the internet that I wish I had read before starting the project. AngularJS is an excellent framework, but did not suit our complex application and required a fair bit of hand holding to get certain tasks working properly.

In concluding this, I implore you to research your frameworks well; don’t just Google “How to use x” or “y framework advantages”, but actively search for reasons against using the technology you are using. Only then can you get an accurate picture of how the technology fits into the world in which you’re working, and whether it’s actually going to be useful at all, or in the long run.

  1. ACID (Atomicity, Consistency, Isolation, Durability) is a set of properties that guarantee that database transactions are processed reliably ↩︎