SteveStreeting.com

As a developer, there’s an polarity of choice when it comes to frameworks regarding whether you would rather lean towards more compact code where most things are implied, or more verbose code where most things are laid out explicitly - most obviously in the web development sphere.

Ruby on Rails is continuing to be a hot property simply because it’s quite elegant and very compact for the functionality it delivers. If you’re making a relatively simple web-based, database-driven application there’s probably no faster way to do it right now - although significant concerns about practical scalability remain, perhaps Ruby 1.9 will make things better once Rails supports it. However, in order to deliver all this power, Rails makes a lot of assumptions about the way a typical user is going to want to organise things, such as driving the structure of the model from an existing database structure and auto-wiring views and controllers etc. It means that when you look at some Rails code for the first time, it can often be startlingly short and leave you wondering where the rest of it is.

In terms of rapid development, this is great. But, brevity does come at a cost, which is that when you look at the code, you’re not seeing the whole picture. That’s always the case to some degree when you’re working with OO or layered software, in that implementation hiding and the ‘onion skin’ effect mean that implementation details are always hidden somewhere. However, one difference is that in a less adaptive application development structure, the base implementation, the part you don’t necessarily see unless you start to heavily dig, is a constant - it’s invariant across all applications. Anything specific to your application will be there in the code, particularly the ‘assembly’ aspects - how it’s all tied together. When you bring in implicit configuration too, this is no longer the case - there’s some ‘magic’ in there that makes things ‘just work’, which is very cool, but it also kind of makes me feel a little nervous. Because what if it ceases to ‘just work’? How do I figure out what went wrong? If I’m looking at code someone else developed a year ago, will I be able to piece all the potential contributing factors together quickly, compared to developing a new app myself?

I had an experience a number of years back with a design tool that let you create complex (fat) GUI applications by dragging, dropping & wiring components visually. It was really impressive when building new things, and made it possible to create complex GUIs with appserver integration incredibly fast, writing almost no code at all. As time went on though, we found that while we could build things quickly, coming back to the more complex designs later to resolve issues became a bit of a nightmare, simply because picking apart all the ‘magic’ bits that were happening was problematic. When it worked, great, but when it didn’t it took a lot longer to figure out why. We found that in many ways it was like running into a tar pit - at first you were flying through it, but after a certain level of critical mass and complexity had been achieved you had a tendency to get bogged down. The metrics of effort versus output over time were not favourable, considering that a typical application spends far longer in maintenance than it ever does in initial development. From then on I’ve always been a little cautious when presented with tech that purports to make building applications fast, because I want to know that it also makes maintaining them fast too. I don’t have a handle on what Rails applications are like to maintain over a significant amount of time because I’ve never done it, obviously the ‘build’ phase is fast, but does it suffer from the problems I had with visual design tools to any degree, or does the high level of convention mitigate that (assuming your application fits into that slot neatly)?

On a purely developer level, I like things to be quick and no more verbose than they need to be, but I also dislike having to be too trusting. I’m never really comfortable when something ‘magically’ happens in technology and it’s less than obvious as to why - I tend to prefer a slightly more explicit line from cause to effect, simply because if I feel that if I can’t obviously see why something worked, how point A got connected to point B, I have a blind spot  which may well come up to bite me later. It’s also comforting to browse some source and see all the pieces slot into place, without any glaring gaps where ’stuff happens’. On balance then, I tend to prefer systems that are explicit, but at the same time I don’t advocate mindless verbosity - there’s a balance here. I quite like Spring in that regard, there’s a lot of prebuilt functionality packaged in there, but while the implementations are wrapped and out of the way it’s all wired up explicitly (unless you use auto-wiring, which I avoid) which for me is confidence building, I can browse the configuration and ‘connect the dots’ easily, dipping in deeper where I want to. It’s not what you’d call a rapid web development environment though; it’s convenient, powerful and very solid, but you’re unlikely to get a ‘20-minute app’ screencast out of it, which seems to be the primary measure of worth these days

I’ve played with Rails a little, but have never used it for anything serious mostly because I’m afraid of the scalability issues I might encounter when it’s too late to do anything about it (except rewrite using something else) - once those scalability issues are resolved I may come back to it. In the meantime, if I had a need for truly rapid web development I’ve got my eye on alternatives such as Pylons or TurboGears, which share a lot with Rails but are based on Python which is somewhat more mature & proven for sizeable deployments, and they’re also a tad more explicit about some elements (like model definition) which I prefer. Whatever option I might choose, I would prefer to dig into the framework source to better understand how the automation that is there functions, rather than just accept it on face value. Rails, Pylons and TurboGears  are all open source of course so that’s at least possible - I don’t think I would ever use them if they were closed source, because ‘magical and opaque’ is the very worst combination I can think of. Not everyone feels like that I know, many people are happy to just trust that something works and move on (and in a closed framework like .Net, that’s your only real option), but over the years I’ve bashed my head against frameworks & libraries enough to dislike trusting things I can’t examine, trace through and even fix / extend when the chips are down. 

Any opinions?