Languages

Fear (and respect) the framework

The appeal of building generic, framework solutions is undeniable - but at some point it has to stop. The specific use case needs to be solved. Realizing when to stop is tricky and crossing the line is tempting.

The past few months I’ve been working on building a relatively specific module for Drupal. Rooms wants to solve the booking problem for hotels, vacation rentals and B&Bs. Using Drupal to build it has meant that I had access to a wealth of generic tools. A DB layer, theming engine, date tools, querying tools, etc. My task was reduced to figuring out a reasonable solution for my specific problem and joining the dots to get it working.

As soon as Rooms was released we had several requests to turn it into a generic booking solution. Hotels and B&Bs book rooms by the night. They do discounts for single use. The rooms sleep a certain number of people and have a bed configuration. What if I want to book a conference room for an hour, rent a guitar out for 30 minutes, book a car, a ship, a yacht, a spaceship! Rooms, some suggest, should be a generic booking solution so it could then be adapted to any scenario. This got me thinking about the framework vs domain-specific approach.

The appeal of framework solutions - getting to the core, resolving the underlying issues, tackling the larger problems is undeniable. Who wants to fix a home when you can fix a town, a country - save the world! I am as guilty as anyone - my PhD thesis was titled Models for Agent-Based Systems and it was all about introducing generalized methodologies and modeling techniques.

Drupal is a great example of going down the framework route. It started as a CMS / Community tool and it is evolving into a generalized framework for building web applications (the CMS is turning into a mere example of what the framework can do). Along the way it is also feeling all the pains of having gone down that route. Confused users, developers often lost in a maze of possibilities, integrators trying to figure out whether it’s going to be a contrib module, a custom solution, contrib + custom, some of it in the theme, some in the db, etc. The more Drupal goes down the route of generalization the more the efforts to offer help, support and training increase - because those houses eventually need to get fixed in order to fix the town and save the world.

Now here is the challenge (as far as I am concerned). Up to a certain level frameworking is essential, beyond it is superfluous. It needs to stop and you actually have to solve the specific, mundane problem. Once a framework is in place at some point we need to stop building more frameworks on top of it. The risk of turning Rooms into a generic booking solution is that the distance from the specific problem would increase so much that we would then have to claw it back to re-adapt it to hotels. And what would we gain by the generic booking solution in a hotel setting? If a hotel owner saw it they wouldn’t recognize it as relevant to them. They would say “sure - this is a generic solution”, but I need one specific to hotels. One that talks my language and tackles all my very specific issues about “doubles used as singles” and “cots available”, etc.

Some developers might be happy - they would see the possibility to build on top of it. But are you really building on top - or against. Focusing just on hotels means also simpler code as the space of cases to deal with is reduced. With a framework do we end up with simpler code, easier to understand and fix or are we simply hacking a generic system to do something specific. Even Drupal - that has lots of very intelligent people building it at times feels that it is working against you and making you jump through hoops for simple tasks. More framework-style solutions would be adding more layers of complexity.

A framework that reduces the work for subsequent tasks, simplifies the process and leads to better code is in the right place. Overall, I think with Drupal we already have plenty of frameworks both in core and contrib. Not every module needs to solve generic problems - it can also simply tackle the challenges of a specific group of users. We need to fear the framework path - and respect the frameworks we have by using them as effectively as possible.

Disclaimer: I may well be wrong here ;-) I am hoping to get good pro and con arguments.

Comments

Submitted by Nigel (not verified) on

A perfect example of this is ubercart and commerce. ubercart made a lot of assumptions about what kind of "store" and almost everything was hard-coded. As a result, if you wanted to do something "custom" to it, it required a lot of hacks or workarounds to achieve. To fix this, Ryan (& CommerceGuys) saw an opportunity to leverage existing "meta" modules to achieve what they needed (Views, Rules, Entities) and made very little assumption about what kind of store it was. The result is a small core with a lot of flexibility.
I have followed Drupal Rooms, since it was first announced and I am impressed. This is a huge leap for Drupal and I look forward to it's future. I would love to see Rooms to turn into more of an API for other contrib to tap into, instead of having to reinvent the wheel. e.g. a Hotel can have room, conference, car and resource bookings. I would hate to see that they may have to piece together 4 modules, that don't play nicely together, just to achieve what they want. Just my thoughts. Keep up the good work!

There are different paths to making something generic - it may be that there is a core that can be extracted to be used in a more generic sense but that might not look like an API - rather it might be a set of patterns of how to set these things up or it might be a generic API that talks to different booking engines (one for hotels, one for conference rooms, etc). We will see - my main concern is not to try and go down that path too soon.

Submitted by Anonymous (not verified) on

The way the Drupal community tackles this, is with installation profiles. It's true that Drupal is pretty generic, and plenty of modules are more tools than solutions. Installation profiles, on the other hand, take all these and create a basic, out-of-the-box solution. You're a newspaper? Install OpenPublish and start from there. You need something to manage a whole team? Install OpenAtrium. You're a government? Try OpenPublic. You're a school or university? Go for OpenScholar. Hell, there's even a Drupal for Churches installation profile!

The installation profiles is a slightly forgotten corner of Drupal, though. There're alot of profiles, but plenty of junk ones. Being able to find the one you need might seem tricky due to that. I'm hoping to see that part being improved in the coming time, as a good installation profiles section will prove to be invaluable for Drupal as the core gets more and more generic.

The idea behind Rooms is to have an installation profile to accompany the module - but I don't think we should divide it along the lines of modules = generic, profiles = specific. For a large enough niche a specific module may still be required.

Submitted by wandybrad (not verified) on

Try OpenPublic. You're a school or university? Go for OpenScholar. Hell, there's even a Drupal for Churches installation profile!

Excellent post as always Ronald. I believe the power of Drupal is the openness, width and breadth of the community enabling parallel development on a massive scale, from designer through developers, governments, geniuses, porn-pushers, money-men, and kids of an age computers weren't even around when I was that young!

It adapts to the current environment based on the needs of people like you and I whom use it on a daily basis. I think small distributions of Drupal with modules like yours are the next phase of growth. We have many 'generic' needs but on many levels, there is not just one 'generic' way.

For example we have hypnotists and photographers, hairdressers and corner shops, etc. and there is no reason why we can't build minidistros for these cases, it's just sense. It's more sense to tie it to the generic Drupal framework as that means we don't have to keep reinventing the wheel on the highly technical side whilst focusing on working with local entrepreneurs and businesses to help them when Wordpress just isn't enough.

I tweeted it earlier - I believe we live in a world built on competition and greed, luckily however I work in a world of co-operation and tolerance.

Anyway, my idea for the way forward is http://minidistros.com, another idea I need to take an hour or two out and set up, going to put a few archetypes up like I mentioned above and let people vote on what they want built. May even be a route to funding it. I see Chile's looking for ideas and offering $40k a pop for them with the startup chile thing, perhaps get a few Drupal lovers on that.

My 5p...

Like the idea - I think there is a huge opportunity there and I would suspect people tending (drupal) gardens would at least be exploring similar varieties for their garden :-)

Submitted by Anonymous (not verified) on

The requests to to turn it into a generic booking solution were merely self-interested. You are an experienced developer working with a team, with (presumably) a bit of commercial motivation and funding. Those of us working on the more specialist (or less profitable?) use cases, with less knowledge of Drupal, less time, and fewer resources, are bound to check whether we can just adapt an already developed and tested module.

Fortunately this is open source software, so those developing other modules can make good use of your source code.

I expect solutions that have very tiny units and booking periods (e.g. renting a tennis racquet for an hour and a half) will have significant UI problems. There is not really much comparison with hotel rooms.

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
By submitting this form, you accept the Mollom privacy policy.