suggesting large changes/a rewrite as an intern

Question

The context:

• it's an internal project (that I don't think a lot of people use)
• it's old
• we're updating it

The issues:

1. it abuses the mvc framework (no use of models, business logic in views, etc)
2. what we're being asked to do is small, but because of the low cohesion we have two options:
   1. continue to botch things
   2. move large chunks of code around or rewrite the thing

The solutions (I see):

1. continue working with it, ignore best practices in favor of being done soon and not introducing new bugs by refactoring/rewriting
2. refactor/rewrite

I guess my question is really: if I want to make large changes to this project, how do I do propose that without insulting anyone? Or would it be better for me to simply go with the flow even if that means (metaphorical) duct-tape sometimes?

Answer 1

Propose your changes. Be clear on the business case for each: Why will your proposed change help the system as a whole? If it doesn't, expect push back. Why spend money fixing something that ain't broke? Reasons such as making the system more extensible and separations of concern may be valid (depending on who you're talking to), but 99% of the time, just saying "it's not implemented correctly" will get you nowhere. Make sure that you're adding value to the project and not just proposing make work (even if it does clean up the code).

Unfortunately, in the professional world, just because something's been implemented wrong doesn't mean that it's broken, and therefore in no need of fixing. Also, in fixing it, you may introduce unforeseen knock-on issues that could impact other areas of the project.

Answer 2

Reading your question, I'm actually skeptical that rewriting the application is worth it. Maybe you didn't bother to make the full case in your question. But how likely is it that the benefit of rewriting is worth the cost if it's an old, rarely used, internal application? The cost of a rewrite is likely to be more than the sum of all the updates and patches it will ever have.

If you think that's not true you will need to make more of a case for it than you did here.

As for improving the application, you might have some chance for a little bit of refactoring that happens naturally in the course of your updates.

Answer 3

You're an intern. Presumably, you're brand new. They probably suspect you for an idiot.

So as you go about making suggestions, tread lightly. Be humble and unassuming. Let your ideas flow conversationally as you allow other members to also discuss their own ideas about the codebase and what pressures they may be under (there could be very good reason why an effort hasn't been made to clean things up).

You want to earn their trust. You do this by writing good code for the tasks you are given. Write it cleanly, use the best practices that you would like to see implemented, but only on what you are assigned to do. These will probably be small things, things that the rest of the team probably thinks are insignificant. Do those things well. Brighten the corner where you are, and as the team comes to review your code favorably, your ideas will in turn also grow in stature.

Eventually, as you demonstrate your competency and knowledge, you may be able to pull off a suggestion or two.

Answer 4

OK Here goes.

You think the application is badly structured and badly written.

The customer thinks it does the job.

You want to rewrite it for no other reason than to improve its "internal beauty".

So you are asking the customer to spend money on getting the application to do exactly what it does now -- only the parts the user does not see or understand will be somehow "better".

The main objection to badly written badly structured code is that it is hard to understand.

The code is hard to understand and has functionality and features that can only be easily implemented in a badly structured application. So unless you are very very good at this the new application won't do exactly what the current application does, and, because you did not fully understand what the original code was doing it will probably be doing it wrong.

So your customer now has spent a lot of money to get an application that is markedly worse than the original application. You are not going to be popular!

Luckily your more experienced colleges are prepared to humor you (probably because they made the same mistake when they were starting out, and, may even have had the misfortune to get management approval for such an ill fated project).

So my advice would be to keep the old code base running, and, keep quiet. The customer just wants a system that works they do not really care if you think the code is ugly.

Answer 5

I would totally make this suggestion, but only to a fellow developer. I would not bring it up with management, as I would imagine management would see that as some type of overstepping of boundaries.

After making the suggestion to a developer you're working with, they'll probably have some good reasons for how the codebase is why it is. The reasons could range from "no, actually the code is fine, you just don't understand MVC (and that's why you're an intern)" to "that's a great idea, let's architect the new application together!"

Keep in mind that the answer to refactoring this application will more than likely be no; I would never want an intern taking over the rewrite of an internal application (what happens when your internship is done and the rewrite is only half-finished?) Plus, there's probably more important stuff you could be working on than poking around an internal application.

But it never hurts to ask your peers, and if you do, you will learn something. And that, 7983879342, is what an internship is all about.

Answer 6

Whatever happens, I hope you take the following message away. As some of the responses above have pointed out sometimes a code re-write, for the best of technical reasons is sometimes infeasible for business/cost reasons. Too many programmers live in the technical solution and refuse to consider that their, personal, quest for technical elegance/readability/best practice should be balanced by the business' needs to get things done. In my personal experience the guy that does not strike that balance (from either direction) is often viewed as a liability within the team.

Don't stop questionning things though, even if you get some knockbacks, its the way we learn and grow.

Answer 7

Other answers have spoken a lot about the politics of your situation, and I tend to agree. Unless you can present a compelling business case, a re-write is probably not on the cards.

However, that does not mean that you should forget the Boy Scout Rule:

Always leave the campground cleaner than you found it.

If while you are implementing something on this codebase, you can work out a way to clean up some aspect of the design or implementation, then that is something you should consider. You probably don't need to re-write the whole application to make better use of the MVC model, and if you are implementing some new business logic for a particular view, you could consider moving the logic out of the old view into the model and adding your new logic to that.

Answer 8

As others have stated, ask another developer (one familiar with this application) to do a quick walkthrough just so you can understand the how/why of the implementation. Explain that while you can understand the technological aspects, but you want to be able to connect the dots to the business requirements (business requirements trumps all).

Once you have this information, you can then make your evaluation. If you personally think that it should be re-written, but don't think others will see it as a good use of time, take it on as a personal project. Even if it's an hour here/there when you have downtime, do the implementation "correctly". Once you finish, present it to the other developer(s) as a "hey, I felt like this could use some clean up, so i did some side-work during my downtime. what do you think?" Don't press the change on them - just offer it to them as a "hey, you guys like this?" and go from there.

Answer 9

Most changes happen incrementally, as a general rule.

A few things to keep in mind;

• What is the history of the application?
• Why is it ugly today?
• What is the benefit of the architectural changes?

A good strategy is to work on the small things and ask a ton of questions about stuff (questions you can't learn from Google or the source, don't waste people's time). After you feel comfortable with the code base and the developers, you should have a good feel for why the code is the way it is. Sometimes, it's just, "Yeah, we had to hack something together and shove it out the door". If you can propose mild changes to small parts of the system that occur as you go along in your normal work, that will get more traction than radical rewrites.

Answer 10

There's no hurt in suggesting a rewrite if you ask nicely and make a logical case (not just a hunch or its the better way to do it). There's a high chance that rewriting a low-use application will be shot down, and there's a good chance that whoever originally wrote the system is still around (and higher in the hierarchy than you) and may not take kindly to criticism.

So don't say "We need to rewrite this horribly designed system that violates basic MVC principles", ask it as an open question to the appropriate higher-ups (people directly above you). Something like "I'm wondering if rewriting the system in the MVC model might save a lot of time in the long run. What do you think? I bet we could halve the maintenance time with a major rewrite (in say 2 weeks) that incorporates MVC model, TDD, etc. was done and that after two months of routine maintenance we'll break even". The response may be, no we don't think that's called for -- I disagree with your time estimates and the likelihood the new system will be a suitable replacement. Or the response could be, fine go for it, but remember if your new system doesn't work as good/better than the new system in the time frame you proposed that people will blame you. And even if the system is little used; it may not be acceptable to stop updating it with minor fixes during the rewrite period.