Web Development

General discussion


Software is never finished...really?

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.

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Yes.... and No

by awfernald In reply to Software is never finishe ...

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

Collapse -

a matter of perspective

by apotheon In reply to Software is never finishe ...

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.

Collapse -

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

Collapse -

Yes and No

by JamesRL In reply to Software is never finishe ...

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


Collapse -

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.

Collapse -

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.

Collapse -

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.

Collapse -

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.

Collapse -

I think you missed his point.

by apotheon In reply to Our users make the distin ...

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.

Collapse -


by Tony Hopkinson In reply to Our users make the distin ...

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.

Related Discussions

Related Forums