The number one reason why application maintenance is so costly is??? EEK PLEASE HELP ACADEMIC QUESTION

we can't do your homework for you, as per the member agreement we all signed

I must agree with "stevenlewis" but, your question is not that hard, just think a little !

Best Regards !

> e) ...

eep, I guess I'll stop having to quote from spam emails :-)

but $8/hour IS cheap...

technology is always getting updated

oh yeah and also clients find the dumbest errors

Dependng on the software to what answer you want to go with.

Is the softwrae designed for 1 client only for their business needs?  Is it freely out there for anyone to buy?  How old is it? What does it do?  How much did you pay for it?  What kind of support is given with the software?  It is easy to use?  Easy to debug? stable?  does it crash alot?

Millions of things come into the factor of the cost.

Keeping in mind though.  My old company use to charge nearly $350/hr (Australia) for my time on a client site.  Mind you though I knew the software and how it worked inside and out.  I was expected to fix it first go or don't bother tying to get it fixed.  If there was a problem either hardware or software I was to fix it.  Clients paid high rates then, but they got great service for it too.

Let's see... I am a professional developer so I should know this... :-)

> The number one reason why application maintenance is so costly is:
There are often dozens of reasons.

> a.     Documentation is obsolete or missing.
Yep. It's quite common, especially in small developers teams, that developers decide to do the documentation afterwards, when the code is ready and finished before the deadline. Then, after the deadline they could update the documentation. Unfortunately, after the deadline they just get another project in most cases. If not, developers just prefer to do other things than just write documentation. I've seen projects with hundreds of source lines and no comments even in the source, as if whomever is viewing it would know what it is about...

> b.   Unskilled programmers made enhancements.
Yeah, this happens too quite often. I worked on a project once that had a complex structure. After a few months it needed to be updated but I was too busy with another project so they went to the least experienced developer in the company and let him take over my project. BIG mistake of course, since he didn't understand what it did, didn't think the 5 comments in it were useful, didn't listen when I explained him how it worked internally and what he should be aware of. And in the end, he made the ultimate sin... He broke the structure and replaced it with his own structure. Too bad that my structure was created as a time-saver while his just took more and more time. He worked about three months on it before I was done with my project. Then his manager got too frustrated and knew I was available again. He called me, and I got to work on this project again. The first thing I did was take my own copy of the project, that this other guy hadn't messed up. Then I asked for the specifications of what needed to be altered and a week later I created something that worked better than whatever this replacement had made in three months. (Three months in the garbage, btw. I didn't even bother to look at his changes after two days since they were too rediculous to see.)

> c.   The code was written in an old version of the programming languages.
Yeah, this is often a problem too. I use Delphi for a lot of projects and one nasty thing is that every new Delphi version requires that all 3rd-party libraries need to be recompiled with the new version again. This often results in errors and warnings and other fun stuff. And big problems if we don't have the original source code since that means we cannot use it anymore. Some minor changes in the new version of the development system can also cause lots of nasty issues that require me to not only recompile those libraries but also to modify the sources to match the new version.

> d.  The programming techniques used in the original are obsolete.
This now happens with .NET development. Many projects were done in C++, VB or Delphi and run nicely under Win32 environments. But moving those projects to the .NET environment isn't as easy as it seems, especially if you use a lot of low-level API functions. It also happened years ago when computers moved from the MS-DOS platform to Windows 3.11, then to Win32, then to the NT-based Win32 systems. The rise of object-oriented programming, which has now become a standard, did cause a bit of a stir. The rise of XML and webservices and distributed computing is also adding to the whole complexity.

> e) {nationalistic remark removed - ee_ai_construct, cs admin}
Well, conflicts and disagreements between developers also cause some losses. I've been in such a situation once. I had written a nice design for some security component which my manager considered okay. But some newly hired guy also wrote some crappy solution and unfortunately he was a personal friend of my manager. Even worse, even if it was his suggestion, I was supposed to write it. Well, I said NO. If his solution was chosen, then I would NOT do it. And I stuck to this. So the manager decided to talk to a few more people and slowly understood that I was right. He might have been in favor for his friend, but everyone else considered my solution the better one. (Especially after I showed people the weak spots of the other proposal.)
So I got what I wanted and that other guy was put to work on some other project. He wasn't succesful at that either and was fired after a few months again, since he just couldn't do his job properly. He made too many mistakes, yet pretended to be one of the best developers.
See, I am one of the best developers but I don't brag about it. My results just speak for me. ;-)

> f) Patents have been filed on the technology you use and no-one dares do anything with it.
Patents are also real killers but fortunately most developers don't have to worry about it. Patents are more pains for the management, which decides if some patented technique will be used or not. We developers just develop. Furthermore, patents don't add to the maintenance cost. They add to the overall cost.

> g) someone encrypted the functions file and didn't back up the original
Yeah, that's a funny one. Some collegue of mine (about 15 years ago, when backups weren't popular) had the habit of making backups of source files in password-protected ZIP files. These would then be stored on floppy disks and archived. Then this joker decided to start working somewhere else so he left. Too bad he never gave his password. Even worse, when my boss discovered that the sources were password-protected, he contacted this ex-collegue and asked him for the password. The answer? He had forgotten the password too. He had written it down in his notebook, which he had thrown away after he had quit.
It's very expensive to decrypt those files back, though. It could be done but 15 years ago the technology and knowledge about this wasn't as well-known as it is now. (This is the pre-Internet era, btw!)

Now, the number one reason? LOL. From my past experience, I would say that b is the most expensive one since I've seen an inexperienced developer at work, actually damaging a product that worked but which needed additional functionality. Because he kept failing, the product had to be delayed and delayed and customers weren't happy about it. When I was asked to repair the damage, I had to use the original, undamaged source, thus all his work became garbage. Three months of lost wages and unhappy customers...
As an experienced developer I don't mind missing documentation that much but it does slow me down a bit. Thus a is not that costly in my opinion. And if you have something that needs an old version of some language, there's no reason to stop using that old language. Or combine old languages and new languages by making the project more modular. Some companies still have to work with software that's 30 years old or even older. It works and works well so they don't fix it. But they need to integrate it into newer products so they work around the problems. Not too costly either. And programming techniques never really get obsolete. It's just that other techniques are just enhancing things. Here too, mixing the two solves a lot of problems.

Thus, if you ask me, the answer is B.
But others will think about this differently... Since it's academic, I would be suprised if your teacher agrees with me. :-)

> > e) {nationalistic remark removed - ee_ai_construct, cs admin}
> Well, conflicts and disagreements between developers also cause some losses.

That wasn't my point...

The crux of my statement was the company is using local labour and having to pay expensive rates rather than outsource to one of those companies that operate in far-flung countries with minimal overheads that offer $8/hr developers. I know of a few companies that oursource to [insert nondescript country name] most of their development and maintenance which have built very good relationships and saved thousands of [currency] per month.

I wasn't meaning to single out any particular breed of developer - quite the contrary in fact.

Mike

Ja, easy mistake...

bedtime!

(Redo from e)

> e) using local labour and having to pay expensive rates
This is a correct point too. Indeed, quite a few companies prefer to outsource their projects to countries where the labout is a lot cheaper than it is here. Especially companies who don't want to spend much on software development in the first place. Then again, there are quite a few countries who don't even have a software development team because maintaining such a team is quite expensive.
I happen to work for a company that develops software for other companies. Basically I am one of those to whom projects are outsourced too. But I ain't cheap either. (About $150 to $200 per hour.) But I can easily compete with those $8/hr developers since I've been more specialized in certain areas.
Still, if all a company needs is a very simple application with a few screens that communicates with a database and doesn't do anything special then it's similat to companies who have shoe factories in those same countries. For generic purposes and standard running shoes, those cheap-labor countries are quite useful. For more specialized projects and custom-made shoes, you will need a more specialized developer, though. And the more specialized your needs are, the more expensive things get.
And I must say that I would feel quite stupid if all I have to do is just create simple screens where users can enter or view data. I would feel heavily overpaid in that case. I'm a professional developer, not a typing monkey! ;-) [I used to be a typing monkey once, though, when I was less experienced and there's nothing wrong with that. Just don't stay a typing monkey is my motto.]
Outsourcing to cheap-labor-countries is one way to reduce the costs but you have to be aware that the people who will be working on it will be less experienced too. They will learn and become smarter though. ut when they learn, their prices will rise too. And there are risks that while you're negotiating with cheap laborers in a foreign country, those same laborers might just be collecting your money without returning any of value in return. As a result, you could end up being cheated by them and then you have to think if it's worth to contact the foreign authority, file a complaint and make more expenses in the hope of getting anything back...
If your developers are located in the same country, it becomes a lot easier to take legal actions if they don't uphold their end of the bargain. So, outsourcing is cheaper but comes at a higher risk.