Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am currently on a paid internship, and have been tasked with maintaining an obsolete system that has been developed by multiple developers (at different times) over the course of the past 5 years. Management agrees the "system is on life support", and I receive a fairly regular supply of bug reports from end users currently using the system.

Management now wants to extend the project for another year, and in the process nearly triple the user base.

As an intern (or any entry level position) how do I "push back"? I've already written a report stating my concerns, albeit in an open-ended document. Is there protocol or document type for suggesting changes? Am I in a position to make suggestions, or should I simply continue to support the old system?

  • To clarify, software development is not my company's primary business. As such no internal protocols exist. Additionally, the project has no formal documentation at all, and no requirements documents either. The development is very ad hoc.
share|improve this question
6  
I sympathize with your problem. Sadly, there is no easy way around this and I am sure your question has been asked before in many different ways. One thing I would recommend is to avoid writing a report with "open-ended" concerns. Managers (especially non-technical ones) HATE that whether they say it outright or not. If you complain about something, you have to make concrete and practical recommendations for making it better. –  Angelo Nov 2 '11 at 13:24
3  
@James, the format of the document, in your context, is totally irrelevant. What matters is that you 1) identify the changes you need to make, 2) describe a concrete plan for implementing them, and 3) persuade those involved to agree to the plan. In an environment where things are "ad-hoc" formal document structure means nothing. –  Angelo Nov 2 '11 at 13:57
7  
Unless there's a replacement system under active development, I'd argue that the current one is not "on life support". Especially if the company includes it in future plans. –  TMN Nov 2 '11 at 14:08
7  
Since when is a 5-year old system "legacy"? –  Marjan Venema Nov 2 '11 at 14:13
1  
@James - That's not the definition of a legacy system. Legacy is defined by there being a (clearly) newer or more efficient technology available, not the failure of internal processes or staff retention. –  Jon Hopkins Nov 2 '11 at 17:26
show 9 more comments

8 Answers

up vote 22 down vote accepted

I am currently on a paid internship, and have been tasked with maintaining an obsolete system that has been developed by multiple developers (at different times) over the course of the past 5 years. Management agrees the "system is on life support", and I receive a fairly regular supply of bug reports from end users currently using the system.

The system isn't obsolete if people are still using it and it's supporting the business activities. Since it's still being used, the business can't just throw it away - it needs to be supported until the need for the system no longer exists. That could be a change in business objectives or a new system has been developed, tested, and deployed successfully to the end users.

Really, 5 years isn't that long. I've worked with code that was 10 years old before. If it's still serving the needs of the user, why throw it away? That's throwing away a lot of money spent to develop it. Until it becomes unfeasible to maintain due to increasing costs or the requirements change drastically, there's no business reason to throw it away.

Management now wants to extend the project for another year, and in the process nearly triple the user base.

If management says that this system is "on life support", why are they trying to deploy it further? It's common that maintenance activities continue on a legacy system until it's replaced, but if a system is in end-of-life, it's not typically deployed to more people. Extending maintenance is one thing, but adding users who rely on the system is a different situation all together.

To me, it sounds like it's not actually end of life, but rather in a maintenance phase and will continue to be there until the system no longer serves the needs of the users.

As an intern (or any entry level position) how do I "push back"? I've already written a report stating my concerns, albeit in an open-ended document. Is there protocol or document type for suggesting changes? Am I in a position to make suggestions, or should I simply continue to support the old system?

You need to continue to support the old system. Later, you mention that software is not your company's primary business. In such an environment, the job of software teams is to support the company's primary business. However, the software teams also need to keep the business objectives in mind.

In the mean time, capture your suggestions in a way that isn't overbearing. Point out other technologies or techniques that could be integrated with the system or used if/when a new system is created and their pros/cons. How you do this depends on the company, but considering some later points, perhaps establishing a wiki or other collaborative site would be useful.

In a non-software business, software is a cost and the software teams (especially the software project/program managers) should be working to minimize the cost of building and maintaining software systems as much as possible, while supporting the needs of the end users. Throwing away software that (as far as I can tell, from your post, anyway) meets the needs of the users goes against what's in the best interests of the software team.

*To clarify, software development is not my company's primary business. As such no internal protocols exist. Additionally, the project has no formal documentation at all, no requirements documents. The development is very ad hoc.

To me, this is the problem. Not producing documentation, not developing to a specification, and a lack of consistency tends to increase the cost of developing software. Working toward fixing this would be my highest priority, and I would do that by working on things like a coding standard, version control, producing self-documenting code and design documents, defect tracking, and requirements specifications.

share|improve this answer
9  
I've worked with code that was 10 years old before How about 25 years old :) Still met the company needs and did an awesome job at what it was designed to do, despite the fact that touching the code was about as pleasant as a swim in the arctic. –  maple_shaft Nov 2 '11 at 13:32
    
@maple_shaft Nothing 25 years old. I think the oldest code I've ever seen was around 10-15 years old. It's not pleasant, but the user doesn't care about clean code. They care about using software that does what they need it to do in a way that helps their business. –  Thomas Owens Nov 2 '11 at 13:34
1  
@James Not really. If it's a software enhancement or defect that requires some changes to the existing system, that's tracked in a defect tracker, where it gets prioritized and assigned. If it's a process, methodology, or notice for a future project, that either gets captured through a feasibility project that prototypes the solution or an engineering memo. –  Thomas Owens Nov 2 '11 at 13:41
1  
I am working on a 15 year old system and it happens to be a joy. Yes, there are parts that could do with improvement, but that can be old parts or parts that were written a mere six months ago. Like with people: age is insignificant. It is the care that was taken developing the software and how much technical debt was incurred during that development, that dictates how much or how little joy you can get out of it. –  Marjan Venema Nov 2 '11 at 14:17
1  
@James The SRS is technical. If you're dealing directly with management, and software development is not their main business, then you're going to have to put it in business terms. Since there is no existing project documentation and so forth, I'd start with a business case or project plan or an options analysis for reengineering before any SRS. One thing managers and business understand is cost. A complete rewrite can be fraught with difficulty, so beware. –  Jason S Nov 2 '11 at 21:45
show 8 more comments

I've already written a report stating my concerns

Good. That is about the extent of what you can do as an intern. For future reference when writing such reports I emphasize presenting hard facts in an unbiased, professional manner that is void of emotional prejudices. You don't know who will read the report, possibly somebody who may or may not have caused some of the issues you are describing or had made decisions that led to these issues. Anything other than cold facts could be taken by such people as an affront, or an offense and will cause them to not like you and possibly not take any of it seriously.

Management now wants to extend the project for another year, and in the process nearly triple the user base

Keep in mind that business decisions like this are made because they are trying to make due with resources that they have available to them. I am certain that management is probably aware of the issues with the legacy software, and are probably aware of the user complaints, but do they have the software development resources available to deal with refactoring or a rewrite?

Most of the time they do not, especially if software is not the bread and butter of the company and quality and user satisfaction with the software will not directly affect the bottomline. Making these kinds of decisions are sometimes why being a manager sucks because you are often in a lose-lose situation no matter what you do.

maintaining an obsolete system that has been developed by multiple developers (at different times) over the course of the past 5 years

Mistakes were made throughout the project that led it to this point. Lack of solid user input or requirements, lack of proper product management and change control to manage changing requirements and needs, and lack of adequate technical resources to implement caused the problems as they exist today. I don't know if obsolete is the right word though. Is the underlying technology built on desupported frameworks and technologies, or is it just not the cutting edge or ideal technologies?

As an intern (or any entry level position) how do I "push back"?

You are in a position of least power and you are temporary at that. It doesn't matter if you are right, I wouldn't expect an intern to ever "push back" on me. I expect them to learn, discuss issues as they see them, and follow orders. That's about it. Once an order is given I expect it to be carried out to the best of their ability, because the time for discussion is over at that point.

share|improve this answer
    
Perhaps the use of the term "legacy" was incorrect. Currently the tech driving the system is VBA and classic ASP. The code base has been created by several rotating interns in the past. Wikipedia identifies a legacy system as one that is no longer understood, and that such situations occur when the system is not documented, and/or the original developers have left. Additionally, "push back" is in quotes, because I have a personal motto to "never be satisfied with mediocrity", and as such cannot stand sitting back and not voicing concerns. I feel as though I'm not being helpful –  James Nov 2 '11 at 13:35
    
@James It is good to voice concerns but do it once, do it completely, present a viable alternative and then leave it at that. If you voice out about the same issue more than once then you will be perceived as a whiner, and whiners aren't helpful. If you do not understand it, and nobody in house truly understands it technically then it is indeed legacy you are correct. –  maple_shaft Nov 2 '11 at 13:45
7  
James, it may be that you are never satisfied with mediocrity but from this interchange you are giving the impression that you are not good at the wider picture of how software supports the business and how business priorities differ to yours. –  temptar Nov 2 '11 at 13:48
2  
"Wikipedia identifies a legacy system as one that is no longer understood". Well if you understand and document it, so it is understood, then it won't be a legacy system any more. –  DJClayworth Nov 2 '11 at 16:01
2  
"never be satisfied with mediocrity" is a good motto, but it applies only to things you can control yourself. If you take a mediocre codebase and turn it into a well-documented, easy-to-maintain codebase that's excellent work that you should be proud of. –  DJClayworth Nov 2 '11 at 16:03
show 1 more comment

You're an intern. I doubt very much whether you are even remotely au fait with the day to day business imperatives as a whole and as other people have noticed, a 5 year old code base is not really that old.

Decisions about replacing legacy systems are not always technically driven; they are driven by changing business requirements. Input to those can be difficulties relating to maintaining; but at the end of the day, you need to recognise that your position does not necessarily mean you have all the available and required knowledge. I would go so far as to say you actually have very little of the required knowledge to make the call on what is the best move at present.

My advice to you is this: learn from the experience and stop assuming that your knowledge trumps that of people who have to run the business on a day to day basis.

Your job is to keep the system working, not to suggest a shiny new replacement.

It seems to me that a lot of young programmers do not realise that maintenance of older systems is a bigger part of programming work than designing shiny new systems/

share|improve this answer
    
I believe you are correct in stating that I do not understand the wider picture as I am unfamiliar with the overhead associated with internal software development. The education I have been exposed to so far as primarily dealt with formal process, or at the least where software development is the primary business –  James Nov 2 '11 at 14:18
add comment

Don't push back. The only thing you should do is voice your concerns in a clear, concise manner. The fact of the matter is that most businesses you will work at in the future will have legacy systems. Those legacy systems need to be maintained because in many cases are too expensive to replace.

In many cases you may even have the best intentions of replacing the current system with a better system, however, you may just introduce new and different bugs...when you leave the system will quickly turn into a legacy system again and the company will be in the same spot it was before. Nothing is obsolete until no longer servers its purpose or is completely incompatible with modern systems. My company has a 20+ year old system that we are just now converting to ASP.NET. The system still runs but support for the old technology is dwindling and making it work with modern web browsers is becoming increasingly more time consuming.

What you can do:

Leave Things Cleaner

When you maintain something leave it cleaner than when you started. make your fix, but also clean things up so the next time somebody needs to make a modification it is easier to understand.

Create Documentation

If lack of documentation is a problem, create documentation. When you're working on a particular part of the system document it.

Make It Less Painful

As I stated you can voice your concerns but your best off just working diligently on the system and making it better to work on for those after you. Fix bugs properly. Document. Disperse code smells. Make it better. And when you do these things, let your superiors know. Tell them that your doing X, Y and Z to improve the development process. That builds credibility and in the long run that is going to help you and your company more than anything else.

share|improve this answer
1  
One of the most important things that can be done as X, Y, or Z is to write unit tests. Having tests makes working with legacy code, which could break at any time in any way, much less stressful. –  Kevin Vermeer Nov 2 '11 at 18:46
add comment

YOU DON'T!!! This is a GREAT Opportunity!

You are an Internship to learn! This project is a real world as it gets.

You are very lucky to have it. The fact that you are unqualified is not your concern. (If\when management realized this you will have gained a whole lot)

YOU will be qualified once you are done with this internship, And that's great news.

PS: Make backups religiously, be sure ANYTHING you do can be rolled back. Start with the Issues that are "Easy fixes" But big pain points for users. Take baby steps.

share|improve this answer
    
The other thing that internships are great for is determining whether or not you want to work for a company, and (for them) whether or not they want you to work for them. This is a much better situation than if the OP had been hired as a full-time employee and was concerned about keeping the first job or leaving quickly. –  Kevin Vermeer Nov 2 '11 at 18:44
add comment

I guess, in a very theoretic sense - there is no such a thing called Legacy system. I have a very old phone (a legacy system), and these days there are good android phones (modern platforms), but my phone works and does what i need. Why should i throw that away?

All systems you call "legacy" today, were one day the state-of-the-art. It is only the time we need. Also, when there are sizable work is in place, it is not that re-doing the whole stuff again in modern platforms, means it will be automatically bug free (or pain free).

Here is what i recommend you should do:

  1. Leave away your dislike of "legacy system" first. This will make you very counter productive.

  2. Begin documenting what you now do and what you think. Albeit in a step by step way. There is just no better time to do documentation than the one where you realize you need one.

  3. Instead of trying to Push-back the furthering of "legacy system" - try to define path for it's exit smoothly. Try to see that you can convince management that newer development which can be isolated, can be done step by step in newer plat forms without breaking interoperability with old systems. Slowly (and this will be really slowly) as things evolve, the need to keep legacy system would vanish. That is the only way to say a good bye to any old system.

Dipan.

share|improve this answer
add comment

Truth is no one gives interns the work they want to do. When you are the most junior person, you get the least exciting work. How well you personally handle that says a lot to the organization as to whether they can trust you to do more the exciting work.

So here is a priceless opportunity to show that you can deliver by doing the bug fixes, that you can refactor by making each part of the code you touch a little beter, that you can create unit tests, by starting to create them for this system and that you can document by creating documentation for the next poor soul who is stuck with this system. It also gives you the opportunty to show you can deal with users effectively (to get more detail on reported bugs) and meet their needs. If the project is not now in source control, put it there and if the bugs aren't tracked in a bug tracker, then start one. These types of actions will show you know how to work professionally. All of this is far more valuable experience than just working in some fun technology doing a project that will be thrown aaway after you leave (the other things some interns get assigned to do).

Or you could take the opposite path and just bitch about how bad the project is and how cool it would be to replace it. In which case, you almost certainly won't be offered a job at that company after your internship.

share|improve this answer
add comment

You probably don't have enough information to determine if it is cost effective to go another year or not. It would be interesting to understand the company and why they are adding users. Seems like there may be some growth going on and they just can't afford to take a step back financially or under certain time constraints to build another app. Building a new app is rarely the best choice anyway. 5 years is not that old unless they built it on old technology to begin with.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.