Re: Joel Spolsky on languages for web programming

On 9/6/06, Devin Mullins <[e-mail]> wrote:
> Long post! Ack!

Yeah, research and reqs gathering has pimped out my typing
skills. I have written more english than code this year. :sob

> So... the 50-100% extra time is okay, as long as it's known up front?

If its known, and can be planned for, and identified risk is either low,
or has had backup plans for, then its generally okay. Unless you
are in a situation where you are making software commodities
(like yet another social networking site) and productivity converted
into exclusive features is what drives your business, the productivity
hit is okay.

Or at least thats project manager think, that a low-scalar productivity
hit is fine as long as there is no additional hit due to risk.

I don't tend to agree. Once a project schedule extends beyond a low
single digit number of months, it turns into pure fantasy. Also software
schedules are like fly paper - they longer they are, the more shit
sticks to them. 'Completed' software attracts better change requests
than incomplete software.

When the conception date and the ship date become very far apart,
project sponsors forget their original reasoning behind a feature request.
You can bitch about marketing all you want, but they are just human
too.

I have done enough agile work in Java to appreciate on a surface level
what Ruby/Rails can do for you. *I* believe the productivity boost is
extremely important, and the time saved can be applied to polishing
the final product or introducing more features, or as a hedge against
possible risky areas of Ruby/Rails (say no secure SNMPv3 support)
where we might have to wrap a java library or something. Under those
circumstances, risk assessment is about showstoppers like:
- you cannot accomplish something in Rails *at all* - you have overstepped
the current capabilities of the framework and Ruby has no good fallback, or
existing functionality is not 100% ready for primetime or your needs
(e.g. crypto stuff, i18n, enterprise libraries, install on a specific
platform etc.)
- its single CPU performance of a properly optimised solution is 'not
good enough' over a java equivalent
- Rails app distribution to customers is hard to achieve well

These are *my* risk concerns. I am listing them, not stating them as
facts. But the other concerns I am familiar with too, as I know how my
peers and superiors think, and they are the kind of questions they will
ask. So I look out for them - even though I have personally confirmed
them as non-issues, I need to have a prepared defense against them.

> Why not just pad the extra 50-100% for the Ruby estimate, and just spend
> the last few weeks partying when you finish early? :P

lol! They would probably get suspicious as my tan started to improve all
the way up to the march delivery date ....

> >> 2. What such case studies have you read about the other options you're
> >> considering?
> My question had an agenda. I meant: leading up to the moment you picked
> [Java, I presume], what case studies had you read about its use? Just
> trying to scope out for any double-edged swords. Sorry; I was cranky
> yesterday.

Heh. I am thick skinned - I use up all my irritability on marketing, heated
responses don't phase me.

And to subvert your agenda, its probably because of the Java situation
that people are sensitive about technology choice. During Java's early
adoption phase there was really nothing like it at the time, and there
was a total upheaval in software development as this web thing started
to become a platform.

Java eventually matured into a successful language, after burning through
the hype bubble. Once the smoke cleared people realised that WORA
didn't mean Java Office, or Java OS, but in fact meant that java code
would run on whatever you ported your runtime to. Once it failed as a
consumer GUI, people moved on to what it was really good at, like
security, i18n, network software, development solutions and web apps.

But people really got hurt in the 1.1 era. It had enough language/api
features to be useful, but it hurt to develop in. As a result people are
anal about technology choice. Of course now we actually *have*
choices to be anal about.

And if they ever got burned on a development choice before they can
go ultra-conservative. There is a perception that Rails may have certain
weaknesses. Many are not true, some are. Not all the false ones
are being properly dismissed as rubbish, and some of the true ones
are not being debated enough for them to be quantified.

And joel is right: technology steering committees are a useless
waste of time.

> Well, at RailsConf, I talked to a guy who'd never programmed in his life
> before Rails, and he said that within 2 months of picking it up, he'd
> deployed an app to a customer. *shudder*

Nods. I was very fascinated by how it promotes best practices. It removes
unnecessary choices from you, like where your view code goes, where to
put your utility code (helpers) and wiring code (controllers), and how to
break up html generation usefully (partials & components).

Hell, once I am up to speed I am thinking of teaching it to my Dad, who
close to retirement age is considering learning how to do some development.
In the interests of prolonging his existence on this planet, I think Ruby/Rails
is an excellent choice. Its got practical applications, it has a short feedback
cycle for learning, and principle-of-least-surprise is a real phenomenon and
not language-fanboy-speak.

Also - imagine if your customer isn't too fussy and is happy enough with
scaffold code ... it boggles the mind at how far you could take it and how
many people you could get to do it. The hardest thing about that kind
of software development is finding more customers like that.

> Hrm. The only thing I really recall breaking a whole bunch is Engines.
> That said, through experience developing some of these apps, I've become
> much more conservative of what plugins I use. I wrote my own tagging
> code; were I to do it again, I'd write my own user/password code; etc.
> Not so much because of Rails upgrades causing breakage, but because the
> plugin implementations turned out to be flawed/buggy (read: poorly tested).

Well this is what I call a legitimate concern, but it is also something that
I think is hugely overblown by jittery decision makers. Considering the
speed of Rails development, by the time you would start to encounter
plugin issues, say 4-6 months into the project those issues may have
been resolved, or replacement plugins may have arrived. Hell, even swapping
out the standard interpreter with JRuby might address it as you just use an
equivalent mature java library instead.

The discussion I read here about new Rails versions breaking plugins was
more about the philosophy of Rails development - that maintaining
backwards code compatibilty wasn't as primary a concern as it is in
other frameworks. Thats the digest, I don't know how true it was, but
it has now added to my Perception(tm) of rails. I have looked, and
identified that I need Globalise or an equivalent, and BackgroundRb.
And write all my own code.

> > to. People with an eye for risk take that pretty seriously - they
> > expect security issues, but not rock-and-hard-place conflicts like
> > that.
> That's true, and that's one of the ways in which Rails needs somewhat
> guru coders -- ones who test their app thoroughly, and are able to patch
> the broken spots when they come up.

Theres also a concern that if you have written something for a customer,
you need a way to update them or patch their install. Thats the flip side
of my deployment concern: automatic updates to software.

>
> >> Ruby/Rails libraries/plugins/tools are all over the map
> > i.e. all over the place - that makes it risky
> Same could be said about any language, no?
>
> > I don't see enough libraries
> > that I am likely to depend on, at a mature enough version to warrant doing
> > anything mission critical with them. Theres a lot of libraries that require
> > binary installations that are unavailable on all platforms.
> Ah, yeah, can't help you there -- I haven't needed much in the way of
> libraries -- XML parser, HTML parser, etc.. I might be able to help you
> with the second part in a few days -- I'm finally getting around to
> profiling, and hence need to compile Shugo's or ZenProfiler for win32.

I guess wait one year. A lot of this is due to the 'enterprise-style' APIs
coming into Ruby fairly recently (so new the docs aren't up to date
e.g. HTTP class).

> > write your own equivalents (which will wipe
> > out your rails productivity boost).
> Well, not according to the Relevance folks, but I admit, they seem
> pretty adept.

Being at their level is the 'goal' you might say - and my guess is that
a serious showstopper in a library or plugin could wipe out the productivity
boost for an organisation getting into Rails. Which is what I am primarily
concerned with.

> I'm confused... are you asking if the Ruby language is as quick to
> program in as the Rails framework, or if the framework is fast despite
> the language? Or are you talking about writing a Ruby extension?

I am not talking about productivity boost here. I am looking at a
legitimate scaling concern. If you need to do something strange
in Rails you simply write Ruby code in your helpers that does it,
or write a funky plugin.

However I was raising a concern that perhaps Rails is only highly
scaling if you don't do this or are otherwise very careful about how
you introduce pure-processing code like this.

> In any
> case, I don't know if you are going to get metrics much more specific
> than the Relevance posts. People seem pretty guarded about their own
> professional productivity. Probably a little productivity abritage going on.

Yeah they were good. And refreshingly honest. I have been through
several hype bubbles before and sycophants do more harm than
good.

> Interesting. Well, Rubyscript2Exe is supposed to do just that. Never
> used it, but seen an example package being run. A little slow to start up.

Deployment is way more involved than that, but its a start. An interesting
way to look at what I mean by deployment:
"What would be involved to make your Rails app installable by your Mom"
Basically going from nothing (and I mean nothing, you can't expect
Rails knowledge or domain knowledge on the part of the person installing it)
to 100% working Rails app.

You also need to consider the update case as well, like Windows updates.

Once this is a solved problem, you can address all the intervening problems,
like advanced/customisation by someone who knows their stuff and wants
to use their existing web server/database.

And then you address the remote install problem, and look into whether you
need to do anythign wierd for virtualised systems.

> > I don't have a problem with working on Rails myself, I always figured
> > that if
> > I could get a functional prototype of what our main app is doing,
> > working in
> > Rails, it would be a good start. But its all these edge conditions that
> > would
> > kill Rails adoption - and I don't have the time to both address/investigate
> > the concerns
> Ah. Well, I might, were I working for you.
>
> But I'm not. :D

What bugs me is that in order to make a convincing pro-Rails argument
I would effectively have to write the app (software that manages other
software agents on the network) in its entirety. While Rails
has excellent productivity improvements its not *that* good, not for someone
like me who is learning still. While I am tantalisingly close to getting
certain aspects working in some rough code (even cheating: communicating
with the web-enabled software agents by scraping their UI with
WWW::Mechanize or even WATIR) the only way to determine if there are
no i18n issues is to Globalise it, and the only way to address how
installable Rails is, is to make a 1-click installer. And thats not fun, at all,
though WIX might help.

More seriously though is the investment in process-type stuff (tieing in
with our automated build system/auto testing etc.)

Yeah, just one more body would make the difference. The scary thing is
that the steps required to rapidly prototype a java app usually mean
that the code is only fit for burning afterwards. But the difference between
a Rails prototype and a proper app is some refactoring and going back
to write the unit tests.