General discussion

  • Creator
    Topic
  • #2292989

    Software is never finished…really?

    Locked

    by collins_rf ·

    I have an interesting thread to toss out there among you. Is software development really ever finished? I pose the question for discussion out of some level of frustration over a vendor manager’s claim that software is never truly finished. The problem is that this person is in a position to always keep the dollars flowing out to selected vendors that never really ever finish products. Feature creep not withstanding I am trying to find some examples and some professional references where software is indeed finished. I believe that if planned properly and if the needs assessments are performed and business models are handled objectively that a software project can indeed be finished. Certainly other releases can be planned for and features can be added as new needs are identified. Like a construction plan if done properly software can be finished. Please discuss, and happy holidays.

All Comments

  • Author
    Replies
    • #3299864

      Yes…. and No

      by awfernald ·

      In reply to Software is never finished…really?

      I assume you are talking about in house software development vs. 3rd party application development, as 3rd party applications need to constantly bloat so that they can make money off of the upgrades they sale.

      However, as far as in house software development is concerned, the software is never really completed as long as the people who are financing the software development are willing to pay money to have changes made.

      As business processes change (or in some cases, when personnel change), the applications built must be modified to comply with the new process/policies/laws.

      Yes, a specific project can be completed, and a release made, however, I’m willing to bet that 99% of all the BUSINESS (note, not system!) applications that you project for will already have a list of things to put in the next version before the current version is even “finished”. Thus, the project is done, the app is released, now you have to go back to the SDLC and work on getting the next release done (if budgeted).

    • #3299859

      a matter of perspective

      by apotheon ·

      In reply to Software is never finished…really?

      From the point of view of the marketing department, software is finished, then sold. From the point of view of a “software engineer” wageslave, software is finished when he’s told it is.

      From the point of view of a dedicated programmer who loves his craft (a “hacker”, in the classic sense of the term), software is never finished. It can be “abandoned” as “good enough” to serve a purpose while something more important or interesting is worked on, or it can be set aside for a while, or it can be “given up” when the programmer realizes it’s consuming his or her life, or it can be taken from his grasping fingers by the necessities of programming in the working world, but it’s never truly “finished”. There’s always something more that can be done.

      It’s like being a writer of fiction: There’s always another rewrite you can do. It has been said that a story is never really finished, just abandoned. Of course, one eventually reaches the point where rewrites will actually make it worse. There’s a trick to recognizing that point, I’m sure. I’m also sure that applies to writing source code.

      There is also the quintessential Taoist approach to determining when software is finished:
      “A program is complete not when there is nothing left to add, but when there is nothing left to take away.”

      I’m sure this post doesn’t address the issue at hand, as the initial question was intended, at all.

      • #3324583

        Depends on the objective

        by sue’s comment ·

        In reply to a matter of perspective

        In house the objective is always functionality. If functional then it is finished. Then Microsoft come along with Office 2003 and you have to re-write some code that hasn’t been changed for over 3 years because the code no longer functions. 🙂

        In one case I took the opportunity to replace 70 pages of code with 8 rather than test the 275 changes I had identified! That was a good example of knowing when to stop changing the existing code. Trouble is it was a lot of work and the user sees absolutely no difference! Sometimes I wish I were not the only person here working in IT! I also wish management listened when I asked to have a working copy of Office 2003 a month before the users….

    • #3299794

      Yes and No

      by jamesrl ·

      In reply to Software is never finished…really?

      You can indeed build software that is perfect for the point in time when the requirements were being gathered.

      But few organizations stay the same. Some scope creep does not always reflect poor requirements gathering but the changing needs of the organization. Strategic goals and plans change, so software too often has to change to accomodate that. The trick is in planning things well out to account for that change.

      Often its better to implement a subset, then start a new project, rather than tackling too much at one time. That too is reflected in software “not being finished”.

      James

      • #3299611

        that’s so

        by apotheon ·

        In reply to Yes and No

        Indeed, that’s true.

        Also, you might keep in mind that some of the most successful software in the world is not written in the Microsoft tradition of huge, do-everything applications. Rather, it’s made up of a collection of smaller programs that do discrete tasks which, when taken together, make up the complete set of tasks you want your software to perform. These separate programs would be created in such a way that they’re easily interfaced with by other programs so that they can communicate between them, and so that they can be tied together by an interface application that makes them all seem to fit together into one contiguous whole, from the user’s perspective.

        The reason these software projects end up being so successful, with such longevity, is that their interfaces and functionality can be altered drastically, and easily. If you want to include a new set of functions, you just write another small back-end program to handle it and make some changes to the interface to take advantage of it. Then, if needed, the user can also access these various programs separately through the command line, and you can also use them later in other, related programs that would then become “compatible” with the first software project’s functionality. Et cetera.

        In that sense, then, a particular application can be both finished, because it’s perfect for your needs at a given time, and unfinished, because there’s always more functionality you can add to it and more you can do with it if you decide you want to, and the software will be flexible enough that it can always be adapted to keep up with the times and never become entirely irrelevant.

        • #3345618

          Software is finished when…

          by montgomery gator ·

          In reply to that’s so

          …that piece of software is declared obsolete and replaced with new software. I have worked on software systems at my company that were being phased out, and doing maintenance and code changes even with only a couple of weeks to go before the program was retired. Then the software was finished, and the process started again with the new software that replaced the old obsolete system.

        • #3346930

          If you replaced it

          by tony hopkinson ·

          In reply to Software is finished when…

          then you could say it wasn’t finished. Windows 3.11 is obsolete, but Windows is n’t. Code obsolescence is a given, software well I’m hard pressed to think of an example of obsolete software when considered in terms of function. In real terms this is the only thing that matters. I doubt our customers make the distinction.

        • #3346773

          Our users make the distinction

          by montgomery gator ·

          In reply to If you replaced it

          I work for an insurance company, and usually we phase in new systems, running in parallel with the old systems for several months, replacing a few service centers, and the users definitely distinguish between the two systems, especially when we converted from old DOS applications to Windows GUI applications. They definitely knew the difference and made the distinction.

        • #3346742

          I think you missed his point.

          by apotheon ·

          In reply to Our users make the distinction

          He wasn’t talking about making the distinction between two programs. He was talking about making the distinction between a specific program and a class of software.

          I’m not entirely certain that I agree with his definitions, but I understand what he’s saying about making distinctions.

        • #3345284

          P.O.V

          by tony hopkinson ·

          In reply to Our users make the distinction

          They certainly notice differences in the software, but they should not notice difference in the business function. So in those terms the software still alive. i.e. there is still a need for it.

          We might make the distinction that the driver for a HP Laserjet II is dead because we’ve upgraded to Vs or switched to Xerox, but the user clicks the little picture of a printer and crosses his fingers as usual.

        • #3250723

          Parallel testing? Wish we could.

          by paymeister ·

          In reply to Our users make the distinction

          We do realtime testing – very similar to laying the first length of pipe, turning on the water, and trying to stay ahead of it…

      • #3318306

        plugins.

        by jaqui ·

        In reply to Yes and No

        best way to plan for altered requirements.
        the ui is the main app.
        all functionality is through plugins.

      • #3342468

        Vicious Circle (erm, triangle)

        by scotgig ·

        In reply to Yes and No

        I once took some good advice during a business convention. In application and web development; there are no absolutes.

        In fact, you can imagine a scenario like this with three equally important factorial sides of an equilateral triangle:

        Business changeability,
        Software adaptability,
        Change suitability.

        Business changeability encompasses the need for a business to continue changing to suit its market, its rate of change, anticipated future benchmarks and a definitive gauge of its static environment.

        Software adaptability accounts for the amount of consideration given to ensure future-proofing prior to development, flexibility in current design and structure, easy of change and extent of business understanding of usage, change, effectiveness and value.

        Change suitability encompasses often complex financial, time and manpower implications related to change and not just whatever immediately needs changed to keep pace with business requirements and market pressure.

        All three key factors weigh heavily upon the needs of a business or organisation. Not one of the three is any more or less important than the others, although their integral components will have relative values.

        So, as you can maybe see from this model, it can be tweaked to suit your own circumstances and expanded if required, into sub-components and relationships between them can be mapped out to identify next steps.

      • #3250697

        Should be the first line of code in any app.

        by tonythetiger ·

        In reply to Yes and No

        ;Customer requirements change.

        It’s important to realize that, and while you cannot know what the change will be, you can structure your app so that the change is not terribly disruptive when it is required.

    • #3300504

      Safehouse

      by mrafrohead ·

      In reply to Software is never finished…really?

      I use a program called Safehouse. Its an encryption program. I can tell ya, that I’ve been using this program for about five years…

      In using this program, I have seen 1 update. That was from version 2.10.072 to version 2.10.075.

      The change that was implemented was a different lock and key basically. They added an “activation” step to the software during installation to prevent piracy.

      IMHO, that’s how things should be done. Just enhancements when needed, but no bug or hole fixes because it was just done right the first time… ;p

      Mrafrohead

      • #3301706

        Finished And Out Of Date

        by hal9000 ·

        In reply to Safehouse

        As a software developer, I can state categorically that projects have to be finished, delivered and implemented. If not, we are not paid. However, there is also much truth in the perception that the work is never finished, at least on a larger project. We constantly receive requests for expansion of the programs that we create, not because the original does not do the job for which it was designed, but because the users are continually inventing or discovering aspects that were not dealt with in the original design, and technology and the use of there of marches on. We deal with this by releasing new versions of our programs periodically. Each new version is ?complete? in the sense that it fulfils the design criterion, and will do the job for which it was created.

        I have also come across situations where a developer, either a third party vendor or an in-house developer, seems to have made a life?s work out of a single project. I personally feel that this is unacceptable, as it results in goals not being set, and not being met.

        If you find yourself in this situation, my advice would be as follows:

        Define the functionality and use of the program/system in detail, preferably before any work is done, but any time in the project will do.
        Design, or be involved with the design of the interface from the inception of the project. Interface and user logic problems are often the root of multiple re-writes.
        If possible, use a modular approach that will permit future additions to the program/system without the need to undergo a complete re-write.
        If aspects such as reporting etc are required in the program, ensure that a report generator for custom reports etc is included in the program/system.
        Institute a bug fix period, or beta testing period, during which time all identified bugs are sorted out. Do not permit additional requests to be made during this period.
        Maintain a list of requests and nice to haves, and only permit them to be added to a new version, which should be treated as a new project.

        The march of technology, and user expectations will eventually necessitate re-looking at any piece of software that has been in place for a while. When this occurs, treat it as a new project, with defined goals and a delivery date. Otherwise you will simply encourage the developer to continue fiddling, upgrading and changing the program, with no end in sight.

        • #3250731

          Very helpful list – thanks!

          by paymeister ·

          In reply to Finished And Out Of Date

          Dear Hal,

          Your “to-do” list will be very helpful to me in a project I’m embarking on just now, and your comments resonate with some wounds I’ve incurred on previous projects.

          Thanks…

          -Tim

        • #3248339

          thanks for advice

          by davspa ·

          In reply to Finished And Out Of Date

          Thank you for the advice. At the very least it is something to think about and take into consideration when planning or working on a project. I am one of the ones that tends to keep projects dragging on! We have to live in the real world that involves money and getting things done for pay, as it should be, and at the same time (at least I do) enjoy tinkering with new code / ideas for projects.

      • #3318304

        yup….

        by jaqui ·

        In reply to Safehouse

        but most companies are more interested in that paycheque of a release than properly coding the app and then properly testing it.

    • #3301722

      Not entirely true

      by cpalconet ·

      In reply to Software is never finished…really?

      I belived that if all requirements for the software are identified and all requirements are meet by the software, then it is finished.

      the problem lies in the User interface, simplicity and sufficient information shopuld be available to the user with minimum error in data entry or data selection.
      the program developer should be aware of this issues, and once properly executed I do not see any reason for the project to be delayed any further.

      the second problem or issue are the user friendlyness of the software, bugs and loops.
      assuming that the developer of the software has extensive knowledge in this field, this should not be a problem.

      software that never end are softwares written by poor developers or amatures or too many wish list of the customers.

      • #3346204

        Engineer pulls crank.

        by tony hopkinson ·

        In reply to Not entirely true

        If you’d have put one of these statements in amongst some sense I might have bit, but no too obvious matey.

    • #3301721

      Technically True

      by harsha.mangalmurti ·

      In reply to Software is never finished…really?

      Probably thats the perfect question to answer.

      Requirements Phase of any project is crutial in a sence to identify the completion of a Project. So you start a project keeping end in mind.

      Its a good practivce to follow a structured approch for Requirements gathering. This also helps the customer to prioritise the needs based on ‘time and cost budget’.

      Also the structured approach towards Acceptance help to descide the intermediate deliverables as well as the phased acceptance of any product.

      Process to address suitable maintenance schedule as well as a schedule for new features develpment is a must.

      I believe that this structured approch shall help in desicion making and provide better clarity so as to avoid the commercial intangles.

    • #3301714

      Adapt or die

      by ken.newby ·

      In reply to Software is never finished…really?

      Software is developed to enable a business requirement for information or to automate a process (amongst other things).
      In today?s fast changing world, business needs are changing on a daily basis.
      If we develop to a closed specification, as in the past, are we really adding value to our enterprise or should we be in a ?software on demand? mode. Is this not what components and web-services can start to lay the foundation for?
      Times are changing for our customers ? we must keep up or go out of business.

      • #3318457

        quite so

        by apotheon ·

        In reply to Adapt or die

        You make a very good point. It is in part because of this that open source software development is being increasingly recognized as an exremely valuable resource for software in production computing environments.

    • #3301713

      “Is the Glass: half full or half empty?”

      by bobo_smasher ·

      In reply to Software is never finished…really?

      ___ Maybe this — “Software is never finish… really” — issue falls in the (“Is the Glass: half full or half empty?”) category. It just might be: how you look at the saturation.

    • #3301711

      “Is the Glass: half full or half empty?”

      by bobo_smasher ·

      In reply to Software is never finished…really?

      ___ Maybe this — “Software is never finish… really” — issue falls in the (“Is the Glass: half full or half empty?”) category. It just might be: how you look at the saturation.

    • #3301710

      “Is the Glass: half full or half empty?”

      by bobo_smasher ·

      In reply to Software is never finished…really?

      ___ Maybe this — “Software is never finish… really” — issue falls in the (“Is the Glass: half full or half empty?”) category. It just might be: how you look at the saturation.

    • #3301705

      Depends on the Application

      by robertestx ·

      In reply to Software is never finished…really?

      I believe there are applications that have been developed and “finished” for no better term. I’ve seen many software apps that were finished in regards to business functionality – sure there may have been changes made based on OS changes or even hardware changes, but for the most part there was no on going development in the business model. However, for the most part I believe that until “auto-morphing” development tools are created 😉 then it is inevitable for software to ever be considered finished. You have to consider the IT world we live in – advancements are made more quickly in our field than practically any other. Code that was written to run on the hardware available 5 yrs ago, today can be customized to take advantage of significant technological advances in that short time. Sure, base functionality probably remains the same, and in that regard the product can be considered “finished”; but as the business grows, business rules change, therefore your software that supports those business rules must change. (exclusive of OTS software.)
      So I guess my comments fall into the “Yes, it can be finished” with some exceptions to that policy…
      May the best of 2004 be the worst of 2005 for you all.

    • #3301689

      Never

      by kengoad ·

      In reply to Software is never finished…really?

      Saying that software is finished implies three things that I believe are an impossibility. One, your analysis of the solution is perfect and that every possible contigency has been thought of and every point of view has been taken into consideration. Two, that the world is unchanging. Once you have a written a software solution, inevitably, something upon which based your premise has changed therefore creating the need for a change in your solution. Three, you assume QA will find, and engineering will eliminate, every bug which exists within the solution. While I believe you can come pretty close to finishing a software package, I don’t believe it is ever truly finished. The most unchanging comment when software is delivered to the end-user is “I absolutely love it, but…”. Even if they were fully involved in the development you will hear this comment.

    • #3301665

      Software is eventually complete

      by alicia5 ·

      In reply to Software is never finished…really?

      When there is no longer any use for a software application, it is finished and discarded. Just like anything else in the world that which is ‘alive’ and useful is not finished. As business needs change the software the business uses will also change and adapt. Someday, however, every software program will come to the end of its usefulness and be discarded, then it is finished!

    • #3301660

      Software Projects and Business

      by msuarezb ·

      In reply to Software is never finished…really?

      Syncromind is an Offshore provider from Argentina. We have worked with US clients and we have had great success in finishing software PROJECTS.

      That is, we have set some initial requirements and gone through some cascading cycles until an acceptable first release was put into production. I think the key to finishing software development projects is to take it with a “dynamic requirement” view and work on change management appropiatelly with the client’s active participation.

      Under this line of though software CAN be finished, once enough iterations occur.

      SOFTWARE is never finished because software needs to be aligned with the business it was meant to help/control/empower. Business requirements and realities change every day (replace with “month”, “year” or any other time scope) so the software related to it has to change accordingly.

      I believe you need examples so here they are:

      [Web Application Development Project]
      We have worked with a Arcadia, CA based company that works on structural engineering for hospitals in California. We built a Web application in .Net that enables hospital managers and project managers to easy up the red tape regaring the quality assurrance reporting.

      We started out with a vague vision toward where we where heading, even though the time-to-market was ambitious. We knew that changes were going to arise, so we remained flexible.

      Changes indeed were needed so we started including periodic revisions (spirals in a software development process) in order to stay aligned with the real business needs.

      With active client participation and relatively small cycles we accomplished the development in record speed time (3 months) and the client was satisfied with the first version.

      Now that the project is closed OUR CLIENT is requiring additional features for the project.

      —–

      I think that the example is good to express my experience in the field. I want my clients to receive working software and when they belive they need more, they can contact us for new projects or ongoing updates.

      I hope this helps and please don’t hesitate to contact me for whatever you may need.

      Cheers!!

      Mariano Suarez Battan
      Partner at Syncromind
      http://www.syncromind.com

    • #3301645

      Incredible IFs

      by jhmanley ·

      In reply to Software is never finished…really?

      “I believe that if planned properly and if the needs assessments are performed and business models are handled objectively that a software project can indeed be finished.”

      Take the largest and darkest font you can find and use it on the two “ifs” in your quote. I would agree with your point however I would argue that 99% of the time your if statements return false.

      Software engineering can be broken down into 3 components: Time, Money and Functionality. Pick 2 and sacrifice the third. You want all functionality and quickly? Expect to pay a lot. You want it quick and cheap? Reduce the functionality. Trouble with all this is that users don’t want to sacrifice anything. They want it cheap, fast and able to solve world hunger. The projects are comprimised, timelines compressed and inevitably they fail or as you point out continue on in perpetuity.

      I have been doing this for nearly 15 years and I can’t remember a project that was “objectively” scoped and planned. Where the people executing the plan said, “this will take 10 months” without someone coming back and saying, “How can you do it in 6?” For some reason the business user always thinks tech folks overestimate when in reality it is in our nature to underestimate. We always think things are easier than they turn out to be. We envision a vacuum where if we had 8 hours a day to work on a project we could achieve the goals. Reality doesn’t turn out that way.

      Interesting post. Would love to hear feedback.

      • #3301591

        Agreed! However…

        by p3john ·

        In reply to Incredible IFs

        I have to agree with JHManley. Experience has shown me that there must be compromise between Time, Money, and Functionality.

        To add my 2 cents I’d say that project sponsors (or whatever) are never really satisfied because they need to adjust their expectations.
        However, if we limit our conversation to say, a particular build or version, then, yes, it can be viewed as “complete” – but the application in the larger picture will always be dynamic.

        • #3301548

          Requirements seem to change daily…

          by mtbergan ·

          In reply to Agreed! However…

          …as business needs morph. In a vacuum, sure; in reality, not necessarily.

    • #3301555

      It it’s useful…

      by mbayrock ·

      In reply to Software is never finished…really?

      As frustrating as it is to me, systems development could be a never ending process. Systems (software) projects finish, but the software is “finished” when it is replaced with something new.

      A while ago, I heard the phrase, “If it is useful, it must be changed.” – the implication being that it must (and will) be changed to be _more_ useful. The more people use a product, the more they will say that it could be better if it did [fill in an idea].

      So what do you do? Focus on the software _project_ phases, including closure, and don’t sweat it if the software continues to evolve. After all, that’s the source of new software projects…

      • #3318431

        in other words:

        by apotheon ·

        In reply to It it’s useful…

        Something is only “finished” when it cannot be improved. It cannot be improved when:
        A) it has been abandoned
        B) it has been designed into a corner
        C) it is replaced

        Or . . .

        Software is never really “finished” because your needs will change before you can ever completely fulfill them with a given piece of software. Professional software development is a constant game of catch-up.

    • #3301538

      Catch 22

      by alexp023 ·

      In reply to Software is never finished…really?

      This discussion can go on even longer than some projects. My take is that like the construction plan you referred to, if you follow the project plan and original design documents with no modifications, then it becomes complete. But in the real world it usually takes on a life of its own.

      I think it’s best covered by one of Murphy’s Technology Laws – Whenever a system becomes completely defined, some damn fool discovers something which either abolishes the system or expands it beyond recognition.

    • #3301512

      How about games?

      by sdmagic ·

      In reply to Software is never finished…really?

      While game software might fall into the “abandoned” category, I would argue that some games are truly finished. They work as advertised, and don’t have to be maintained.

      Also, a lot of small system software and utilities can be called, “finished”. I’ve written utility programs that I and others have used for years. They are narrow enough in scope that there has never been the need to maintain them — they do what they’re supposed to do. On the other hand, I’m currently writing a utility that will never be finished because it relies on applications written by others — When they change, the utility might have to be changed.

      With all that said, I’ve never seen a non-trivial application that I would call, “finished”, and I’ve been in IT since 1977.

    • #3301498

      Only When Someone Says It Is!

      by pcruth ·

      In reply to Software is never finished…really?

      Unfortunately, the only way to truly complete a software development project is to declare it finished and be done with it. The fact is, he one thing that man has been unable to predict with any accuracy is the future, and software is no exception. The question is, does it matter? Logically, once the original requirements for a particular software system are met, the project could be described as being finished. However, 90% of the Total Cost of Ownership of a system is accrued after deployment; that includes bug fixes, enhancements, etc. So when is it really finished? When someone takes the responsibility to declare it finished, and all work on it ceases.

    • #3301463

      Are SD contracts ever closed?

      by dhislop ·

      In reply to Software is never finished…really?

      A distinction that may be helpful here is the difference between the questions, ?Is a piece of software ever finished?? and ?Does a vendor ever finish delivering on a software contract??

      The answer to the first is like asking ?Is a hospital ever finished being constructed?? Who knows? Many times there are small additions and remodeling, and sometimes entire wings are added years after the initial construction is finished. Buildings can evolve over time just like software when the need is there. But construction contracts are closed/completed every day.

      The second question involves the needs of the organization. Does the organization need a vendor to build and deliver a piece of software and then close the contract and stop the money flow to the vendor, or does the organization need the vendor to provide an ongoing service that includes modifying the software application. The problem arises when you want the former, but the contract is structured to allow the latter. If you want the former then the contract must be structured with a statement of work, and a payment scheme that supports that.

      Now to put the two answers together. Knowing that software typically evolves and is maintained long after it initial release, and knowing that contracts for software development can and should be structured to meet the needs of the contracting organization, an interesting question could be ?In your organization can contracts be structured to make reasonably sure that software deliverables are completed on-time and still allow for the vendor to provide software maintenance if needed??

      You could open up the idea of a contract that includes a deliverables based payment schedule, and a fixed-time maintenance time period at an hourly rate. With the deliverables based payment schedule the vendor would be paid when software development milestones are complete according to documented requirements as judged by the contracting organization. After all deliverables are complete the maintenance period would begin possibly with reduced vendor staff for a predetermined period.

      Software development contracts are closed everyday.

    • #3318491

      SW is never finished because Business Continues

      by pittsburgh ·

      In reply to Software is never finished…really?

      SW is never finsished because as users delve into the functionality provided, they discover another, deeper need. The common analogy is ‘peeling an onion’.

      As a developer and analyst for more than 15 years it has always been my experience, both in-house and for ‘shrink wrap’ development, that there is always another need or perspective. As soon as users understand and employ what is in a release, they find a different and better way of doing or looking at the data.

      If SW is a reflection of a user’s needs and not an end unto itself, it is never truly finished. SW is only a tool and not the problem to which it is applied. So long as business continues, there will continue to be new needs to be met.

      • #3318389

        I Agree

        by techrep ·

        In reply to SW is never finished because Business Continues

        And rather than fight it, I’ve focused on a consulting developer practice that had high-speed development tools, so that the with time normally spent on pinning down the micro design goals of the important users, you instead deploy, adapt and update changes as they stream in inside a change management structure.

    • #3318390

      Finishing is Bad

      by techrep ·

      In reply to Software is never finished…really?

      Software can be done. But if you are designing to a complex and changing business process, it shouldn’t be.

      I think the future is hinting that software will become more and more dynamic, with business stake holders able to update and change many of the software functions and parameters as needed without coders on hand.

      In fact, this is the type of software I tend to design for my clients.

      • #3318298

        indeed

        by apotheon ·

        In reply to Finishing is Bad

        I certainly hope that software design is headed toward a more dynamic model (and I believe it inevitably is). Only by turning software back into a service, instead of continuing to try to treat it as a product, can we really have much hope of saving the IT industry in this country. It’s ironic to see all the Windowphiles denigrating open source software, considering that’s the development model most likely to actually keep programming jobs in the industrialized West.

        Of course, Microsoft itself will keep trying to paint OSS as the “enemy” because Microsoft’s entire business is based around the shrink-wrapped software-as-product business model.

    • #3318388

      Do you still use DOS

      by richard p ·

      In reply to Software is never finished…really?

      I’ve written several small appications that were complete. Some still run! But here is the catch. Either the customer wanted the interface updated OR they only run on systems that no longer have any support.
      Do you use DOS 6 or Windows 3.1
      or even RH linux 6.2?

      • #3318269

        Dos Apps

        by jamesrl ·

        In reply to Do you still use DOS

        I do know a DOS app that is used daily by thousands of people. Its an application for customers of a big Canadian courier company. I was there for Y2K and the original plan was to replace it with something big and fancy(VB/C++)in the Windows environment. But due to time contraints, it was decided to make the existing app work for Y2K. Four years later, my new employer still uses this app daily without any issues.

        On the other hand, the Ontario Government commissioned a land survey registry system about 10 years ago, and it took 8 years to fully implement – everytime they thought they were finished they were looking at the obselecense of their architecture.

        James

      • #3345276

        Windows 3.1

        by tony hopkinson ·

        In reply to Do you still use DOS

        A colleague, is currently implementing one of these because the machine it was running on had a heart attack.
        The software written for it still works and is still fit for purpose and would cost a lot more to re-write than a pc but won’t work on 95 onwards. Mad but true.

        Load of bemused techs sat around trying to remember how to twiddle with protocol.ini.

        I left one place in 99 and it was still using 8 inch floppies on one device. Technology used to be tough in the old days.

        • #3250651

          Nothing is really obsolete….

          by rknrlkid ·

          In reply to Windows 3.1

          if it is doing what it was designed to do.

          I recall a forum conversation many years ago. There was a major university in California who ran a custom application on an IBM PS/2 Model 55sx. The hard drive was going out, and they were pretty frantic because the software was written specifically for that computer. Budget realities came into play because getting the application rewritten for the then current Win9x series of software was not only impractical, but way too costly. So several of us gave ideas on how to get a new OEM hard drive or to do the upgrades to keep the system running.

          “Latest and greatest and newest” is not necessarily the “best solution.” Sometimes sticking with what you have is.

        • #3250213

          Agreed, other side of the coin

          by tony hopkinson ·

          In reply to Nothing is really obsolete….

          This is way back when . PC was a hybrid XT 286. In 1993 the printer on the system stopped working. Turned out to be the card. The card was a video/printer combo and unsurprisingly no longer available. Replaced it and the software crashed. They’d written it to do direct writes to that brand and model of card’s ports.
          Stuffed up gloriously. The thing had lasted over ten years so they’d had pay back but the departmental manager was very unhappy with ?50k for something that would cost ?50.

        • #3250202

          Why all the panic?

          by apotheon ·

          In reply to Nothing is really obsolete….

          Shoulda just run a DOS emulator in Linux. Linux is more backwards-compatible to earlier Microsoft OSes than newer Windows OSes tend to be.

    • #3346487

      To Spec

      by rpmcaninch ·

      In reply to Software is never finished…really?

      If you allow it, the improvements and extra additions to a software application can continue ad nauseum. That said, when all of the customer’s specifications have been met, the software is finished and the cycle starts over again. Disciplined project management has to keep a tight reign on project scope.

      • #3346394

        Thats the nice simplistic approach

        by jamesrl ·

        In reply to To Spec

        The reality that I have seen at many large companies is that requirements are deferred to keep to timelines, new requirements are found during UAT, new players come into the game, the business continues to change and grow. Which means that once you put that new software into production, you have a list of requirements and needs for the next version already.

        James

    • #3346401

      No technology is finished

      by jseller ·

      In reply to Software is never finished…really?

      Think of another technology for comparison. Is the technology of automobiles ever finished? no, but a particular instance of it is, or else we wouldn’t be able to actually use them. particular instances of software are finished, indicated by their version number, but the technology is never finished. Vinyl Lp records are an example of a technology that is essentially finished.

    • #3345624

      Software ever finished?

      by timjor19 ·

      In reply to Software is never finished…really?

      I believe it depends on the application’s enviroment of use.

      If it is used in a dynamic environment, then it will need to be adapted and will need to be updated/changed over time.

      If it is in a static enviroment then yes, I think the program can be cosidered finished once it is optimised and tested to be stable.

    • #3345898

      Finished means DEAD

      by charles simon ·

      In reply to Software is never finished…really?

      In the development of software for sale, which I have been doing for over 25 years, I have found that there are 4 phases of software development.
      1) product creation
      2) product enhancement
      3) product stability
      4) product retirement (actually death)

      Product creation (1) is the process of finding a need and defining the target customer. You then desing and write the code that addresses the need as it was understood.

      Product enhancement (2) is the process of receiving customer feedback for missing functionality.

      Product stability (3) is the last useful (and profitable) phase where there are no more useful features that SHOULD be added and most of the changes are fixing the bugs that are uncovered while using the product.

      The last state for a product is retirement, the equivalent of death, by the software company. It is still being used but is no longer being actively sold or purchased and you receive very few or no bug reports. At this point the product is FINISHED. It also means that the company has no vested interest in receiving calls about the product. Has laid off the developers or they have moved on to other products and are not about to fix a bug in the old product unless a customer is still paying large bucks for support (cash cow) or threatens to sue you.

    • #3326189

      NO and yes!

      by johnj42699 ·

      In reply to Software is never finished…really?

      From a contractors point of view, I firmly believe that the completion of a software project is totally a question of defining the, or a customer’s objective.
      IF a software manager starts a project without a properly defined project he needs to be shot somewhere painful. In order to set out you need a map, or you get lost. Dealing with Govt. departments is a prime example, they always want soething else, but each time the agreed spec changes you need to renegociate the contract, and this will need an honest re-evaluation of in-house resources, and a good hard look at the timeframes involved in rework acquiring appropriate skills/facilities if you don’t have them etc.
      Perpetual development is death for many organisations who lose not just the profit in the job but possibly their shirts.

      • #3326143

        Got it in phase one ?

        by tony hopkinson ·

        In reply to NO and yes!

        Types of never ending software.

        1) Undefined goal
        2) Incorrectly defined goal
        3) Moving goal
        4) Evolving goal
        5) Hidden goal.

        The last one I think was the original poster’s concern, that’s where the vendor
        uses 1-3 and to a certain extent 4 to create 5 and a ‘never ending’ income stream.

        It has certainly happened in the past, which suggests that it does happen now. Whether that’s true in this case I can’t comment. All except 4 are a failure of management. Evolving goal is a given in any business that has to adapt to compete and even then it’s effects can be drastically reduced with a better design. Not popular this as it usually means spending now to avoid spending later which messes up the bean counters spreadsheets.

        As a developer I want clearly defined requirements so I can prove that I’ve met them and that I’ve a right to more money for these little changes that have just been thought up.

        As a purchaser I need clearly defined requirements so I get what I need for my money and so I can establish where I’ve been shortchanged. Also I can do a realistic analysis of my changed requirements and decide whether it is cost effective to continue with the vendor or to wrap it up and go for a next phase or an alternative.

    • #3326004

      This being a legal issue

      by just a guy from spain ·

      In reply to Software is never finished…really?

      This is my opinion:

      The problem of software being finished is not an IT issue. That is a LEGAL issue.

      IT people (including me) should pay more attention to contracts…

    • #3325975

      Games projects complete but life goes on

      by setanta ·

      In reply to Software is never finished…really?

      Games projects complete but real customised business systems will require changing over time as business requirements change to meet market requirements and business need

    • #3325963

      Software finished, depending …

      by luis ·

      In reply to Software is never finished…really?

      I would say that a specific software to do something very well defined, an encapsulated process which is stable in time, could be finished very well.
      Now, if you are responsible for the software in a large, dinamic organization, conditions change every day so you need to have a continued upgrade of the software which, if you do it in-house gives you the feeling as if it’s never finished. It has to do with well defined objectives but also with the dynamics of the organization. You cannot take a picture at one time, and after 6 months of development deliver de software for that picture expecting that no changes where made on the requirements. At least not in some organizations. Probably is not going to change the hole thing but some parts at least. In a large software (ERP)with many modules there is always something to develop. But if you take a small portion of it it may not change in a couple of years.
      So if software development is finished at one point or it’s a continuous process it depends on what you are speaking of.

    • #3325933

      I Hope Not

      by bpatty ·

      In reply to Software is never finished…really?

      Personally, I would hate to see an end to the devolopment and refining of the software that I use. Software should continue to evolve to meet the needs of it’s users.

    • #3325898

      Define what “finished” is first…

      by dsr28 ·

      In reply to Software is never finished…really?

      I have found that a lot of software starts off without completion in the start. Proper definition to the software project (whether in-house or third party) is the key to completing the software.

      If you put a lot of effort into defining not only what you want the software to do today, but what the software should be able to do in the near future – then the software development cycle can complete successfully and only be revisited in the upcoming years, or when the company has a change in direction.

      I like to tell clients to think of software as a tool. If you take a very simple tool, such as a screwdriver, the software may never need updating. However, something more complex like a chainsaw may require maintenance, updates or overhauls depending on who uses it, what it is used for, and how often.

      With proper management of the process, it is possible to finish a software product.

    • #3325897

      Only when business is done

      by pmoleski ·

      In reply to Software is never finished…really?

      Projects can complete. If a business is living then the requirements of that business will change over time requiring new changes to existing software or completly new software if the change in the business is big enough.

      When the business becomes stagant it usually fails which means time to find a new job. Venders that come up with new and innovative changes to software that help businesses, just like inhouse developers and analysts that innovate are both good. The innovations help the company you are working for to continue to stay competivite and evolve into the future. If ever we view change as work rather than why we are here in this industry it is time to find a new job.

      The topic of poorly wirtten, bug filled software is quite a different topic than the above. The reward to a vender that does that should be to switch to another vender if there is a realistic alternative. However venders live in the real world like the rest of us where quality is what is possible in the time you have to get something done. It is a bit unreasonable to expect more from a vender than we do from ourselves.

    • #3326554

      Software is developed, then maintained.

      by jcallahantx ·

      In reply to Software is never finished…really?

      My approach to this question is from a life cycle perspective. Software, like most products, has a life cycle of development, delivery, implementation or use, improvement, and finally, replacement. Most software products, when delivered, rarely meet all specifications. During the implementation/use stage of the software life cycle, improvements may include both those specs not included in the original delivery and new specs that represent enhancements to the software product. Whether we call it software development, maintenance, or improvement, this activity is continuous until the software is replaced or retired. Good software is never finished.

    • #3326539

      SDLC says it is never really done

      by rnmpleasant ·

      In reply to Software is never finished…really?

      You are looking for professional examples of when software or development is ?done?. I think you will be hard pressed to find that but if you do, it is only from one perspective. First, separate out system applications from user intended applications. Systems applications can be finished if planned out because their requirements are largely driven by finite circumstances (machine requirements, OS requirements drivers, etc.). Even in these cases, though, we see many upgrades and patches in the lifecycle. However, in a business application, there are many challenges to doing it as good. First, time to market is a big factor. The next challenge you face is feature dependency and complexity. Unless the application is small, there is a core set of objects that must be in place for any of the advanced features to work. However, you may find that one such object will take 2 months to correctly architect out while the rest of the application seems to be completed in the same amount of time. The next challenge you face is success. This always has the unfortunate consequences of creating the next wish list. In essence, as you offer features, you change the way people do their jobs and this causes a focus shift to other areas that need attention, thus, creating a new set of requirements not previously discussed or realized. In the end, ?done? is a shaky term that relies on elements of time, money and necessity (all of which change with business days) and then is measured against technology (which also moves) to determine.

    • #3326484

      Software Development Projects Can and Should be Finished!

      by gskinner ·

      In reply to Software is never finished…really?

      Software development should be carefully planned and comprehensively executed throughout the development process. The scope of the project must be clearly defined at the beginning, and signed-off on by all parties. Scope Creep or “Feature Creep” must be avoided at all costs; as this insidious reality of software development is all too common. When the current development project is completed, the newly discovered “features” or additional functionality can be considered and weighed against the costs and benefits of a new project. The statement of your Vendor Manager that “software is never truly finished”, only serves as an excuse for failure to hold vendor’s accountable.

      Read about a related subject of software maintenance by clicking on the thread below:

      http://techrepublic.com.com/5208-6230-0.html?forumID=91&threadID=166132&start=0

      • #3326456

        Now I feel like a complete wally

        by tony hopkinson ·

        In reply to Software Development Projects Can and Should be Finished!

        I actually clicked on your link.

        Ah can’t be bothered.

      • #3326415

        Life in the real world

        by jamesrl ·

        In reply to Software Development Projects Can and Should be Finished!

        Your post sounds like an ad.

        Those of us in the trenches know that yes, you can and should finish software projects.

        But that does not mean that the software is finished. Scope creep that is managed or deferred doesn’t disappear. How many times on major projects have we had one project finish, wait a month for the software to stabilize, then pick up the list of deferred items and see if there is enough justification to start another project.

        And vendors don’t make it any easier either. As major vendors like Oracle or Peoplesoft withdraw support for older products, they force people to upgrade to newer versions, which have more features. That encourages the users to not think in terms of simple like for like upgrades, but instead of adding functionality at the same time as moving up to a later version.

        James

        • #3322728

          Always More

          by dogknees ·

          In reply to Life in the real world

          One thing I can think of that would mean a lot of software thought to be “finished” would need to be modified.

          What if we change Calendar forms again? It’s happened before, and will probably happen again one day. When it does, of course all software working with dates, and that’s most of it at some point, will need to be changed.

          In the real world, it’s never finished, although the development project may be.

          Regards

    • #3326233

      It’s SD ‘Life Cycle’

      by drmemory ·

      In reply to Software is never finished…really?

      You can interpret SDLC two ways, that it is a perpetual process or that it should include the criteria for obsolescence. I prefer the latter. At some point the convenience of extending the life of an application seems to blind everyone that its time has passed and replacement is in order. Package vendors may continue the name, but most will engage in a major re-write (MS notwithstanding) when the technology base is clearly superceded. By specifying the end-of-life criteria, the then current management is provided with the necessary opportunity to formally decide that the end has come.

    • #3328133

      Reality Check

      by paul.tiffany ·

      In reply to Software is never finished…really?

      Having been in software development for over thirty years, I can categorically state that software is only finished when it is replaced by something new. It is a fallacy to think it is even possible to perfectly define and design a “system”. As people use a system and the world turns, there will always be a need for modified or additional features.

      That said, usually much more should be done to better define software features before and DURING development to assure effective results in the near term. Architectures and designs should be documented as living systems, NOT as an assumed static end result.

      This also means that care should be taken to preserve previously developed features (in previous releases). This is probably the biggest failure of software companies like Microsoft. Of course, Billy learned the lesson of planned obsolescence a long time ago. Software that is hungrier and hungrier for resources without a significant improvement in features has been a mainstay for hardware manufacturers ever since the advent of Windows.

      As the rate of technological improvement accelerates with computers, networks and communications; the need to more rapidly develop changing systems to take advantage of this technology increases in like manner.

      • #3342414

        Never done, never works

        by straightshooter ·

        In reply to Reality Check

        I’m of the opinion that software is never finished. In fact, I’ll go one step further (and really tick some folks off!) and say that it NEVER works! Oh sure, it may work 90+%, but is that working? In an industry that works on ones and zeroes, right or wrong, on or off, how is it that we accept something that “sort of” works? Or as the SW industry says, “works substantially in accordance with the documentation” Substantially? Is that good enough?
        How long would you keep your job if you performed it “substantially in accordance with the job description?” Or substantially in accordance with my bosses wishes?
        Come on folks, it will never get better unless we demand it. We certainly don’t tolerate this level of performance with our hardware!

        • #3342377

          “substantially in accordance with”

          by apotheon ·

          In reply to Never done, never works

          I gather you’re used to the complex GUI-app culture of Windows users. Bloatware in general has exactly that problem with failures of functionality all the time for the simple reason that it’s overly complex. This is one major reason that unices tend to be far more stable: rather than creating massive, monolithic applications that collect six hundred features into one single hunk of spaghetti code, the unix approach to feature-rich functionality is to create a number of smaller utilities that each do “one job, and do it well”. In fact, that’s an oft-used slogan of unix utility design in certain programming subcultures (most notably the venerable “hacker” culture that dates back to before the creation of the original Unix operating system and C programming language).

          The “one job, and do it well” approach produces a number of very small, generally bug-free (after a couple iterations, at least) utilities that do EXACTLY what they’re expected to do, and when many features are needed for one large task they get tied together with “glue” applications that allow multiple utilities to interact with one another. Such glue-apps, or meta-applications, tend to work best when they exist as command line capable scripts on which you can slap a GUI veneer if you need to (again, separating “glue” and “GUI” into two “one job, and do it well” programs).

          For instance, all the necessary tools of a fully-featured word processor exist at the command line in the average modern unix system (such as any Linux distribution) as individual utilities like wc, cat, grep, and so on. One could easily cobble together a word processor application with a meta-application and a GUI constructed with some graphical toolkit like GTK+, though generally nobody bothers because there are so many word processors that already exist and work “substantially in accordance with” their needs.

          In fact, I haven’t looked into it, but there are probably a few word processor programs that actually do just that. Most of us who understand the value of such an approach, however, don’t tend to use integrated word processor applications because we also know the various tools that would make up the functionality of such a thing, and we tend to simply use them from the command line. After all, part of the reason these tools exist as command-line utilities is that they are more powerful, flexible, and quickly applicable from the command line than from within a GUI environment with drop-down menus, radio buttons, and text fields.

    • #3327551

      Definitely depends upon point of view

      by carolange ·

      In reply to Software is never finished…really?

      I often remark, ‘it’s all beta…’

      But to paraphrase some recent poetry of Donald Rumsfeld (Secry of Defense): “We often go into production with the software we have, not the software we wish to have or hope to have someday.”

    • #3325454

      There’s a reason

      by peter choi ·

      In reply to Software is never finished…really?

      The most important reason for a project to continue:
      The project is keeping your job. If the project ends and there is no new project (just maintenance), companies here usually sack the current staff and find cheaper ones. The safest stage is that when the project is ongoing and nobody can take your place…

      ==================
      http://pccm.blogspot.com
      A typical Hong Konger sees a dim future ahead. That’s why I am working
      harder to gain an edge under this adverse circumstance.

    • #3250711

      A useful adage and an effective estimating tool

      by paymeister ·

      In reply to Software is never finished…really?

      “The first 90% of the job takes 90% of the time. The other 10% takes the other 90% of the time.”

      And in estimating times-to-completion, consider the “2x-Shift Rule” – it states that for any project (from taking out the trash to a space shuttle launch), you should make your best guess as to completion time, then double it, then shift it to the next unit. For example, my current web-based payroll project should take a week to finish. Doubling gives two weeks, and shifting gives us two months. My project MAY be ready for testing then… but “finished”? Never!

      Thanks, all, for your useful insights and suggestions. -Tim

    • #3250699

      From experience, I can say ‘Really!’

      by tonythetiger ·

      In reply to Software is never finished…really?

      We have one app here that I have been adding features to for over 20 years! Eventually I am going to re-write it in a more modern language, but since taking over the network duties, my time for uninterrupted software development is extremely limited.

Viewing 42 reply threads