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?"
Now, how to convince the PHB's and the bean counters?
emt 377 emt 4
The emphasis on fast devlopment is justified, at least from a business perspective, because first to market gives a huge advantage in software, not to mention the network effect. Sure the ability to maintain and upgrade software is somewhat important, but it doesn't matter so much if it takes a long time if you are already dominating the market. Similiarily start-ups don't care about these issues since they plan on being bought out before they matter. Yes these attitudes create serious problems and lead to poorly made software, but what can you do about it? (besides using open source)
Philosophy.
It seems to me that this concentration on initial construction of software ignores the issue of total cost of ownership.
Unfortunately that's how a lot of businesses think and they later regret it if they didn't consider the whole picture before settling on a solution. In lot of cases they just want to have something up and running fast, in some cases, the up-front cost doesn't matter.
The point of rapid development is the proof of concept. Pretty much every rapid development mantra is centered around.
1) Make it work
2) Make it work right
3) Make it fast.
If you want tightly designed and thought out, the extreme programming style might be more your style. (Or the style of a properly run business..)
(And god help me when someone makes a "4) for profit!!!! LOL WTFASLBBQ" joke, go fuck yourself.
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.
that the two concepts must be mutually exclusive. Software can be constructed quickly, and still be "robust" and "maintainable". I will not get into specific development "paradigms" here, but I think that there are options that give us both in varying degrees, on a problem-by-problem basis. Market forces demand flexibility, and those that are, make it.
Managerial Buzzword Count: 3
You have large maintnence costs because no one properly plans up front for the long term. People want to see something and they want to see something fast. No one sits down to write the proper documents, no one sits down to plan ahead, they think for the short term only. Which leads to long term problems down the road. At least, that is what I see as major issues on things i have worked on.
people don't want to make the initial investment to plan ahead, so they end up spending much more in development costs because no one decided where the product should go.
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'?
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
> What do you think?
:)
Spot on. It's funny to watch people do demonstrations of how quickly Ruby on Rails can be used to build something because it's exactly the same sort of thing that was used to promote WebObjects ten years ago and I know from experience what rubbish it is. For all but the most simplistic applications you have to abandon the mapping of form elements to the database because you need to do validation. If you start off with a RAD approach to problems to these pages and add validation as an afterthought they quickly degenerate into a horrible mess. There will be less of a problem in this respect with ruby on rails because the data layer is so primitive so there are some knots you can't even contemplate being tied into, but - um - what was the point of Ruby on Rails again?
I imagine that doing major schema refactors on Ruby on Rails apps would be a nightmare because there's no easy way to check that you've fixed all the breakages. Whereas if you use EOF or Cayenne and get a culture in your software where developers avoid using key-paths except in agreed spots it's quite easy - you make the change, fix the areas where you find compile problems and then its done.
Something I would be interested to see would be some sort of business logic layer that could emulate a JDBC adaptor. Then you could write your application against that and bind to it as though it were a schema, but in the background it would in fact have business logic behind it. This would allow a separation between business logic and presentation but still allow you to quickly bind applications up as you do in the RAD webapp tools.
Believe with me, my saplings.
One reason these tools get a lot of attention is that using them produces a measurable effect. It's the "bookkeeping fallacy": things that are easy to measure must be more important than things that are hard or impossible to measure.
I do think these rapid development tools can add a lot if they are used intelligently, which I think means using them to present concrete ideas and prototypes quickly, in order to gain understanding of the problem domain and to get user feedback. But I still think Fred Brooks's advice in The Mythical Man-Month is correct: plan to build the first version to throw away. You will in any case, and it's better not to deliver the rubbish to the customer.
The curse of IT has always been, "There's never time to do it right, but there's always time to do it over."
Of course it's stupid and short-sighted. We sacked all of the people who wasted time on anything but the immediate requirements.
Lacking <sarcasm> tags,
Most people who develop software also have to maintain it, ...
What???? This may be true with open-source software, but I've yet to see a company that did things this way. The norm is that developers, testers, maintainers and users are four separate groups that are kept as far apart as management can manage.
This does go a long way toward explaining why there's so much crappy software Out There.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Everyone seems to forget that given enough time and resources, *anything is possible in software. Eveyone forgets how _PATHETICLY RETARDED_ business decisions get made (apologies to the mentally challenged who do manage to tie thier shoes). Snide remarks aside, I'm dead serous here. It takes just as much resources, time, and effort to execut a good business idea as it does to do something so fucking stupid it's amazing it was considered in the first palce.
/. masses: Microsoft are a buch of stupid dicks. However, they do one thing (perhaps only one thing) right: they get version 1 out infront of people to figure out what they need to do. Where they go wrong is assuming that 1.2 can be built off the 0.9 beta code base, but that's marketings fault. Given a company with a strong enough technical staff, these things can be corrected. If no strong technical staff exists, then they are doomed anyways and don't know it yet...
Bitch all you want about rapid paths like Ruby On Rails not addressing the long term method, but don't forget the ADD nature of the 6 figure mouth-breathers in the board room. By the time it get's done in a 1/2 assed fashion, you can confirm or deny weather it was worth doing in the first place. Worst case scenario, you have something making money that is hard to deal with. In that case _THROW IT OUT!!!!_ and take into account what you now know for sure about the market/customers/some-sucker-who-will-pay and build the _NEW_ thing that will best make money from them. Too hard you say? Won't work you say? Get some test coverage and push ahead. If you don't, just go home now, because your competition will. Adapt or die. In a global market place, you can't affort to buy "what if" engineering dollars.
Arguments like "We need something that will respond to something we don't know yet" is a variation on big design up front and other various sorts of "slow" waterfall mentality to building software. Yes, I'll admit to being one of those annoying agile assholes, but for 80% of the "business decisions" that get made in the corporate IT (and even startup) world, it holds true: the guys in suits don't know what they are doing. There are numerous reasons why Fredrick P. Brooks said in The Mythical Man Month (now over a quarter century old!) "build one to throw away. You will anyways" was because the nature of business hasn't changed. Anyone selling you some path to something you don't need today needs to be avoided like the plague.
I'll agreee with the
To summarize: this argumet is a load of crap presented by people who want to cling to "proven-to-fail" approaches to building sofware. It's not a bridge, it's not a car, it's ones and zeroes that may or may not see the light of day. The same optimization axion aobut "never prematurely optimize" applies even better to "never assume you have it right". As soon as people drop they fronts of how much they think they know about building products, the better off we all will be. Try, learn, and adapt. Again, if you don't your competition will...
Footnote: * within reason. You're not going to create a miracle, but you know what I mean here...
*** Sigs are a stupid waste of bandwidth.
I think the problem isn't that there is too MUCH focus on the beginning of the software lifecycle. The problem is that there is too LITTLE focus on the beginning of the software lifecycle.
The beginning of the software lifecycle is supposed to consist of analysis and design - both of which can lead to the construction of a superior product if done right. The issue is that many of these "quick start" languages and frameworks make is easy for a programmer to dive right into the coding phase without considering the overall design of the system. Thus, they skip the beginning steps in the software lifecycle.
------
www.moneybythenumbers.com
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.
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!
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?
As someone who started his professional development life maintaining other people's code, I completely agree.
But I must take issue with the title of this thread. The problem isn't too much focus on the beginning of the software lifecycle. Coding is in the middle, not the beginning. A good design comes first, and a good analysis of the problem domain before that. Modern methodologies ignore design, or pretend to do during coding. A quick and dirty hack may come back to bite the heel of a future maintainer, but a hurried design is sure to smother him to death. Way too much emphasis is made on coding, but that's only 10% to 20% of the lifecycle (not counting maintenance).
We're not developing faster, we're just shipping more prototypes.
Don't blame me, I didn't vote for either of them!
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.
Where is it? When I have written software in the past, I've seen rapid development and maintainability go hand in hand.
If you want to finish a software project quickly, your code must be written with a certain level of foresight. You can't just hammer things together, but you must also put in some design effort to make sure that the structure accommodates the functionality you're shooting for. When you do this, your software will be developed faster than any other method because software lends itself to its purpose--your project runs the risk of dying before its finished if you don't. Your software will also have its own intrinsic flexibility toward its application. That means that a clean, solid application will come together more rapidly (and is coincidentally easier to maintain).
We have two major systems at the company I work for. One, that the related staff spent 2 years documenting their business practices and exactly what they wanted the application to do. They took that huge document to a couple of consulting companies and said "we want this." 2 years later the consulting company that won the bid turned over a nearly perfect application.
Wow. Sounds like a ringing endorsement for planning and quality execution.
Unfortunately, though I've tried time and time again, I've never gotten anywhere near the participation required to lay out everything in advance accurately. Worse, the few times I've actually managed to get something together and gotten everybody to sign (in blood) in triplicate, it was rejected on the very first day of rollout because they didn't expect something that was, upon rollout, patently obvious. In my experience, people don't know what they want until they see that you have isn't it. Very few people have the intelligence and foresight to extrapolate what a screenshot will mean to them, in the real world.
So, I've turned my back on the whole idea, and have instead adopted a modified "agile development" approach.
I do just enough specifications to determine how all the pieces are going to fit together, what all the database fields are, and how the constraints, triggers, and foreign keys assure reasonably sound data. I beat the idea in front of a few people and search for objections, until most people approached seem to like the idea, and nobody has any major bones to pick.
Then we code - it goes out the door for public release as soon as it seems stable and workable. I don't bother trying to make it totally bug free, so QA is short and sweet. On rollout, I ask our clients to review it and inform us of any bugs. We never get it right the first time, and we're pretty up front about that. But we fix it quickly, and most importantly, we modify our software towards what the customer actually needs. Stuff that is simply not needed gets dropped pretty fast.
Our software is designed to "fail early" - so that inconsistent or inaccurate data doesn't hurt anything. And so far, we've had only minor issues in over 2 years of heavy, active, exponential growth and development.
Turnaround time for an average modification is less than a week. We issued over 40 releases in the last year alone. Every so often I go over everything in a new perspective, and do a bunch of minor tweaks all at once - that's when UI improvements come down hot and heavy.
The response has been wonderful! A customer who mentions an idea, and sees it implemented a few weeks later is your evangelist for life. You practically become their religeon, and you'll get recommendations and referrals for the rest of your days.
I've heard people talk about it like bargain hunting - they hunt around - just to see what's new!
So far removed from the bleak hopelessness so common here at Slashdot about software projects - it's exciting, intense, fun, and profitable!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
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.
From the freelancer's perspective, there is nothing I love better than a mess of spaghetti code hacked together by interns on crack and then rushed out the door by a PHB.
Where I might normally charge $250 for a few hours of patching, these desperate fools will happily pay 10x that so long as it "works by Monday morning". Of course, that's pretty easy to deliver, especially considering the PHB will almost always elect to avoid all the *real* problems (read: time-consuming). The result? Repeat business!
I used to feel kinda crooked about this (honest). But, in all fairness, a man can only give the same "TCO is relevant!" power point presentation so many times before he just gives up and takes the money.
barack to the future?
Ruby on Rails is not designed for the software engineer. It's designed for the Glue Master who wants/needs an application developed as quickly as possible with as much power as possible. The applications are "quick and dirty" one-offs that will be "refined" by being rewritten. Perfect for Web-UI's that need to be constantly scrapped and rewritten. Typical programming team consists of a single ADD user (not usually a "learned" programmer).
PHP/Python/VB is not designed for the software engineer. It's designed for the programmer who wants/needs an application that is maintainable and will last longer than a RonR app - but is is not going to last indefinately. The applications will have a history and may be revisited and refined for several years. Perfect for heavily used Web Apps that have a short-multi-year lifespans. Typical programming team consists of 1-4 programmers optionally with some support staff and/or managment.
Java/C/C++ is designed for the software engineer and programmer who wants/needs a robust powerful application that will have 5's and 10's of years lifespan - Perfect for building something like a PHP/Ruby on Rails/Web script engine, Apache Web Server, Linux OS, etc. Typical programming team consists of multiple groups of 6 programmers/engineers and staff (managment, testing units) to support them.
It doesn't make sense to over-engineer applications that process simple web-forms. Nor does it make sense to hack together a web-content-management-system. You use the tools, the effort, and the language that makes sense for the application at hand.
-CF
For some of these systems getting it operational quickly may be important, but for all of them maintenance is longer term going to be far more critical. I've more than once built something quick and dirty because we needed something "yesterday", but inevitably a quickly built system will need to be replaced or rewritten to serve long term needs without driving maintenance costs through the roof. Often, planning for a early rewrite is ok - it gets you something up and running quickly and may buy you time AND experience with the actual user needs. But ultimately engineering for maintainability will be needed if your app is going to have a decent lifespan, and engineering for maintainability does take a lot more time than most people think it will.
Service Oriented Architecture
(SOA)
--- -- - -
Give me LIBERTY, or give me a check.
The reason you want to be able to build a working system quickly is so that you can throw out the first one. You see, there is no substitute for learning how to do something than to actually do it. Trouble is that, if you invest a lot in the first one with an eye to reducing maintenance costs, you won't be willing to throw it out even though the entire structure of the program is fucked. A program is founded on a certain set of assumptions. If your assumptions are wrong, then the foundation of your program is wrong. Your program can never be fixed. It must be thrown out, and a new program with correct assumptions must be written.
The second system will also be fucked, because you are a sophomore. It, too, must be thrown out. Only until you get to version 3.0 will you actually have a working system which should and will last for the lifetime of the product. THEN you worry about maintenance.
Don't piss off The Angry Economist