MVC Frameworks and modern web development

Lately I’ve had the pleasure of playing around with Ruby on Rails, undoubtedly THE name that comes to mind when you ask about rapid application development in Web 2.0.

My first impression was that it was going to be a pain to learn the ins-and-outs, and that I was in for a steep learning curve as I had to both learn the Ruby language, and master the MVC framework Rails at the same time. Coming from a PHP background I knew there was a lot of stuff I would have to learn (and unlearn, in a manner of speaking) in order to program effectively in Rails.

In truth however, I found it easier to get up and running with Rails than I did with Symfony, which is basically a PHP MVC framework that mimicks Rails in terms of its functionality. Symfony is itself, however, a brilliant MVC framework and probably the closest thing to Rails I’ve found for PHP.

With Rails and Symfony, you start out by designing your database schema, and then can use a number of command-line tools to scaffold your application, either by creating just simple controller classes or going all the way and letting the framework build pages to provide full CRUD (Create, Retrieve, Update, Delete) functionality, which you can then go through with a scalpel and paintbrush and customise to your liking.

In essence, these two MVC frameworks provide all the functionality and libraries needed to instantly turn a YAML database specification into a working application in a matter of minutes.

Why is this SO AWESOME? Simple: it allows developers to focus their attention on delivering a product based around their core business model, rather than wasting time dealing with fundamentals. Think of it as building a beautiful house out of existing materials…. plaster and timber for the structure, concrete for the foundation, paint for the walls etc. as opposed to building a house by heading off to the nearest timber forest, cutting down trees, cutting the wood to shape, treating the timber, mining limestone and other minerals to create plaster, concrete etc….. you get the idea.

Software development has always worked like this in a way… frameworks get more and more sophisticated, common controls and elements are packaged with development environments to make rapid application development simpler and more effective etc, but it seems that frameworks such as Rails and Symfony go one step further, because just about *everything* you could possibly need for an application is already there, or readily accessible as a plugin, and you can turn a nifty idea for a SaaS application into a reality in no time at all.

Both Rails and Symfony are supported by a fiercely evangelistic community of developers who provide plugins for free to solve a whole host of common software development conundrums, and both are supported by terrific documentation… I have been able to assemble a basic Rails app from scratch simply by following the Ruby Guides. Not bad for somebody who’s never written a single line of Ruby code in their entire life.

There’s one framework I haven’t mentioned yet: Zend. There’s a good reason: I don’t think the Zend framework deserves the title “Framework”. I don’t like Zend. It feels bloated. It feels poorly documented. It feels badly coded (and I’m not the only person who feels this way). To me, it feels like the Microsoft of MVC.

Everything about Ruby and Symfony screams “simplicity” to me, like the creators intended to turn programming back into a graceful art, and to make people truly passionate about web development. Symfony and Rails are the Zen gardens of web development: minimalistic, spiritual, beautiful and closer to art than software development.

Zend doesn’t really “scream” anything, so much as make developers scream at how frustrating it is to use and develop applications. I’ve seen Zend code… it’s like looking into the gates of hell.

I’ll stop bad-mouthing the competition now, and simply close by saying: if you’re passionate about web development, and want to learn a framework that makes developing web 2.0 apps feel more like art than simply cutting code, I implore you to give either Symfony or Rails a decent try. Take a weekend to run through one of the guides. I promise you won’t be disappointed.

Continue reading...

Communication issues in small business

A good friend/ex-colleague of mine and I got into a discussion recently about some of the woes that accompany being a tech guru in a small business. The number one issue at hand was communication – trying to interpret the needs of the business (and the managers) and create a solution that made everyone smile.

Unfortunately, developers are terrible at managing the expectations of the boss, and managers are typically not quite as clued in as their technical subordinates with regards to technical limitations. What usually results is a solution which was either a) done within the timeframes required but falls short of expectations, or b) meets expectations to a degree, but took twice as long as intended.

In a larger business this unfortunate phenomenon is mitigated by two things. Firstly, timelines are paradoxically both more expanded/lenient (read: realistic) and also very inflexible… perhaps not so much a paradox, as the longer timelines may be designed specifically to prevent deadlines slipping… allocate more time than you need and all is well. The key however, is that while there’s plenty of time allocated to meet that goal… The Deadline Is Not Arbitrary. It must be met, on time, every time.

Secondly, an all-important position within the company becomes viable (even essential): there could be a dozen different titles for the position, but what it boils down to is that you have someone who is technically savvy and understands limitations, and has enough experience dealing with/participating in management to effectively manage the expectations of the top brass. Essentially this boils down to having a mediator, a translator who can take the requirements of the business, turn it into a specification the tech guys can understand, while at the same time effectively communicating the technical limitations (and the workload of the tech team) to the boss(es) and keeping their expectations within the bounds of realism.

If you’re dealing directly with tech staff, you may be inclined to put on your Leader Hat and rally them to nail a deadline they just can’t manage, whereas dealing with a single person who acts as an authority over your technical assets means you’re more likely to delegate the management of the project to them, instead of doing it yourself. This means managers can do their job more effectively and not worry themselves with the details, and the tech team can work under the leadership of someone who was once in their shoes.

So how do you fill such a position in a small business? From experience it’s pretty difficult… either you get someone who’s happy to occasionally step over from another role (say, marketing manager or business development manager) or you get a tech guy who can both do the hard work and manage the “team”, even if the team is just him/herself and one other.

It’s a no-brainer that having a separation between management and tech is a good thing, unless you’re lucky enough to build a team made up of a mixed bag of ex-tech, management etc. where the manager(s) has/have a keen understanding of the tech side of the business that they’re directing. This is surprisingly rare.

Well, that’s all I’ve got on that subject… I’d love to hear from you if you have any insight as the “ultimate solution” to the problem of communication within a small business still eludes me!

Continue reading...