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

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.

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

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

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.

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.

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.

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

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

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

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.

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.

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!

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
www.syncromind.com

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

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

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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:

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

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.

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.

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

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.

"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

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.

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.

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