Informality in code can be a problem

Okay... Time to work through a technical issue. :-)

As you might recall, I'm working on a project using the Ruby programming language. Now Ruby, the language, has some close cultural ties to agile programming, a business (slash-development) process that doesn't feature "design" in a way I'm used to. (That's one of the keys, I think...)

Agile programming is more about architecting as you go, which is fine - ideal, even. (We're not building buildings, we're developing abstract functionality that has equally (more?) abstract methods of representation. Or something like that. :-) ) Writing tests and then code to manage some function or other is perfectly reasonable, but it does strike me as a bit Visual Basic 1.0-ish. That's not to say I can't do preliminary design work - I do! - but it seems to me that the Ruby community rejects that sort of formalism. It's almost as if some Ruby developers have an allergic reaction to it. A bit like some PHP developers break into hives at the thought of having any structure in their code.

What all this means is that useful tools like interfaces - code-level definitions of what needs to be implemented - and abstractions (code that contains some implemented methods (etc) and some unimplemented, but defined, ones) are, as I've said before, implemented in an informal business process and hopefully a read-me file. That lack of formality can be a hinderance.

I'm working with a couple of Gems, basically bit of encapsulated functionality, that I think need to have a more formal definition of what they do and how they do it. (No names as I've not settled on using these gems, and don't want to paint them unfairly.) If they had interfaces, and even abstract classes, I'd be able to plonk them into my code and use them, knowing that they could be easily replaced if I needed to do that. As it is, if I do decide to replace them, I have to either write a wrapper to make something else emulate "that bit" of their functionality, or rewrite my code to get around the problem or just write the functionality into a new gem or two. In PHP or Java, C++, et al, I can look at the interface definitions or abstract classes and quickly figure out what's what. With Ruby, I can't do that very easily. Mostly because programmers tend not to be the world's greatest documenters! In other words, I have to know what the innards of a gem are before I can decide if its usable in my application or not. And if I implement it, and find out that it's not quite working, I can monkey-patch it (write code that makes it do what I want, which is a very fragile solution), or look for something else and end up rewriting bits of code to handle the new gem.

Okay. Problem "solved".

I'll abstract the implementation. Makes for a bit more code, but whatever. Ruby is a cool language, but I am really having a problem with its ability to turn every web app into a "Ruby Programmers Permanent Jobs Act. C'est la vie, etc. :-)

Carolyn Ann