I’ve been working with MVC for a while now and it’s generally a great idea. I first got acquainted with it when starting to work on the BeWelcome code (have a look at http://www.bevolunteer.org/trac/ if you’re interested in an open source hospitality exchange project). After that I used it in personal frameworks, based on what I’d seen in BeWelcome and reading from articles like How to use Model-View-Controller (MVC) by Steve Burbeck. My first frameworks were, as one might expect, not providing a whole lot of usability and code reuse. As a colleague of mine said, after having had a look at the code: there were a lot of design patterns present but they didn’t seem to be doing much in my code.

After that, I’ve worked with the MVC pattern in a number of sites as part of my job at Aardvark Media as well as more mature versions of my framework, and it’s let me to some personal opinions on the pattern.

• The main point of the MVC pattern seems to me to be modularising the code. The reason it’s called MVC is that you’re dealing with Model, View and Controller – it’s a triad of connections. In order to get the maximum decoupling, this triad needs to be able to work on it’s own, i.e. you need to be able to rip out an MVC triad without having the entire code break down.
• Most of the uses of MVC that I have seen means coupling the model of the MVC with other classes. The reason for this is simple: the models provide data access and lots of places can need access to data that doesn’t appear in the MVC they’re in. From my point of view this poses a problem, though, because it means you can no longer switch out MVC triads as you please.
• The MVC design works best, in my opinion, when all access to the MVC happens through the controller. In web apps, this means running the framework and then picking an MVC triad to run and then be done with it (possibly running several MVCs but running them independently of each other). It’s also possible to have MVCs use each, but still using only the controller as the entry point to the code. This ensures exposing methods in just one place.
• This leads to the obvious question: how to avoid code duplication and get proper code reuse, if models shouldn’t be shared among MVCs? My personal answer to this is data objects, based on the ORM pattern. The idea here is that the model in an MVC will normally contain general code that does general data lookup and is used by many places (your typical load user code, for instance). The model will also contain some specific code only used by the MVC it is placed in. If the general code is refactored out into a smaller object, that only contains general code, it’s possible to make some very flexible data objects based on the ORM pattern that at the same time fulfill all the data access needs of the project.
• This leads to architechture along the following lines: 1) MVCs that do the work of applications and 2) data objects that do the majority of the data grunt work. Data objects are shared among all MVCs – because they only hold generic methods and data, they don’t overexpose methods or properties. MVC models only expose methods to the MVC they’re in, so there won’t be any tight coupling between individual MVCs.
• This means MVCs become more like modules – you can swap them in and out as you please, turn them on or off during debugging, etc.

Switching to a style like this is not very hard. You can go about it piecemeal: first setup a base class for the data objects with some generic features for getting data out of the DB, then setup some object classes mirroring the DB setup. At first, all you want is just an empty child class of the data object class: just enough detail to tie it with the DB table but no more. Test that you can get data out of the proper table and when this works, you can start refactoring models to use the data object instead: instantiate the data object in the model and move the generic data functions into that instead. And … you’re done :)

Working in teams is great. And a massive pain. It depends on a lot of things: the other team members, the team lead, the project itself, your motivation for being in the team, the structuring of the team, plus the general environment of the team. Obviously, in a normal job, the individual doesn’t have too much influence on most of these factors: your team lead is a given, project is set by your boss, you’ve got a given position determined by what others think is best, the environment is set … most of the factors you’ll have no influence on.

Things are supposed to be different in an open source project. You have much more of a say in things: you determine what, if anything, you contribute. You determine what parts of the project you’re working on, if any. The structure of the team is – with a bit of luck – also something you can have effect on. Open source projects could thus be a dream come true in terms of development experience: people that want to work together on a project they want to participate in. What could go wrong?

Needless to say, tons of things could make things problematic in OS projects. My personal experiences come from working with BeWelcome, a hospitality/cultural exchange organisation and website. Founded on the bad experiences a number of people had with other sites (notably HospitalityClub and Couchsurfing) these people set out to avoid the problems they saw with the other sites. This, unfortunately, led to defining BeWelcome first negatively in terms of the other sites and only secondly to try defining it positively. In terms of the organisation it has led to a lot of bureaucracy – something that has also been felt in the various teams, including the dev team. The main problem has been a lack of clearly defined leadership. There have been team leads, for sure, great ones as well, but an overall problem with leadership in the project has influenced all teams as well (a team environment factor: the outside world influencing the team because the team feels it should mimic the outside world).

By far the biggest problem that I have experienced till now, though, has been lacking a team lead. After the last guy stopped no one stepped up to the plate so we’ve been working without one for a while now and boy! does that suck if there are ever differences between members in the team. Lacking a clear way to resolve differing opinions, point out the way or decide upon the priority of tasks is a major problem. Even just a thing like processes in the team needs a team lead to enforce them: if one person doesn’t like the way things are done and starts working in a different way, who’s to stop her?

While it’s true that in an OS project anyone can step up and take on ownership, human nature would have it that not everyone does. In a project that runs on volunteer motivation, taking part already costs energy … and taking on more responsibility can easily be too much. There’s no extra pay to sweeten the deal, no perks, just more responsibility, more people calling on you to help them with bug fixes and feature requests. Obviously, seeing the project take the right turns and head in the right direction is a reward, but is it enough to outweigh the extra weight on your shoulders? I think the amount of people fighting to take on the role of team lead reflects just how much status is attached to the project – in most situations, it’s not going to be many people.

Then what?

The possibilities for dealing with leadership in development teams fall in three groups:

1. having a team lead
2. sharing the team lead role between several members
3. not having a team lead

1. This is the obvious possibility and the best in my opinion. In order for it to work properly, a good team lead is required but it’s a role in which people can learn and rise to the task.

2. This means cutting the role down to size, sharing out responsibilities and making sure the resulting roles are not too big or too small. If the team gets the roles right and make sure there are no overlapping responsibilities, this can probably work almost as good as option #1. It’s a requirement that the roles are clearly defined and that the people sharing the team lead role can work together without problems.

3. An alternative to having a lead is having clearly defined processes and sticking to them. If the group can agree to some clearly defined procedures for working and follow them, most differences in the every run of things can be resolved by pointing to the rules. Bigger differences in opinion or view of goals and mission can be resolved through a democratic show of hands in the group. This solution might work if all the people in the team shares a mindset and like to work together, but if not it’s doomed from the outset.

In BeWelcome we’re currently going with option #3 and my personal experience is that it’s not working and it’s not worth using – we’re spending way too much time discussing and arguing things, and there’s no option for resolving differences over working processes. Too many confrontations which takes time away from development.

So, time to change things.

Recently I was looking for info on status messages from SVN and while googling for ’svn status cheatsheet’ did turn up quite a few results, they were all useless: none of them went beyond the status messages you get in the first row from SVN when doing svn st. Seeing as I was up against ’s’ and ‘uu’ that didn’t help. The SVN manual didn’t prove very helpful either, at first – the status messages are spread out through the manual and finding the ones I needed took me very long. Hence, for future reference:

Most of this stuff won’t show unless you do ’svn st –show-updates’ or ’svn st -v’ but it’s very useful to know from time to time.

I can’t ever recall the magic methods of PHP and sometimes google doesn’t seem to display them as the first couple of hits, so for my own sake, a cheat-sheet of them with a few notes:

• __construct(/* arguments */) : called on construction of the object
• __destruct() : called when the object is destroyed
• __get($var) : called when the object does NOT contain the property $var or when $var is private or protected. ALSO called on empty($object->$var) if $var is private or protected
• __set($var, $value) : called when the object does NOT contain the property $var or when $var is private or protected.
• __call($method, $args) : called when the object does NOT contain the method $method. Unlike __get and __set it doesn’t hide private or protected methods.
• __callStatic($method, $args) : equivalent to __call but for static calls. New as of 5.3.
• __clone() : called on clone object.
• __isset($var): called when empty() or isset() is called on a non-existing or private or protected property.
  
• __unset($var) : called on unset when object does NOT contain $var or $var is private or protected.
• __sleep() : called if serialize() is called on the object. Should return array of properties that will be serialized before the object is destroyed. Allows object to do cleanup before serialization.
• __wakeup() : called if unserialize() is called on the object. Notifies the object that it is being brought back to life.
• __toString() : let’s a class decide what to return if it is converted to string.
• __invoke(/* arguments */) : called if the objectt is called as a function. New as of 5.3
• __set_state($array) : static method called for classes exported by var_export.

And, the manual page describing the methods.

I have a theory that you can tell a geek by the comics he reads. I don’t know yet what the individual geek types are, but some day I’ll figure that one out too. In the meantime, the question becomes one of “separate the geeks from the non-geeks by looking at their comic reads”. Here are mine:

• Sinfest
• Kevin and Kell
• Calvin and Hobbes
• Non Sequitur
• Order of the Stick
• Garfield minus Garfield
• Too Much Coffee Man
• xkcd

Hmmm … maybe the length of the list plays a role too …