Slashdot Mirror
Thinking about Rails? Think Again
wolfeon writes "In 2005, Derek Sivers of CD Baby wanted to scrap his site and perform a rewrite in Rails. He hired Jeremy Kemper, also known as bitsweat on Freenode, to help on the project. Two years later, through blood and sweat, the project was then canceled because of limitations of Rails. Rails just wasn't meant to do everything since it is very much "canned" project. Mr. Sivers has written an entry in the O'Reilly blog: 7 reasons I switched back to PHP."
I disagree with the vast majority of those points. The only two that I agree with is giving consideration to scalability and getting user feedback. The rest are illogical conclusions based on a failed project whos real failure was poorly specified requirements.
Certainly, Web UI's are not appropriate for everything. They should really only be used if there is some overpowering need (like the ability to access the data from anywhere without having client apps installed). They also apparently gave zero thought to existing processes and staff skillsets.
Avoiding AJAX or any other technology because you tried to use it for something it wasn't good at is patently stupid. There are good uses for the technologies. This just wasn't one of them.
If you need web hosting, you could do worse than here
My advice is to analyze the needs of the system before designing it. Don't assume a GUI or AJAX front end is the best possible way to do things. My favorite example is the library system in my county: their computers are using a console system for check in/check out, card processing, etc. The beauty of it is that the bar code scanner they use behaves like a keyboard, so that each scan is just a series of a numeric keystrokes following by an end-of-line. It is simple, the 80 year old librarians have no problem using it, and it doesn't require any difficult to coordinate mouse movements (as anyone who has studied this knows, using the mouse requires a lot of brain activity than using the keyboard). The console very accurately maps the workflow; a GUI wouldn't add very much, other than sheer lines of code, and a web interface would actually slow down the people who need to use it.
Sure, there are cases where a GUI or web interface is better than a console interface. But that is why an analysis is needed before any code is written. As your friend's situation demonstrates, a well design system can work for many years without any trouble.
Palm trees and 8
I just can't understand how your input data makes you assume your conclussions. Except from the "why change a system already working just OK?" which I'm 100% with you, I extract very different ones from your provided data:
"In the mid-1990s, the company in question built their IT operations [...] They wrote much of their in-house code"
I read here: in the mid 90s the company built a tailor-made IT system engineered by their internal knowledgeable technical staff.
"what is somewhat unique is that they essentially continued to use those same systems up until 200what is somewhat unique is that they essentially continued to use those same systems up until 2006."
We know their staff was knowledgeable and that the system fitted well their needs from the simple fact that it managed to work about 15 years without major complains.
"One of the main reasons why they didn't switch is because their software systems worked just fine"
Exactly what I was saying.
"They even got extremely lucky in the first place, as the developers who initially designed and implemented their software systems did so in a way that allowed for the systems to easily scale"
Do you think that's "luckyness"? That properly scalable systems grow up "per chance"? No: it was properly designed, that's why the system scaled, not because "luck".
An now, for the problems:
"A variety of consultants were apparently called in"
I read here: A variety of *external* resources that surely couldn't know the bussiness better than their old internal counterparts (things cannot be done much better than "OK", and that was the standard to beat), and that surely held their own agendas (like pushing the technologies they are knowledgeable about, instead the ones that best fitted, if only because the old "for a man with only a hammer every problem seems a nail", if not worse, "Certified Microsoft Gold Partner That Gains Money Every Time Microsoft Technologies Are Pushed Into A Client") were in place to design the new system.
And this is the very and only problem: By the 90's they had knowdledgeable internal staff. By 2006 they went to external unfitted consultors. I bet there's an untold story here that includes those "so expensive" Solaris sysadmins and C++ developers that were fired by a "smart" manager looking for profit. All the particular problems you outlined are not problems but consecuencies of this. Of course the new web-based GUI could be Firefox-tested -if knowledgeable people were in charge. Of course the new web-based GUI could make use of proper keyboard-based navigation -if knowledgeable people were in charge. Of course that the proper ammount of iron could have been pushed on the backed (specially after 15-more years of stats and usage-patterns) -if knowledgeable people were in charge.
No one of them are strictily speaking problems with AJAX, or Windows, or dot-net, or whatever the technology (while going from a perfectly working C++/Unix environment to an all-and-only-Microsoft is a very hard hint about management going nuts). All of them can be pointed out to a very common tendency on IT: fire the old knowledgeable technicians that put the means for the company to grow and stay there in first place and contract cheap minions and expensive external consultants as substitutes; then look as a very smart manager that saves the company some pennies; then the obvious "???" and finally the "wreak havoc" instead of "profit".