Mashable Code

In my day job the term “mashup” comes up a lot. I mean loads! A mash up for anyone who doesn’t know is the idea that you can take a bunch of library code, mash it together with some glue code and end up with a new solution. This is extremely popular on the web but happens in most languages and domains to a greater or lesser extent. Games for instance, very similar approach – take some graphics code, add some sound library, a bit of networking, a pinch of path finding source, mix in some custom glue game play logic – pop out comes a game.

Alright, it’s a bit more complicated than that, but you get the idea. At work we traditionally write server side code in Java. The hard thing about server code is it’s hard to test every path, it’s hard to re-deploy once it’s live and above all it’s multiuser, so if the server breaks, you break everyone. With all that in mind there are a set of software development best practices that are applied to make things easier to test and more reliable in the long run:

  • Encapsulation – everything related to one topic is contain in one class (or set of classes). This tends to mean small bits of code spread out very thinly.
  • Information Hiding – don’t expose anything to the outside unless they absolutely need to know it.
  • Decoupling – try to make sure most relationships are done via interface not via real dependency. This helps with information hiding too.
  • Decomposition – every problem is built of N reusable parts that I want to separate so I can change one part at any time.

All of these things are great for building nice flexible, reliable and testable code. However, as with most things in software theres a trade off – for every level of protection I put in to prevent the uneducated programmer making a mistake, I take away an option for the educated programmer to use in a mash up. For instance, by hiding that one internal variable I prevent the developer setting it to something I didn’t plan for! – on the flip side, by hiding that one internal variable I prevent the developing using it to do something new!

This trade off is really bears considering when you’re writing your software. Who is your target? Are you sure you know everything about how someone else might want to use your code? This isn’t a one way fits all thing.

For me, the choice is about where it’s deployed, what culture the language programmers have and how easy it is to test. So, if I’m up on the server, in Java, where it takes hours to setup and configure the system, I’m probably going to err on the side of protecting everything. If I’m on the client, in Javascript and I can test it by just fiddling with a script – I’m going to err on the side of mashability (just made that word up!).

Change any of the variables and the answer may change. As always it’s all about thinking for yourself and considering the options. Blindly following is the way to fail.

Tags :
Categories : Code Rants

Leave a comment