Forgot your password?
typodupeerror

Too Much Focus on the Beginning of Software Lifecycle? 295

Posted by Cliff
from the software-development-doesn't-end-at-release-time dept.
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?"
This discussion has been archived. No new comments can be posted.

Too Much Focus on the Beginning of Software Lifecycle?

Comments Filter:
  • Good point (Score:5, Insightful)

    by Duhavid (677874) on Friday July 14, 2006 @11:27PM (#15723219)
    Now, how to convince the PHB's and the bean counters?
    • Re:Good point (Score:5, Informative)

      by Spectra72 (13146) on Friday July 14, 2006 @11:50PM (#15723301)
      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).
      • Re:Good point (Score:3, Insightful)

        by Duhavid (677874)
        I've known more than a few programmers like that,
        unfortunately. I dont consider them the ideal,
        just the ones that management hires because they
        dont know what to value. The better programmers
        of my acquaintance know the value in the existing
        code, and are not hot to continually reinvent
        the wheel.
    • Re:Good point (Score:3, Interesting)

      by try_anything (880404)
      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 ex
      • That's funny, I *just* happen to have a framework
        using a language with built in time wasting.
        Lots of it, more even than the fabled internet.
        ( Hard to believe, I know, but stick with it ).

        The cost is fairly minimal, and there is a methodology
        that I have worked out with it.

        My consulting team can get yours trained up and
        ready in a very short time (tm).
    • Re:Good point (Score:3, Insightful)

      by TapeCutter (624760)
      Just nitpicking the point, but the begining of the SDLC is requirements gathering not development. If you nail the requirements acuurately (eg: write the user manual first and make sure the PHB's agree in writing) your maintenance and testing battles will be half over before you write any code.

      In other words: If both the sponsoring PHB's and the developers fail to communicate to others "what the software is supposed to do" every user/tester complaint becomes a bug and the software rapidly deteriorates in
  • Justified (Score:5, Insightful)

    by Umbral Blot (737704) on Friday July 14, 2006 @11:29PM (#15723224) Homepage
    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 [wikipedia.org]. 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)
    • "first to market gives a huge advantage in software"

      This is correct only for software that is an incremental improvement over existing software; a few new wiz-bang features are added. Other companies are feverishly trying to add those same features and first-to-market may make a significant difference to the bottom line. Code maintenance is of no concern to the runners-up who have no sales.

      However, if the software in question has something new to offer, something not obvious to competitors, then there is no
    • Re:Justified (Score:5, Insightful)

      by humblecoder (472099) on Saturday July 15, 2006 @12:33AM (#15723456) Homepage
      Actually, being first to market really isn't that big of a deal. There are tons of products which were first to market which have slided away into oblivion because they were rushed out the door. Because they were rushed, they ended up sucking the big one. Then, another company comes out with a better, more polished version of the same product and everyone forgets about the first, sucky product.

      The dotcom bust is littered with companies whose business model was, "be first or else", and nobody seems to remember them.
      • Probably absolutely correct but you'll NEVER convince a sales droid or marketing weenie of this. Further, all they have to do is say, "Lost sale becuase we didn't have feature Y and brand X does," and management will be in a tizzy. The fact that the potential customer just wanted to get the sales droid out of their office so they could get some real work done never seem to occur to anyone except the poor SOB who gets to spend nights and weekend coding feature Y.

        Cheers,
        Dave
    • Re:Justified (Score:5, Interesting)

      by msezell (862831) * on Saturday July 15, 2006 @01:01AM (#15723537)
      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.
      • Re:Justified (Score:3, Interesting)

        by stonecypher (118140)
        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
    • Re:Justified (Score:2, Interesting)

      by rgarvage (724842)
      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 a
    • Re:Justified (Score:3, Interesting)

      by jbertling1960 (982188)
      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
      • Re:Justified (Score:3, Insightful)

        by stonecypher (118140)
        The saddest thing about this is how correct you are, and how it hinders you. If you and another team developed Product X, and both went 33% over schedule, the other team would hit early milestones, declare progressive success, change the schedule to fit the new needs, allow bloat, hammer in new features to justify the lag, and end up coming in 200% over budget. You would come in 33% over budget, but since you didn't dance around acting like the schedule was the only important thing, your lean and nearly o
  • by Anonymous Coward
    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.
  • by Beuno (740018)
    I think that as long as there is a bigger influence of non-tech executives and marketing departments, this is going to keep on going.
    It's very hard to understand the long term benefits if you don't have some technical skill and have made that mistake a few times.
    There should be a balance that clearly isn't there most of the time.
  • Different Strokes (Score:2, Insightful)

    by Anonymous Coward
    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.
    • Actually, extreme programming does follow the "make it work, and produce it fast" mentality. I really enjoyed reading about the test-driven methodology because it makes so much sense to me. Having a fully functionaly, albeit without all functionality in place is really a plus when it comes to making the customer happy. It also shows upper management that you are actually accomplishing something, and also produces more maintainable code in the end.

      (And god help me when someone makes a "4) for profit!!!
  • by moochfish (822730) on Friday July 14, 2006 @11:34PM (#15723241)
    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.
    • In other words: The implicit assumption in the original question is incorrect: These frameworks are *not* concentrated merely on getting apps running quickly.

      Of course the infamous manner of showing off these frameworks is to make a screencast showing how easy it is to make a simple wiki or todo list. These screencasts can be misleading since they often employ simple CRUD scaffolding, which is useless in the real world. However, taken with a grain of salt, they help you get a feel for the framework.

      A go
    • by Anonymous Coward on Saturday July 15, 2006 @12:20AM (#15723410)
      As Douglass Adams said: the problem with things that can't possibly go wrong is that when they do go wrong, there's no way to fix them. When you accept the "easy" models promoted by some of the higher level languages, you might take the framework your using as far as it goes and realize that it doesn't go far enough. At that point you're stuck. For example, you may have written a powerhouse GUI application for a platform like .NET or Java and now that you've invested millions in development, you realize that there's nothing more you can do to optimize performance on that platform: your application is a memory hog and takes forever to load. It's still a good application, but your choice of development tools has put a hard limit on how far you can go. That's a tough spot to be in.
    • by skiflyer (716312) on Saturday July 15, 2006 @01:14AM (#15723566)
      At least that's why I assumed rapid developement frameworks caught on.

      There's also the fact that in many jobs a huge percentage of programs are run once, or maybe run once a day for a month... and maintainability isn't an issue. My previous employment was just that, lots of tasks that needed to be scripted, and then they were done. Occasionally a program become popular and had to be scaled up to repeated use, and then we did just that. But the rapid development was great for the ones that didn't, sometimes the code for them was garbage, but worked, and sometimes it was really well organized and easy to transform... but more importantly the tasks where completed in less total hours (programming + running) than if a human had to process the issues by hand.

      Now, as someone who's a boss and cares alot about the dollars per hour, one of my constant frustrations is watching someone write a script for a run once application that takes 3 hours to write and debug, 5 seconds to run... while I'm paying them $30/hr, whereas they (or a better yet a $7.50/hr employee) could've done it by hand in 30 minutes.
      • We don't have run-once applications. Instead, we have run-in-reaction-to-problem scripts. Spending 3 hours to write and debug an app means that the next time you need to run the thing once, it'll take 5 seconds and be done right.
      • I agree with your point, sometimes real-scissors and real glue are better than a word processor... but a it does not have to be all bad... mitigating factor would be that if people like coding, and they keep their practice up by implementing scripts in three hours, that could easily be saving you training hours, keeping their skills up for when they really need it, and improving coder morale... You might be just distributing training costs throughout your budget, and not having to shell out for it up-front
      • You're ignoring opportunity costs; sure there's a higher cost ($90) for your scripted solution; however, in those three hours, maybe that $7.50/hour employee is occupied with other, more profitable tasks that he wouldn't have been able to complete if he was pulled away for 30 minutes of data entry. Maybe data integrity is critical and the cost of the scripted solution vs. the risk of a $7.50/hr employee mis-entering the data made the scripted solution much less.

        Nathan
  • I am not so sure (Score:2, Insightful)

    by raymondmroz (574950)
    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
  • No. (Score:5, Insightful)

    by hsmith (818216) on Friday July 14, 2006 @11:40PM (#15723263)
    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.
    • Re:No. (Score:5, Insightful)

      by RingDev (879105) on Friday July 14, 2006 @11:57PM (#15723325) Homepage Journal
      Here! Here!

      The problem isn't high level languages or agile development. The problem is a lack of foresight, planning, and documentation.

      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.

      The other app is an extension of a 3rd party application. This app started development with little to no documentation, no project manager, and no one who had actually worked with the 3rd party application. Flying blind into a short deadline has left us playing redevelopment games for almost 2 years! We finally managed to get the critical personnel together to get the system and processes documented, and after 3 months of business process documentation we should be set to re-write the business layer of the application in 6 months.

      Had the user group worked with the 3rd party app prior to launch, and documented their processes, the entire application could have been developed in under 9 months. But with out that work on the front side we will have over two and a half years wrapped up in development from 3 people.

      One more project like this, and I'm moving to management. As much as I love coding, I hate inept managers even more.

      -Rick
      • Re:No. (Score:5, Insightful)

        by Kadin2048 (468275) <slashdot.kadinNO@SPAMxoxy.net> on Saturday July 15, 2006 @12:47AM (#15723490) Homepage Journal
        That's a great anecdote, and I don't think that you can hit that point hard enough.

        If somebody came to you and said "hey, I've got this great new way to build a bridge! Instead of making up plans, we'll just start building it! We'll build it out of popsicle sticks first, and then we'll go in and add some steel beams, and toss some pavement on top of that," you'd say they were insane. Nobody does stuff like that in the real world -- yet that's exactly what a lot of poorly-managed 'agile' software projects are doing. They're getting short-term prototyping gains but at the cost of maintainability and probably stability as well.

        Rather than figuring anything out ahead of time -- actually answering the hard questions like "what do we want this software to do and how do we want to do it?" they just start making something. It's like just giving some steelworkers a pile of rebar on either side of the river and telling them to build towards the center and figure the details out later.

        I think one of the biggest problems in software development, and it's really endemic, is an underappreciation of the pre-development work: requirements analysis, specification development, even simple stuff like the clear division of job roles and responsibilities. If you get that stuff done, the actual coding ought to be an academic exercise, not a seat-of-the-pants experiment.

        Part of the problem lies with managers who don't understand software, and just take any opportunity to compress schedules and make themselves look better, and another problem is with "programmer culture," where people think the ideal way to solve a complicated problem is just to put a half-dozen developers in a room for a weekend with a few gallons of Mountain Dew, an Amex card, and the number of the nearest Domino's Pizza. (Although to be fair, this attitude seems to be less common among developers who have SOs/families, or are used to 40-hour workweeks.)

        While concentrating on "getting it out the door" may solve the problem in the short run, it's almost certainly not going to give you neat, easily-maintainable, well-documented code. And when you're looking at the long-term maintainance costs, it sometimes can be better to not have anything at all, than to have a lot of spaghetti code that somebody is just going to have to rewrite down the road, when they can't figure it all out.
        • Re:No. (Score:5, Insightful)

          by mcrbids (148650) on Saturday July 15, 2006 @03:51AM (#15723896) Journal

          If somebody came to you and said "hey, I've got this great new way to build a bridge! Instead of making up plans, we'll just start building it! We'll build it out of popsicle sticks first, and then we'll go in and add some steel beams, and toss some pavement on top of that," you'd say they were insane. Nobody does stuff like that in the real world -- yet that's exactly what a lot of poorly-managed 'agile' software projects are doing. They're getting short-term prototyping gains but at the cost of maintainability and probably stability as well.


          A complex software project doesn't compare well to a bridge. It's more like a city. Nobody goes and says "Let's build a city!", lays out plans, prototypes and discusses what business go where.

          That's just stupid; nobody does a city like that.

          A bridge is a simple item, an artifact of intelligence, it's an item with almsot irreducible complexity. A city, however, is a highly complex, interactive social organism with bazillions of interactions, many of which you can't easily forsee. It has a very small level of irreducible complexity. Lots of software has much in common with this.

          Cities ARE built in a "agile development" fashion. People spec out just enough to get started, to get them by for the next few months/years, slam together a some houses, and maybe a store or two. People like living there, then somebody comes along and thinks "We outta have.... a Newspaper!" and they build a building and buy paper and start writing articles and printing and all that jazz. It's a little different than software because most software has a lifespan of perhaps 10-20 years, cities have lifespans in the hundreds of years.

          Changes in this city are incremental; they're small. They happen everyday. Somebody does an extension on their house. The lady down the street gives birth to a son. The corner grocery starts selling sandwiches. The empty lot down the street becomes a movie theatre. And so, the agile development model continues.

          You're dead wrong - the bridge is a small, incremental example of EXACTLY how well-done agile software develops!
          • Re:No. (Score:3, Insightful)

            by stonecypher (118140)
            That's just stupid; nobody does a city like that.

            Philadelphia, New Beijing, Taiwan, Seoul, Londinium, Carthos, Constantinople, Phoenix, Chicago, Tampa, Rio De Janeiro, Tokyo/Kyoto, Sydney, Jakarta and Dubai were all carefully planned. All have scaled to the modern world very well, with the exception of dealing with automobiles, something you can't really fault the ancients for not seeing coming. Essentially the entire Roman empire had very careful city planning, and in fact they did well enough that eve
      • by mcrbids (148650) on Saturday July 15, 2006 @03:31AM (#15723863) Journal
        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!
        • by nightowl03d (882197) on Saturday July 15, 2006 @01:17PM (#15724990)

          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

    • 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.

      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

  • by aussersterne (212916) on Friday July 14, 2006 @11:40PM (#15723266) Homepage
    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.
    • by wtansill (576643) on Saturday July 15, 2006 @12:07AM (#15723360)
      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.
      Ehhhhh -- no. Maybe some trivial applicationm can be thrown away and reengineered every few years, but business generally does not have that luxury. There are data conversions to consider, as well as the fact that, depending on the system in question, an entire "ecosystem" has likely grown up around the core application. You cannot just throw the application away without ripping out and reworking all those other systems that depend on it in some form or fashion. Yes, I know -- Software as a Service to the rescue -- well defined interfaces between applications, etc. Except that in the main, that does not happen, so you are better off having an extensible, maintainable system. Now if I could only sell that idea to the PHB...
    • by GigsVT (208848) on Saturday July 15, 2006 @12:14AM (#15723389) Journal
      Terrible idea. Happens a lot though. Not created here syndrome doesn't help.

      My personal policy is that unless the requirements change radically, or you are facing serious obselence, you should never start over from scratch.

      Even if you wind up rewriting 95% of the code, you'll prevent yourself from making the same mistakes that the original developer already sorted out.

      It goes something like this:

      You find a chunk code that looks entirely unnecessary.
      You take it out, replacing it with the obvious solution.
      You run your testing stuff, it's easy since you were starting from a working system, it's all regression testing.
      You often find that the code actually did do something important, something subtle usually.
      You rewrite it in a better way, that accomplishes the same thing.

      The alternative, starting from scratch, means that you will likely miss the subtle need for that particular thing. You don't have the benefit from starting from something that works.

      It seems like it would take longer, but it goes a long way to prevent requirements and their subtle implications from falling through the cracks. You basically have a cryptic book telling you all the little tricky things. If you throw that book away then you have to rediscover them yourself. And even if you keep it, you aren't going to seriously read it in a deep way if you are starting over completely. By the time you understand all the old code fully you could have been rewriting it incrementally.
    • . . .it's cheaper to just start from scratch every couple of years.

      But just think of all those lines of code being dumped into our landfills. Sure, it's easy enough to ignore it now, but ultimately we leave the problem to be dealt with by our children.

      Everybody! A-one and a-two and a-three . . .

      Won't someone please think of. . .

      KFG
      • Some day, we're going to run out of room in the virtual landfills. If we don't start recycling code NOW, our children or our children's children will never know the vast sweeping cyberspaces of the internet.

        Something like that? The visual I get is of a guy in a pirate suit with a tear running down his cheek. =)
    • The attitude you get when you hire children. Well designed apps are maintainable and last for much longer than the transient early career coders can believe. I have written application components that ran unchanged for more than a decade without any modification. Careful thought, proper design with comprehensive error detection and incremental testing during construction can produce an efficient proper solution that will stand the test of time. Enterprise applications often have lives of a decade or more. B
    • by Anonymous Coward
      > software labor costs go through the floor due to offshoring.

      Nice urban legend. Maybe you should talk to someone who has actually done this type of thing. By the time you pay for the extra cost to send-out the RFP's and negotiate a contract (from what I've seen it's typically 1% or more of the total cost of the system when dealing with Indian contractors), the extra management required to oversee the project, travel to/from the contractor (as an example, my last airfare to Ahmedabad, India was $4,784.
  • If Ruby On Rails drives down development time, do it!

    If Cruise Control (and continuous integration) drives down development and maintenance time, do it!

    If it you've got some tool or process laying around to help drive ~any~ part of the software product lifecycle, it will be adopted and used, just like Ruby on Rails has.

  • Software frameworks are not a replacement for software management and development methods. Do you blame the C# libraries for poor software written in it? Do you blame the STL for un-maintanable code? Tools are tools, they should work as efficiently as possible. The person using the tools is responsible for what they do with them.
    • Do you blame the C# libraries for poor software written in it?

      Dijkstra would. Here are a few of his choice quotes:

      PL/I --"the fatal disease"-- belongs more to the problem set than to the solution set.
      The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.
      Projects promoting programming in "natural language" are intrinsically doomed to fail.

      Dijkstra is not the only one. Others, such as Alan Kay, have been promoting their vision of how programming sh
    • oh, here is a quote that illustrates my point perfectly:

      The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities.

      This is why the language matters. It is a tool, but a tool can limit us in a million different ways.
  • by TrappedByMyself (861094) on Friday July 14, 2006 @11:42PM (#15723273)
    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.
    • And what you don't understand is that the "Rapid Development" (or proto typing, as we used to call it years ago), only works well when your developers can plan ahead.

      Otherwise, the rapid development pushes MORE work down on your tech support staff, like your DBAs, who now do 3 and 4 times the work to add columns one at a time, instead of all at once.

      The company I am currently at is doing this now, and as a DBA, I haveto put up with the crap from the increased workload, so bottom line, it is a net LOSS for t
      • And what you don't understand is that the "Rapid Development" (or proto typing, as we used to call it years ago), only works well when your developers can plan ahead.

        If people don't commit to the system, then of course it won't work.
        If I tell you that a screwdriver is for screws, you can't call me wrong just because you're using it to pound nails.
    • Not that you dont have a good point, but I have seen
      many cases where the developers want to converse with
      the subject matter experts, but they and the management
      above the SME's will not commit the time needed to do
      this. So, the quick, wrong ( in part anyway ) answer
      is given, the system is wrong, and development is
      blamed.

      And continuous deliverables and agile development can
      be a good solution, but only if the users will put in
      the time to evaluate the incremental drops. And that,
      often enough, depends on the m
      • All the more reason to get to a "dog food" release as soon as possible, so users can actually start using the application instead of just playing with it. Of course, it's hard to convince people to switch until the new system is better than the old one, but that's the point at which truly valuable feedback is inevitable. Until it's being used for real, you're likely to get only cursory feedback from most users.
        • The problem is, you're still shipping a pre-pre-pre-alpha prototype. Then charging the customer for a pre-pre-beta 2.0 version. Then charging them again for an incredibly buggy 3.0 release candidate. And so on.

          Cyclic software lifecycles have been around for a couple of decades, but only recently have we given them cool names and used them as an excuse to release unfinished (and untested) software. The problem with modern software development is that we've lost all sense of pride and craftsmanship.
          • The problem is, you're still shipping a pre-pre-pre-alpha prototype. Then charging the customer for a pre-pre-beta 2.0 version. Then charging them again for an incredibly buggy 3.0 release candidate. And so on.

            Wrong. Your pre-pre-pre-alpha prototype is supposed to be a tested and solid project. Instead of cramming half implemented features in and having a constantly broken system, you implement a few features well. The customer doesn't need to see a prototype of everything in the first go around.

            The big
  • There's too much focus on the price and features of new razors, and not enough attention paid to the cost of razor blades.

    Welcome to life, people. We humans like instant gratification, and if something is easy now, we don't pay a whole lot of attention to what the long term implications are. Same goes for companies.

    I'm not belittling the original OP; I think it's a valid point and one that should be paid attention to. I'm just trying to explain why it is not a surprising state of affairs at all.

    -b
  • by TheSpoom (715771) * <[ten.00mrebu] [ta] [todhsals]> on Friday July 14, 2006 @11:45PM (#15723283) Homepage Journal
    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 [cakephp.org], 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.
  • I agree (Score:5, Insightful)

    by The OPTiCIAN (8190) on Friday July 14, 2006 @11:48PM (#15723296)
    > 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.
    • Re:I agree (Score:4, Insightful)

      by Duhavid (677874) on Saturday July 15, 2006 @12:26AM (#15723435)
      It's funny to watch people do demonstrations of how quickly Ruby on Rails can be used to build something


      And it is also funny to have to take that demonstration code and turn
      it into a production ready system. Time is never sufficient, because
      management can only see the (poorly) implemented features, and not
      the lack of error handling and return value checking, and robustness.
    • I think you're missing the point.

      Most of the sites being developed with these tools and deveopment practices have a short lifespan, and the ones that don't have zero code re-use between versions because they have to be on the bleeding edge to be relevant, and their old site is, well, yesterday.

      If you're developing long term application solutions, you shouldn't be focusing on speed of development alone. That's not to say you can't use RAD tools like Ruby on Rails, though... There's nothing in these framework
    • 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.

      Are you familiar with the MVC paradigm at all? Rails uses this, and enables logical separation of the three major components: Model, View, and Controller. I'm going to assume that if you care at all, that you'll do more of your own research; either that or you already know what MVC is but were unaware that rails used it. My point is that most of the code you se

    • Re:I agree (Score:3, Interesting)

      by PintoPiman (648009)
      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 te
  • I think developing a new project is the fun part. So people focus on how to maximize the enjoyment of doing the activity they like, rather than minimizing the drudgery of the activity they don't. We'd all be better off if more maintenance lessons learned made their way into the software design phase. But people are creatures of habit. They figure if they just push their pet method harder on the next project, it won't be a disaster like it was on the last project. Learning from reality never enters into
  • by richg74 (650636) on Friday July 14, 2006 @11:56PM (#15723322) Homepage
    I think I might argue that the beginning of the development processs -- or, at least, what should be the beginning, namely the design, often gets too little attention. My experience leads me to believe that most gnarly maintenance problems stem from poor design more than from low-level coding blunders. Think of the well-publicized security issues that have bedeviled Microsoft. I don't think they occur because Microsoft has bad programmers, but I do think that the "tightly coupled" design of Windows is a mistake, and makes problems much more difficult to resolve.

    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."

    • 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.

      I'd take it further than that. My experience over the last 10 years of development work has been that for any medium-large project (the smallest I've worked on that this has applied to was an e-commerce system that has about 9,000 lines of code, the largest was a GUI framework that has about 40,000) was t
  • by overshoot (39700) on Friday July 14, 2006 @11:56PM (#15723324)
    I think you're going to have a bitch of a time selling that idea to management. They live and die by quarterly goals, and their goal is to get this turkey out the door this quarter. Maintenance is someone else's problem, assuming we make it that far.

    Of course it's stupid and short-sighted. We sacked all of the people who wasted time on anything but the immediate requirements.

  • If this was about an application that was going to stick around for quite some time or will be used by millions, then it makes sense to take time and get it done right (witness vista and current office; possibly the first time in MS history where it MIGHT get it right). But in a small company, or a small product, it makes sense to go with Ruby, PHP, perl , etc. Roughly anything that will allow for a fast development, secure, and ok to decent run time. After all, the vast majority of start-ups/ products fai
  • by jc42 (318812) on Saturday July 15, 2006 @12:00AM (#15723339) Homepage Journal
    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.

    • Agreed. In my 8 years as a software engineer, I don't think I've ever been responsible for any amount of serious maintenance. I build projects; someone else takes care of them. But I make the decisions on frameworks, tools, etc to use - "management" wouldn't have enough of a background to make an informed decision (and usually they know it). But I plan on making MY life easier and on meeting MY goals and responsibilities. I'm not measured on TCO, I'm measured on producing a product quickly that meets a
  • by bADlOGIN (133391) on Saturday July 15, 2006 @12:01AM (#15723343) Homepage
    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.

    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 /. 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...

    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...
  • I work in support for a tech company that sells large software packages to Fortune 500 companies. The director of Support made a presentation on software maintainability to the Engineering department in which he displayed a spreadsheet showing that the fact that our binaries can't report their hotfix level (our customers always end up running hotfixed binaries) adds an average of 5 minutes to every support case while we determine the hotfix level, with a cost to end users at around $100,000 a year in lost
  • It's not the language or the tools that lead to maintainable code. It is entirely the quality of the people who architect and implement it in the first place. An experienced, well educated developer will always write with the future in mind, with commenting and clear abstractions. In converse, no language can prevent sloppy coding - and sloppy coding is the only cause of unmaintainable applications. Full stop.

    What language and toolset benchmarks do is show how easy it is to express ideas, which is a pre
    • Hear, hear!

      I have seen bad programs written in almost every language. And good programs written in some of the badly-slammed languages. It's the skill of the programmer that determines how good the application is. Badly designed (programming) languages can make it harder to do good work, but really good people can still do at least decent work in limited capability systems. And going further than that, well-designed problem definition systems can give even low-skilled people the chance to do considerab

  • 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: Spen
    • 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 desk
  • You may be right about the TOC and maintenance. RoR really does make creation of CRUD apps simple and fast. However, it's hard to tell what the TOC and maintenance of RoR is like yet, as RoR only recently started getting heavy use outside the country of its origin, Japan. It's too early, I think. In other words, we have to wait for a few years to pass, let some people build non-toy RoR apps, and then look back and try to judge what maintenance was like.
    A pile of new Web 2.0 companies are using RoR to ge
  • by humblecoder (472099) on Saturday July 15, 2006 @12:38AM (#15723472) Homepage
    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.
  • by Trailer Trash (60756) on Saturday July 15, 2006 @12:57AM (#15723521) Homepage
    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.
  • Right or right now? (Score:2, Informative)

    by bunhed (208100)
    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
  • Eiffel (Score:2, Interesting)

    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!
  • by Brandybuck (704397) on Saturday July 15, 2006 @01:56AM (#15723670) Homepage Journal
    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.
  • by SmallFurryCreature (593017) on Saturday July 15, 2006 @02:04AM (#15723691) Journal
    Software in development is loosing money. Software in maintenance is making money. If you have ever worked in other fields especially warehouses or production and have an eye for effeciency you will often spot things that if optomized could easily make cost drops and productivty go up. But only if production is stopped for a week to put in place the optimizations. Wich is too expensive.

    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.

    • 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?

      Because the FIA rules mandate that for the racing seasons 2005 and beyond engines must be used for a minimum of two (2) race weekends before they can be rebuilt, that's why.

  • by hansreiser (6963) on Saturday July 15, 2006 @02:10AM (#15723707) Homepage
    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.
  • Leaving aside some of the specifics mentioned (which were misguided) the basic question is a good one, for which there is no clearcut answer.

    Some arguments for concentrating on a quick, inexpensive initial implementation:

    • the application cannot help the business make and/or save money until it is running; a two month delay in initial implementation may cost a fortune;
    • even applications you expect to use for a long time often do not work out that way; further, the longer you take giving the user a solutio
  • Yes. We should definitely do that. It would be the best thing for--Oooh! Look! Shiny Things!

    By the time your maintanable app is on the market, the Shiny Things have beat you.

  • The difference... (Score:3, Insightful)

    by vga_init (589198) on Saturday July 15, 2006 @02:50AM (#15723789) Journal

    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).

  • I think that if you don't get the project out the door ASAP, then there will be no money coming in to pay for all those expensive maintenance programmers. Besides which, unless someone is actually using the project, how are you going to know what to maintain?

    Now, there is certainly justification for the maintenance team refusing to accept code until it meets certain criteria, but there is no need for those criteria to get in the way of customer release. They are two seperate issues.
  • That thought is terribly flawed, at least from a small business' perspective. Rapid software development is key. For one main reason. Before you have a product it makes you $0. After you launch it (assuming you do a good job) it makes revenue and can pay for its maintenance. Its now making you money instead of costing you money. It may not matter to MS, but to small business it means the world.
    It's simple logic really, and you'll find it's how most small-medium software companies look at it.
    • Re:flawed. (Score:3, Insightful)

      by vidarh (309115)
      True in some sense, but keep in mind that most software development is not done by software houses, but in house by companies that will use it.

      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 main

  • by Zaphod2016 (971897) on Saturday July 15, 2006 @07:47AM (#15724208) Homepage
    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.
  • 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 des
  • Three words (Score:3, Insightful)

    by KarmaBlackballed (222917) on Saturday July 15, 2006 @08:34AM (#15724270) Homepage Journal
    Service Oriented Architecture

    (SOA)
  • burn the first one (Score:3, Insightful)

    by Russ Nelson (33911) <slashdot@russnelson.com> on Saturday July 15, 2006 @10:00AM (#15724417) Homepage
    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.

panic: kernel trap (ignored)

Working...