This is my personal blog. The views expressed on these pages are mine alone and not those of my employer.

Saturday, 19 February 2011

Keeping it simple - stupid

Einstein once said "Everything should be made as simple as possible, but not simpler" which couldn't apply any more to physics as it does modern software development.

You see - modern software development is brimming full of abstractions - which exist solely to provide simplification through hiding complexity.

These abstractions tend to come along with 'buzz word' names, here's just a handful:

- Web Services
- ASP.NET Web Forms
- User Controls

These are all 'cool' words to find on anyones CV, and asking a software developer about each would result in volumes spoken.  However at the end of the day all of these boil down to abstracting the underlying messages being passed across a network.  Imagine having to piece together each HTTP packet, adding the headers, and populating its payload - it would take an age to build anything, never mind a decent website, user control or web service - which is the problem abstraction solves.

However abstractions are very limited in their scope, and it's too easy for the non-experienced to try and abstract too much.  Abstractions keep things simple, but applied too wide they make things simpler.  And we know good old Einstein wouldn't be impressed with that.

To illustrate this point I'd like to describe something I recently experienced.  A requirement of ours was to provide nightly backups across the internet, between two separate systems. To achieve this the following would take place:
  • The backup would be uploaded over FTP
  • A message would be sent to the recipient of the backup when complete (to allow it to process the backup)
The developer in charge decided the message after the upload was complete should be sent via a method call to a web service, which would also pass the hash of the uploaded file so it could be verified.  There was a number of problems getting this set up, and while the FTP side of things worked perfectly, the web service didn't.

The point I'm making is that a web service is an abstraction over HTTP, and is complete overkill for a simple method call.  A much better (and simpler) way would be to create a page who's URL allowed the hash to be passed in as a variable.  Which would in turn carry out the same actions as the web service.

Doing it this way allows a number of benefits over the web service option:
  • Any machine connected to the internet could send the 'completed' message as there is no reliance on the .net framework
  • A lot of overhead has been removed
  • There no need to install, debug, and mess around with web service way of doing things
The developer involved had the notion that using a web service is some how more secure, which just sounds downright dangerous to me.  If you've got an open web service, anyone can play around with it, but that's because I understand that its just abstracting a bunch of HTTP calls.

I therefore urge all software developers out there to think before you type anything, remember this is what a specification is for!  Are you trying to abstract something which is already simple?  You wouldn't nail a picture to the wall with a sledgehammer, would you?


  1. I totally agree with you mate, but I believe some of it is to blame on the ever increasing complexity of technology and pressure on developers nowadays to keep up.

    1. Since I wrote this it certainly does appear there is more complexity out there than ever - resulting in more *leaky* abstractions. However I think the trick is to never 'narrow' your knowledge too much, but merely know enough to select the correct tool for the job, and learn any complexities along the way.