Swarm - Website Design & Digital Media Agency

Welcome to the Swarm website! Swarm Media is a digital design agency based in Leeds & York in the United Kingdom. We specialise in many areas of digital design including website design, graphic design, web development, Flash animation, search-engine optimisation and web hosting. If you want quality digital design solutions, then look no further.

Blog / Updates

The MVC Pattern

MVC stands for Model-View-Controller and is an architectural pattern used in programming. The intention behind the pattern is to separate presentation from logic, much in the same way that CSS stylesheets separate the visual elements of a webpage from the structural HTML markup. Models represent the data, the view represents how the data is displayed to the user and the controller deals with the interaction between the two.

Before I go any further, please be aware that this blog entry is aimed at MVC in relation to building websites, not MVC in general.

In my previous blog entry I discussed PHP frameworks. Many of these implement the MVC pattern and so it is becoming quite popular amongst web developers. However in general, I remain unconvinced that it is really the best approach to use.

Whilst I am keen on object-oriented programming which separates code into manageable blocks, I find that the MVC pattern needlessly complicates things. For example, the MVC pattern requires one to separate what would otherwise reside in a continuous, ordered sequence, into multiple files.

Whilst a non-MVC approach is not necessarily entirely procedural, the three MVC elements are generally integrated together, so one might fetch some data from the database and then cycle through the results and display them all in a few consecutive lines of code. The MVC approach would be to move the database functions to a separate file, move the visual functions to a separate file, and then request these external files via the controller functions.

In a situation where multiple developers are working on a project over an extended period of time, where some may be tasked with developing the visual front-end elements and others may be tasked with working on the database functions, the MVC approach is useful as it allows work to be done separately with less chance of breaking something. However, if all the developers involved have a strong understanding of all these elements, or if the project is quite small, MVC becomes a hinderance rather than any help.

I personally favour using integrated "controllers", where the flow of the application is exactly as you see it. Of course, objects can (and should) be used to avoid needlessly repeating the same code many times, however these objects are used for specific functionality. Rather than dividing things based on whether they handle data or presentation, I prefer to group functionality based on its specific function within an application - so a controller which handles blog entries, a controller which handles portfolio items etc. - including both the data management and presentation aspects of these components. If I need to fetch something from the database I will do it directly and exactly where it is needed (fetch the data, display the data). MVC on the other hand requires you to use the controller to fetch the model which fetches the data, then use the controller to fetch the view, and then feed the data into the view which then displays the data.

I'm not massively opposed to MVC, I just prefer a more cohesive approach because it seems more logical to me.

Further reading:

MVC Wikipedia Entry

MVC: Not a good architecture for websites

Occam's Razor

As may be indicated by the title, I'm a big fan of Occam's Razor. For anyone who has never heard of it, it's a philosophical principle which states "entities should not be multiplied unnecessarily". Basically; keep things as simple as possible, because the simplest answer is probably the best answer. Although the principle originally applied to scientific and philosophical hypotheses, I strongly believe it is highly applicable to web design and development.

Over the past few years pre-built frameworks and content management systems (such as WordPress, Drupal and Joomla) have become very popular and widespread. Essentially these are pre-written libraries of code which are intended to make the development of a website much faster and easier by providing a lot of commonly used website elements and functionality. In the case of CMSs, this means that all the developer has to do is set some configuration options and a website can be made live in 10 minutes.

I've experimented with several PHP frameworks including CakePHP, CodeIgniter and Kohana, and I've dabbled in all the most popular content management systems (mentioned above). I can certainly see why one might want to use them; they provide a lot of great functionality, and they're especially good if you're not an expert in PHP because a lot of the groundwork is done for you. In the end though, I'm in agreement with the inventor of PHP Rasmus Lerdorf when he says "their "jack-of-all-trades" attitude leads developers down the wrong path by not using what is best for the job." If you use either a framework or (especially) a content management system, you start off with a library of between 300 and 10,000 files (perhaps more), the majority of which you probably don't need for that specific project. This is bloat, plain and simple.

Another problem, leading back to Occam's Razor, is the fact that it will be highly unlikely that a developer using a framework will be able to go into any given file and fully understand what any given piece of code does. This makes customisation trickier than it ought to be, and it makes it harder to fix something that goes wrong. Some are easier than others, but learning a framework or a CMS is often like learning a whole new language with its own rules, syntax and structure, and to me the whole process seems unnecessary. Obviously there are definite up-sides to using a framework, but I personally hate being forced to work in someone else's paradigm and prefer to write all my code from scratch and in my own style.

If I had to pick a framework to use though, it'd probably be Kohana at the moment. CodeIgniter is also good, but I wouldn't use it until it drops support for the ageing PHP4.

Occam's Razor isn't only applicable to frameworks and content management systems though. I've seen lots of examples of sites where the code has gotten completely out of hand. I've seen vast blocks of code spread across dozens and dozens of files which do not seem to achieve anything; at least, nothing that couldn't easily be achieved with a far smaller amount of code. A lot of developers seem to just completely lose sight of the practical objectives of a project and assume that "more equals better". Well, it doesn't; quite the opposite actually.

I distinctly remember my GCSE English teacher telling me that I had a talent for writing succinctly, and I think this has carried through to my programming. Efficiency is (or should be) a paramount consideration in any kind of computer/web programming - and Occam's Razor is the perfect philosophical principle to reflect that fact.

My thoughts here are somewhat echoed by Alberto Gutierrez in his blog entry "For god's sake! Keep it simple!" The KISS (Keep It Simple, Stupid) principle is another name for this approach and has been promoted by many great minds throughout history.

Albert Einstein: "Everything should be made as simple as possible, but no simpler."

Leonardo Da Vinci: "Simplicity is the ultimate sophistication."

Antoine de Saint Exupéry: "It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away."

Horribly Coded Sites

As the Technical Director at Swarm, it's my job to make sure everything is coded nicely to ensure firstly that everything we make runs efficiently and bug-free, and secondly that future development will be relatively straightforward. Being a massive perfectionist is pretty useful here because it means I've adopted a very strict coding standard which I use for every project.

Over the past month or so I've been tasked to work on some websites that have been built by other developers in order to improve them, but in the end I decided it would be quicker and more beneficial in the long-term to just completely re-do these websites from scratch because the code was absolutely abysmal.

PHP (the language that I primarily use to make functional websites and which is used on over 20 million websites) is quite relaxed, in that it's very easy to write horrible code which still works. Apparently, even supposedly professional web developers have a tendency to write horrible code, and worse they can get away with it because clients will rarely have the technical knowledge to know what "bad code" looks like. It's like a lot of professions where the amount of technical or specialised knowledge is quite high; car mechanics, electricians etc. Since clients often don't know what's going on, they also don't know if a good job has been done, so it allows so-called "cowboy builders", "cowboy car mechanics" etc. to exist. Well, cowboy web designers exist too.

The level of inconsistency, poor naming conventions, seemingly random indentation and complete absence of code commenting (somewhat of a necessity if the developer wanted to come back in a year and continue work on the site) that I've seen is really staggering. A lot of the code seemed to be just copied and pasted in. I don't know if this is down to sheer inexperience/incompetence, or just a complete disregard for the client and an attempt to quickly churn out a site as fast as possible in order to get paid, but either case is quite disheartening.

I really do hope these sites aren't representative of web development as a whole, but I fear they are.

In contrast, I take a lot of pride in the code I write, and if a client ever wanted me to show it to them and explain exactly what it does, I'd be delighted to do so.

Free Quote