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?"
Maintenance? If you can lower the cost of creation enough, it's cheaper to just start from scratch every couple of years. It's the same phenomenon seen in blenders and automobiles. Send it to the landfill and get a new one made.
This phenomenon is only bound to accelerate as software labor costs go through the floor due to offshoring.
STOP . AMERICA . NOW
The movement to develop "quick software" is not for the sake of developing something fast at the expense of other concerns. It is meant to address requirements problems, which are the life or death of an applciation.
It's rare for a customer to know what they want. Even worse, alot of development happens without customer involvement. For example, there is usually a huge early requirements meetings, then developers walk away and write code for 6 months. Sure there are demos in between, but they are usually heavily scripted to give the illusion of progress. At the end the developer shows up with a system and the customer wants to change about a bazillion changes.
So...the recent movements in agile or rapid or whatever you call it grew to address these issues. By getting up a functional prototype quickly, you get the customer usuefully involved early in the process. They can use the system and begin to get an idea of what they really want. If you chunk into 4 or 6 week cycles you can have continuous deliverables. And if you focus on everything such as testing, documentation, and deployment from the get go, you can have complete systems for each cycle so you always have demo ready versions. With frequent, complete releases the customers (and management) are much less worried about progress, which means less stress for the developers.
Somewhat idealistic, I know, but it works pretty well.
Help me take back Slashdot. When did 'News for Nerds' become 'FUD and Conspiracy Theories for Extremist Nutjobs'?
Considering I have fewer lines of code than I had configuration files, I'd say this is way more maintainable. And fewer LOC's usually means fewer bugs, therefore less maintenance.
Oh, and Rails is about much more than rapid CRUD. Although scaffolding (the automatic generation of CRUD pages for a table) is damned handy in some cases, it's expected you'll replace most of it for any non-trivial application.
But as for TCO, and startup costs. If you're starting a company based on software, would you rather
A: Spend 1-200 hours building something to see if there's a market knowing you'll have to rewrite the whole thing
B: Spend 500 hours doing it "right" and then realizing you either have no demand, or people didn't want the features you put in
Ok, that's not much of a choice is it? All that pre-planning stuff is premature optimization. If you can build it fast AND CLEAN, you'll be able to fix it. Most importantly, you'll still be in the game.
Information: "I want to be anthropomorphized"
If you take a closer look at many of the platforms that are hot right now you will notice that the concepts that give them the ability to quickly create well designed websites also make much easier to maintain these sites. With standardization and the use of modular construction, or what some call tiered programming, you have separated the logical processes and are able to change any one part without having to reinvent the entire website. When you need to rewrite the script calls to the backend, you don't have to worry about what the output of the data will look like in the front end because they are two separate processes that hand off data to their suspected components. Think of it like Cascading Style Sheets, one change to the file and all pages using that definition are changed in on fell swoop. This has a major impact on TCO when changes can be address in a single place that will impact across the whole site.
Specifically, how do you convince them that you're cutting corners like they want when you're actually doing good work? All these new languages/frameworks/methodologies promise that all unnecessary cruft has been taken out, which leaves me the choice of skipping something important (and plunging the project into chaos) or taking a lot of abuse from management for "not understanding the urgency of the situation."
I need a language/framework/methodology with built-in timewasting, so I always have something expendable to sacrifice when management starts screaming, "Days matter! Days matter! Everyone has to pull out all the stops or they're not team players!"
This is exactly why I selected Eiffel for a signifiant simulation project that survivied seven years of maintenance. There simply isn't a language that better supports maintenance. It's not just a programming language--it's a lifestyle!
It don't matter how much you save. Even if that week shutdown paid itself back in the next week it would still often be considered too expensive. Because one week of non-deliveries, one week of the customer going to the competitor to get what he needs is considered far more costly then day in day out small losses because of ineffeciency.
When it comes to IT this is compounded by the many horror stories of runaway IT projects that just don't finish and always go over budget. Sure sure, they say, an advanced IT tracking system would save us a bundle each and every day but only after we spend 3 years on getting it installed and then it will break down on everyday with a y in it.
For software development itself this means that people have come to accept that software needs costly maintenance. So why prolong the development to save costs you are not going to save anyway?
A F1 engine is going to be stripped down after a race anyway so why bother making it reliable enough to last more then one race?
And don't forget that software deployment is often a race. Software is rarely written in advance. Usually it would preferabbly be ready yesterday. Have you ever had a project were a company said, we predict that we have a need for a new system in 3 years so get to work? No, 99% of the time it is, we needed a new system years ago so can you have it done by yesterday?
Good luck then pointing out that if only you spend a little more time on it you can make it easier to maintain in 3 years time. They want it NOW!
Learning to accept this is the only way of not going insane at work. Offcourse if you have learned to accept this you will also have become part of the problem. One of the suits who can't see reason.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Each approach has a place in the ecosystem. Reiser4 could only have been developed the slow way, but that was because we were going into a mature market with solutions that worked already in place. We needed to architect for maintainability because we knew it was a long hard road ahead, and we weren't going to be quitting soon, so we made a plugin architecture.
The problem we have is when the grasses dis the trees and the trees dis the grasses. The Linux Kernel Community, and the rest of society, have too much of that going on.
Respect those who are nothing like you, and see that they have value to society that you cannot match but might complement.
I would also like to add that many of these tools give you the ability to develop an idea quickly without cornering you into bad decisions. In the worst case you just redo a bad design decision. The average case I have seen is you say crap and then realize that you only need to change 3 lines of code and a filename. This has been my experience with rightcart.com and we've been out for about 30 days and had 3 releases with new features in each. That doesn't indicate perfect code level planning, but the ability to rapidly adjust (the ruby people like to call this being agile). This has given our developers (myself included) a lot of confidence in exploring new ideas and features without the fear of breaking the current system. A common line is that it makes programming fun again. Well, my experience is that a happy programmer is a better programmer.
I'll agree with you that running off and adopting $FRAMEWORK as the Next Big Thing without first understanding the pros/cons/tradeoffs involved is haughty. HOWEVER...
It would appear that you have taken your elementary and incomplete understanding of RoR and created an assumption that RoR is elementary and incomplete.
Not only is does RoR support validation and testing, it practically forces them down your throat. After years of C++, Perl, Java and the like, I've never seen a framework that elevated unit testing to such a prominent level. One of the more famous of the 'demos' that you refer to is the creation of a weblog in 15 minutes. Within those 15 minutes, the author demonstrates the basic unit testing, validation and error handling code that RoR *does for you*. Scaffold, rake and 'validates_*' won't take you everywhere you need to go in order to be robust, but they sure do give you a hefty shove in the right direction.
Still, unit testing and input validation aren't even among the top benefits of RoR specifically, or the RAD scheme in general. The framework and the community that supports it actively guide developers in the direction of numerous other good habits. MVC and DRY are acronyms that every dev has heard and most have ignored, to the peril of their apps' maintainability. RoR encourages these techniques and demonstrates their effectiveness.
To be over-blunt about it, the point of RAD is that no matter how long you plan, you still might as well be going off half-cocked. Requirements tend to be ill-defined and rapidly evolving for most projects. RAD operates from the assumption that reducing the time between requirements collection and release gives you a better aproximation of the real-life requirements *at the time of release*. If you spend twice the time finalizing the spec and twice the time implementing it, you're just giving the requirements a head start - they will outrun you. What unit tests, MVC and DRY all have in common is that they combine to make refactoring as easy as possible, simplifying the development cycle and allowing for releases early and often.
No framework or project management scheme is a substitute for good coders and forethought, but if I had to choose a methodology for today's small-medium sized project, RAD/Agile would be it. You can have your waterfall, your SAP, your XML configuration files and your weeks of Requirements Analysis meetings with PHBs who don't have the perspective to know what they want until you've shown them what can be done.
Sadly, this is the hype about Rails, a feature called "scaffolding" which lets you build a CRUD web-database application by writing a single line of code. This is pretty much the first feature anyone who touches Rails learns about, and sadly, it appears to be the only feature of Rails the author of the question has been exposed to. Scaffolding is, perhaps, the least interesting feature of Rails.
I've been developing a fairly high profile web site in Rails for the past year (ClickCaster.com). In the past I've used a number of different web development languages and frameworks, particularly PHP and JSP. Rails has not only resulted in the fastest development of any framework I've used, but also the tersest code to implement given functionality.
The real advantage of Rails comes from two different aspects: leveraging Agile development techniques, and exposing a highly cohesive, high-level interface for developing database-backed web pages.
The former, particularly the practice of test driven development in which you write tests first and code second ensures you think about what your code is trying to do first and how it should do that second. Pro-actively writing tests ensures that making modifications to your code does not break existing functionality.
The latter, which forces your code into an MVC model where database, mailer, and other underlying components are neatly isolated from the rest of the program logic, and the presentation templates are isolated from code receiving and processing user input, all atop a very high level framework where the majority of development tasks are abstracted ensures you write terse code which is well modularized by function. This has two advantages: it makes code easy to write in the first place, and it makes it easier to maintain. The author of the question seems to imply that Rails satisfies the former condition, but not the latter. This is not the case.
Rails results in less code, and uses test driven development which ensures that your changes do not break existing functionality, and all you need run to ensure this is "rake test". Bottom line: less code is easier to maintain, and tests prevent modifications from breaking existing functionality. Thus any implied criticism against Rails in this article is completely unwarranted and only serves to illustrate the ignorance of the question's author, not any imagined deficiencies in the Rails framework.
These attitudes are perhaps justified in a commercial software environment, but I have seen the same trends in corporate IT departments at previous employers. I have found that the progression runs like this: 1. The IT effort becomes increasingly politicized. 2. Old guard IT managers are replaced by political appointees who have no real IT experience. 3. These new managers lack the experience and insight (and often the maturity) to measure the real level of progress in software development and, because they feel that they must have something to measure, schedule becomes the only measurement. When I began writing software professionally in 1985 (Yes, I am ancient), it was pretty well recognized that a schedule was a tool by which you measured your progress toward a predefined goal. Now days, the schedule is the goal. So because people tend to perform toward there goals, we get schedule. What we don't get is quality, sustainability, customer satisfaction, etc. Also, as an added bonus, we get developer burn-out, high turnover rates, and an us-versus-them mentality between corporate IT and their customers in the business groups that have to use the steaming pile systems produced by these attitudes.
In my experience, people don't know what they want until they see that you have isn't it.
You don't say what your target market is, so what I am going to reply here has a relatively small probability of applying to your situation. But this is slashdot so I don't have to worry about a silly think like relevance, so here we go....
If you had this experience, chances are the person who fell down on the job is not the user, the PM, or the developers, but the software architect for not identifying a fluxional feature. In fact the sole justification for the Agile methodologies is these fluxional features. Many, (but not all), "Agile" projects I have been called in to clean up have made this mistake. In most of these cases, the principal performing the architect role was a true technology wizard, but who would filter everything the business people said to conform to the principal's pre-conceived notions or more subtly falling into the "one true answer" trap.
When a contentious topic comes up in analysis meeting, a technology focused architect often seeks to resolve it and record the resolution, and hard-wire that behavior into the requirements. This is death. As this type of error multiplies, the seeds have been sown for disaster. What should have happened, was a contentious point should be used as an indicator of a volatile feature that should be designed with ease of customization in mind.
Volatile requirements are the norm and the identification of fluxional features is the key to knowing when to address them.
In my market these areas often require extreme flexibility.
1. Screen details, and screen workflow on the UI side. Keep the UI shell stupid using an MVC/MVP paradigm. (.Net 2.0 does a fairly good job with this if you use their binding framework judiciously, .Net 3.0 does a better job, JSP sucked donkey balls in this area, JFC and JSF are better, ROR is pretty good for simpler web sites). Oddly enough navigation is usually pretty stable once the stakeholder meetings have been conducted. Be ready for this.
2. New commands will be added. (Commands in this sense are persistence operations or new features). Work out early how all of those contentious points that came up in your continuous interviews with your stakeholders can be resolved with an appropriate plug in approach. What meta data will be needed for future commands? Be ready for this.
3. Your input formats and medium will change. Be ready for this.
4. Business rules will always change, never allow anything structural in your system be governed by any business rule stated in a stakeholder meeting. Keep them behavioral. Construct/purchase an appropriate rules engine who only knows about business rules. Be ready for this.
5. New persistence mechanisms will be desired. Be ready for this.
Sounds a lot like Agile doesn't it? The only difference is that be ready for this changes to react to this. Putting the effort in it to think about these and other volatile issues up front finds the trolls sooner, which enables refactoring efforts to be more local than they would have been otherwise. This list isn't comprehensive, so remember that outside of mathematics, and mathematical physics, there is almost never a one "One True Answer". My personal rule of thumb if that an issue can't be resolved via a thought experiment it should be made a fluxional point.
Very few people have the intelligence and foresight to extrapolate what a screenshot will mean to them, in the real world.
If you are using screen shots to walk through your scenarios, it is no surprise to me that you have gotten bad results. Paper prototypes will let the stakeholder see the consequences of their actions much easier. But that isn't enough either. You should also make efforts to communicate the state of the system and processes at each point in the screen shot. Designing a good walk through is more of an exercise in psychology than a technical exercise . Wal
Well sure, except it's not as if Ruby on Rails enables that in any way. That's the fundamental basis of both object-oriented and interface-oriented programming, and has been around since the mid 1980s. (If you're really old, you might say "bah, you can do that with function pointers, and it's been common since BCPL.) Those of us who write CGIs in C++ are still amazed that the web is only just now discovering modularization. Granted almost no PHP you see in the real world is written this way; still, that's not a reflection of PHP, but rather the quality of the people writing the code.
You're quite right to observe that careful differentiation of interface and implementation has a major effect on the long term maintainability of a system. However, I openly take issue with the supposition that that has anything whatsoever to do with RoR, and in fact it's my contention that RoR tries to showhorn you into a combined model where, though there is modularization, the modules are frequently not ideally selected. It is my belief that a programmer can do a better job at modularizing than what RoR forces you into.
Try writing a large-scale web application in C++ sometime. Sure, it takes a while to nail down some simple text parsing stuff, but the long term maintainability makes most other languages look positively silly by comparison. Really, these days I just can't imagine doing web work in anything other than C++, PHP or Erlang, and I write code in more than 60 languages. Yes, you have to put down a lot of groundwork to get underway with C++, but it's my belief that in a large application, the benefits more than outweigh the up-front work.
It's remarkable how many bugs disappear with real, strictly compiled languages.
StoneCypher is Full of BS
What advantage does C++ have over, say, Java for programming web applications in?
Well, the comparison was between C++ and RoR. The advantages I was citing are equally well held by Java. The advantages I believe in as regards C++ versus Java are typical holy war nonsense (I dislike Java.) There is a minor but not significant advantage for C++ in terms of the number of available libraries. That said, Java fills out my statements to the grandparent post in the same way that C++ does. Actually, there's a good argument that Java is better suited to the web than C++, because of its deep integration of sockets and things like Tomcat and Beans. I would tend to argue what I just said, but it is a viable argument and is contextually appropriate.
The issue I was citing was compiled languages versus quick-assembly toolkits, on terms that large applications would benefit far more from strict static analysis than they would from a quick grammar and extant boilerplate. In this way, C++, Java, Delphi, C#, ASP.Net and quite a few other languages offer the same set of referred-to advantages.
The other difficulty I have with C++ is that it's not particularly powerful, in terms of syntax and control structures, as some other languages, such as Python or Ruby.
I just don't agree. C++'s syntax is so powerful that many major language features have been implemented directly in native syntax, something I've never seen in any other language except Lisp and Lisp descendants, including aspects, properties, the lambda calculus, closures, compile-time metaprogramming, coroutines, inline lexing, message-based concurrency and so on.
I recommend highly that you familiarize yourself with modern C++ methods. It's quite a bit more powerful language than most people realize. A good book to start with is Modern C++ Design.
When you don't particularly need the efficiency that C++ offers, why favour a more syntaxically restrictive language?
Well, for one I don't believe it's syntactically restricted. However, syntax is a comparatively minor component of a language; more important in this case is the specific advantage I cited, that of very strict static analysis. On these terms, very few languages can compete with C++; it is one of the strictest languages on Earth, when used skillfully.
In my experience, very few bugs disappear.
Er. How many times have you actually replaced a rapid-development web toolkit with a fully statically compiled application? I don't mean to seem rude, but this is experience that almost nobody has in the first place.
However, if you find that this is the case, why use dynamically typed languages such as PHP and Erlang?
Because different tools are appropriate for different jobs. I wouldn't use PHP for a large web application. Erlang is a very special case, and has such a weird benefit/detriment pattern that I don't honestly want to get into it. Suffice it to say that I'd use Erlang where pattern analysis, list comprehensions, or linear scaling across a huge number of users were my primary concerns.
And there are surely languages that have stricter rulesets than C++; Eiffel, for instance, which is compiled, and strongly and statically typed, with design-by-contract built in
Contracts are easily implemented in C/C++, and actually, no, Eiffel is nowhere near as strict as C++ is. Yes, there are a few languages stricter than C++ is, such as Clean, Mozart/OZ and Forth; however, what I was trying to do was to make an example, and given that most people are at least passingly familiar with C++, it just makes a better example.
To be plain, I'm Joseph Conrad. It doesn't matter if my native language is Polish; I'm in America, so I write in English. Sure, there are better examples than C++, but they're too little known (in my opinion) to make good examples.
C++'s weak static
StoneCypher is Full of BS