Slashdot Mirror
Too Much Focus on the Beginning of Software Lifecycle?
rfreedman asks: "Most of the buzz on the web about software development tools, languages, and practices seems to concentrate on getting software developed as quickly as possible. Take, for example, the current huge hype about Ruby on Rails, and how it allows the creation of a CRUD web-database application x-times more quickly than every other environment. It seems to me that this concentration on initial construction of software ignores the issue of total cost of ownership. Most people who develop software also have to maintain it, and have to support changes to it over long periods of time. As has been discussed many times over the years, maintenance is the most expensive part of the software development life-cycle. I think that the software development community would be better served by discussions of how to build more robust, flexible, and maintainable software (thereby driving down TCO), than by the endless discussions that we currently see about how to build it quickly. What do you think?"
I'm pretty sure a big part of why these frameworks are popular come from the fact that they allow for smarter, fewer lines of code, ultimately making maintenance easier. Much of the lower level problems like database connectivity, optimization, resource management, etc. are handled by these frameworks and other higher level languages which in turn allow the developers to focus on the business logic, rather than debugging their latest build of the database.
At least that's why I assumed rapid developement frameworks caught on.
shouldn't it depend on the type of project. i'm pretty sure you don't want a banking system based on network effect
For years I've been working with pure, vanilla PHP outside of any sort of buzzword framework. That's not to say that my code was unorganized (quite the opposite, I'm pretty anal when it comes to code clarity), just that I believed as the original poster did that MVC frameworks and the like weren't worth the time.
I've recently started experimenting with CakePHP, and it has somewhat changed my thinking on the matter.
A lot of things we tend to do, especially in web development, get repeated over and over. Data validation, SELECT statements and their JOINs, administration backends, login systems... I could go on. In my experience, it's been when I've been bored to death of doing something repetitively that errors would start to creep into my code. It's pure probability: the more you do something, the better chance you have of one of those things having something wrong with it.
RAD solutions posit a solution to this, centralizing all those repetitive things so you avoid having to type the same thing over and over, and thereby reducing the chance that there is an error in any one of those repeated things. If there's an error in the actual framework, one can fix it, ideally, in one location rather than throughout a script (though the frameworks themselves tend to be closely scrutinized to avoid any obvious issues).
I guess what I'm trying to say is that coding less can mean coding better, as long as you understand why you're coding less, and not doing it simply because you can.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
It's not like programmers just love to dive into maintaining code either you know. They're usually the ones just chomping at the bit to chuck everything and start something new and exciting to put on their resume (or blog about these days).
My experience is that I get huge long-term benefits, not just the faster up-front development. The main reason I develop in rails is that I have much easier long-term maintenance, and making changes to applications has been easy. Way easier than the php code that I have out there.
Put another way, I think your rails slam is unjustified.
Do you have ESP?
I worked for an outfit on the west coast last year for a few months during a systems transition. One of the principals came to me one day and asked what was taking so long. He was an old school COBOL programmer from nineteen tickity two who didn't really understand oop and the monstrosity his company was building so I tried to walk him through what we were doing, saying in the process that I was working at getting it right the first time. I'm always thinking in terms of maintenance down the road. He flipped out and said, "I don't want it right, I want it now!" I kid you not.
I don't work for them anymore.
I understood his point of view however. He needed to get buttons and clicky things in front of the customers as fast as possible. It seems customers will accept the mediocre over waiting and those folks are running a highly successful business as well a creating a giant mess for themselves in the repository.
In the end it seems that people will accept garbage over nothing. I personally don't subscribe to that philosophy but the reality seems to be that it does make for a pile of money.
Please keep in mind that J2EE is a lot more than CRUD applications, making Ruby's capabilities a sub-set of what J2EE can accomplish.
The next version of Java will integrate scripting langages (JSR-223), so it's entirely possible that we will see Ruby on Rails applications implemented as the user front-ends to larger J2EE applications (this is already happening with PHP).
And of course, there's nothing wrong with rapid-prototyping. Ruby is becoming to web applications what Microsoft Access is to Windows desktop database applications (e.g. RoR:JSP Access:PowerBuilder).