Hawaii's Science, Technology and New Media Community
I Love Rails, but I Hate its Popularity
Despite the fact that Ruby on Rails has been around since 2004, I'm still surprised and dismayed at how many "Amateurs" (or non-Passionate Coders as Stephen McMahon recently blogged about) are trying to get into Ruby on Rails.
Much like what Stephen encountered, I seem to be rescuing a lot of Rails Projects recently, with Ruby code made to "look like" an older, more established language.
One recent code snippet I came across was written by a nameless Ruby on Rails programmer in Hawaii. While it's not as bad as what's found in The Daily WTF (a fine site I highly recommend to any serious Programmer), this is still not the kind of code that Honolulu's Ruby on Rails Coders should be propagating, much less tolerating.
The author of the following snippet seems to have no grasp on the merits of using Collections, as a lengthy hunk of code was custom-written for an e-Commerce site:
Alrighty, go ahead and cue that Sam Kinison clip (NSFW) for me, please:
"Oh! Oh! Auuuugh!!!"
Ow, my eyes! Such unsightly code! I thought this was supposed to be Ruby, not Visual Basic or COBOL! I'll bet that even an experienced JavaScript coder would've tried to write the above lookup as a JSON Object or something. Blecch!
If you're writing Ruby code like the above, and consider it perfectly acceptable code, please get out of the game NOW. You're doing nobody any favors by writing such poorly-styled code. In fact, I've fired (dismissed) a few expensive, $300/Hour consultants in Las Vegas for writing unsightly code like that. Thank goodness I was the Technical Lead back then.
If you're writing code like the above through inexperience, though, you might want to invest in some reference materials for your personal library. I suggest The Ruby Way, and The Rails Way as starting points.
Anyway, here's a slightly better way to implement the above, using a Hash Lookup in Ruby:
This is better style for the intended operation, in my opinion, as it's much clearer that only one thing is supposed to happen in the code snippet: determine and apply a surcharge (if any) for specific zip codes. The only acceptable reason to use the original "Big-Ugly Case Statement" would be if several Cases can't easily be grouped into a common, reusable pattern.
Aim for simplicity when possible -- you'll thank yourself 6 months later when you need to go back and update your own code.
Of course, to be a real Rails Rock-Star and have your Inbox flooded with Job Offers -- quite possibly from me -- the above really should have been done as a new Rails Model. At least a "script/generate scaffold ZipSurchargeLookup code:string surcharge:integer". That way, the above is about as simple to implement in Ruby code as this:
Furthermore, by doing the lookup as a Database Table, the ZipCode surcharge can be maintained by the eCommerce site's administrator via Web GUI, rather than maintained by a Programmer spelunking around in Ruby code.
You don't want to be stuck doing menial "Code Maintenance" tasks like updating hard-coded Zip Code Surcharges in low-level Ruby Code, do you? Because if you do, you probably shouldn't be coding in Ruby on Rails, or coding in anything else for that matter.
Much like what Stephen encountered, I seem to be rescuing a lot of Rails Projects recently, with Ruby code made to "look like" an older, more established language.
One recent code snippet I came across was written by a nameless Ruby on Rails programmer in Hawaii. While it's not as bad as what's found in The Daily WTF (a fine site I highly recommend to any serious Programmer), this is still not the kind of code that Honolulu's Ruby on Rails Coders should be propagating, much less tolerating.
The author of the following snippet seems to have no grasp on the merits of using Collections, as a lengthy hunk of code was custom-written for an e-Commerce site:
case address.zip
when "96701"
local_surcharge = 15
when "96734"
local_surcharge = 15
when "96744"
local_surcharge = 15
when "96782"
local_surcharge = 15
when "96797"
local_surcharge = 20
when "96792"
local_surcharge = 25
# ... all the rest of Oahu's Zip Codes hardcoded with values here...
end
if local_surcharge
total_charges = total_charges + local_surcharge
end
Alrighty, go ahead and cue that Sam Kinison clip (NSFW) for me, please:
"Oh! Oh! Auuuugh!!!"
Ow, my eyes! Such unsightly code! I thought this was supposed to be Ruby, not Visual Basic or COBOL! I'll bet that even an experienced JavaScript coder would've tried to write the above lookup as a JSON Object or something. Blecch!
If you're writing Ruby code like the above, and consider it perfectly acceptable code, please get out of the game NOW. You're doing nobody any favors by writing such poorly-styled code. In fact, I've fired (dismissed) a few expensive, $300/Hour consultants in Las Vegas for writing unsightly code like that. Thank goodness I was the Technical Lead back then.
If you're writing code like the above through inexperience, though, you might want to invest in some reference materials for your personal library. I suggest The Ruby Way, and The Rails Way as starting points.
Anyway, here's a slightly better way to implement the above, using a Hash Lookup in Ruby:
zip_lookup = {
"96701"=>15,
"96734"=>15,
"96744"=>15,
"96782"=>15,
"96797"=>20,
"96792"=>25,
# ... all the rest of Oahu's Zip Codes hardcoded with values here...
}
# Add the lookup value, or $0.00 if not in lookup hash
total_charges += (zip_lookup[address.zip] || 0)
This is better style for the intended operation, in my opinion, as it's much clearer that only one thing is supposed to happen in the code snippet: determine and apply a surcharge (if any) for specific zip codes. The only acceptable reason to use the original "Big-Ugly Case Statement" would be if several Cases can't easily be grouped into a common, reusable pattern.
Aim for simplicity when possible -- you'll thank yourself 6 months later when you need to go back and update your own code.
Of course, to be a real Rails Rock-Star and have your Inbox flooded with Job Offers -- quite possibly from me -- the above really should have been done as a new Rails Model. At least a "script/generate scaffold ZipSurchargeLookup code:string surcharge:integer". That way, the above is about as simple to implement in Ruby code as this:
zip_lookup = ZipSurchargeLookup.find_by_code(address.zip)
total_charges += zip_lookup.surcharge unless zip_lookup.nil?
Furthermore, by doing the lookup as a Database Table, the ZipCode surcharge can be maintained by the eCommerce site's administrator via Web GUI, rather than maintained by a Programmer spelunking around in Ruby code.
You don't want to be stuck doing menial "Code Maintenance" tasks like updating hard-coded Zip Code Surcharges in low-level Ruby Code, do you? Because if you do, you probably shouldn't be coding in Ruby on Rails, or coding in anything else for that matter.
Comment
-
Comment by Nizwer Husain on February 27, 2009 at 9:55pm - I have been programming since assembly 360 and Fortran IV in 1974. The high point in programming and creativity I believe was during the Lisp/Artificial Intelligence days in the mid-1980s. Unfortunately a lot of programmers want to learn the next buzz, hype it, get tired of it then move on. Granted Ruby on Rails has a lot of nice features. Compactness of expression, convention over configuration, concept of active records etc. Since Lisp has lost its support from the business world for nearly 20 years will have to live with Ruby Rails for now. The horrible case statement just shows the person is a bad programmer regardless of which language he coded in. Just look at what Java, J2EE and all the other acronyms that mediocre minds brought into this world. It is no accident that hardware has been able to make progress year after year, because they don't try to find different ways to the do the same thing every few years as programmers do. As for consulting rates? they are going down down down. Someone joked that an offshore programmer will work for a sandwich. Quite likely the software project managers we have these days have never written a line of code in their lives (have been nursing their MicroSoft Project files) so crappy code wouldn't catch their eye.
-
Comment by John on November 14, 2008 at 11:33am - While there may be programmers who have boring jobs, programmers are behind some of the most exciting innovations in the world and it's their passion that drives those companies. I'd love to hear about all the exciting passionate work that CPAs are engaged in.
-
Comment by Timothy Little on November 14, 2008 at 11:26am - I don't believe certification, per se, is the way to go. There is a plethora of certificates floating around for our industry now. The problem is that those certs aren't necessarily worth the paper they're issued on. So, if (and it's a big if) there were a cert available that meant programmer X understands why best practices became best practices and what constitutes acceptable code, I'd be on board. Until then, color me skeptical.
-
Comment by Daniel Leuck on November 14, 2008 at 11:17am -
Indeed, I would tend to think software developers, on average, are significantly more passionate than CPAs, JDs or MBAs about their field.
Perhaps, but I wouldn't place any bets. There are plenty of developers slaving away at insurance companies on projects that are marginally preferable to sticking bamboo under your fingernails.
CPAs also have a much higher standard for the minimal level of competence required to work in their field. What would you do if your $300/hour CPAs work on your finances was as sloppy as the code in this post?
'Bar association' - So we should be more like lawyers?
In this sense, yes. There should be a universally accepted certification for professional software developers that possess an understanding of programming fundamentals, best practices, development methodology, etc. This is particularly important when a non-programmer with a limited ability to evaluate programmers needs to hire one. It would also save enormous amounts of money in terms of screening, even when the interviewer is development savvy. The platform and language specific certifications have their place, but they often don't cover general programming competence.
-
Comment by John on November 14, 2008 at 8:28am
-
There are many fields where people lack 'a modicum of passion.' Indeed, I would tend to think software developers, on average, are significantly more passionate than CPAs, JDs or MBAs about their field.
'Bar association' - So we should be more like lawyers?
-
Comment by Daniel Leuck on November 13, 2008 at 11:57pm
- Part of the problem is that software development is still a relatively young and unregulated trade. We don't have the equivalent of a bar association, so any Tom, Dick or Harry can claim to be a professional developer. You might assume that most people having chosen software development as their profession would have a modicum of passion about what they do and that pride would compel them to achieve a basic level of competency. Unfortunately, as we all know, you would be wrong. It seems to be a profession that many people end up doing accidentally.
-
Comment by Timothy Little on November 13, 2008 at 11:20pm
- I've been known to rant about ugly code, too. I feel your pain. I pride myself in learning the right way to sling code in whatever the chosen environment. Unfortunately, there are a lot of coders who are not passionate and only learn enough to make the code work. I suggest as punishment they be forced to go maintain that code when the time rolls around.
-
Comment by Cameron Souza on November 12, 2008 at 5:52pm - $300/Hr? You could get a software architect / neurosurgeon / rocket scientist for that amount in Hawaii!
-
Comment by Laurence A. Lee on November 12, 2008 at 10:27am -
John,
Not much can (or should) be done to get around progress, and I agree that Rails makes it easy to do certain tasks.
I've wrestled with the "code quality" problem several times when migrating teams away from older platforms (COBOL, VB6) to current platforms like C# and VB.NET, and the transitions have never been perfect.
One reason why I feel real Computer Science students have a huge advantage over MIS or EE students is precisely because they are (or should be) exposed to different programming languages. Sure, writing code in Lisp and Prolog takes a lot of getting used to, but if you learn to do it EARLY in your development, you get a real appreciation for cognitive things like Algorithms and Thought Processes, rather than on what Code Patterns (snippets) can be copy/pasted in to get a task done.
When you have multiple languages (with different syntaxes and thought processes) mastered, it's easy to adapt to a new language or framework.
Back to the COBOL/VB6 coders -- they tend to be stuck in their ways because they've only ever seen or worked with that platform. Show them a Collection, and they can only think of it as an Array; show them the Event-Driven model, and they'll write everything within "One Huge main()" function tied in to handle a Button press.
This is exactly the "culture change" problem that Stephen is grappling with: how do you evolve a worker's capabilities so they can write better quality code? And more importantly, how do you deal with a longtime worker who is unwilling to adapt?
To evolve peoples' minds, I usually try to educate and stimulate. I suppose that's why I tend to write blogs, too -- with enough bait to stir up a thoughtful reaction.
As for those unwilling or unable to adapt - if they have earned enough seniority and are otherwise capable, I'd suggest promoting one or two of them to Project Manager (i.e. transition them away from being Active Coders). They know the systems and the business needs, and their expertise is still a valuable asset.
The rest would go the short-list for layoffs the next time there's a Bad Economy. Sorry, but if a worker can't adapt to continue to be productive, they're costly deadwood. In bad economic times, a business just can't afford to keep the deadwood around.
Truman,
Yup, $300/Hr consultants were writing code like that. What's worse, they came from the Professional Services group of the company who sold us the system we were customizing. Basically, they were "learning" their own product on my employer's dime, and at full price. Of course, the consultants probably only received $50/Hr of that, with the vendor pocketing the rest.
Not to mention, we also paid for their flights (in by Monday, out by Friday -- they get to go home for the weekends), and we gave them full RFB (Room, Food, and Beverage) status at one of our properties.
It was a sweeeet Java gig for everyone. Too bad their code quality wasn't worth the price.
-
Comment by Truman Leung on November 11, 2008 at 6:41pm - $300/hr consultants were writing code like that??? Ugh. Well, thinking is that there are newbies everywhere. And while their code may cause involuntary cringing, we were all there once upon a time. I always cringe when I look at my code from a few years back. Don't we all?
© 2010 Created by Daniel Leuck
You need to be a member of TechHui to add comments!
Join TechHui