As an intern, how do I approach the team regarding improving code quality?

Question

I am a Software Engineering intern at a big company.

Few weeks back, I was given a simple task to do, imitating the behavior of another component.

Reading the code, I found the current implementation rather flawed. It was introducing tight coupling between components, and the effort put on it looked rather redundant: additions to the codebase would result in duplication of work.

I came up with an alternative solution, using a different library, which would extremely reduce future repetition, at its own costs:

1. Nobody else knows how to work with it, so I am pretty much on my own.
2. It is not implemented elsewhere within the team, so I have to "decide" the best practices on my own.
3. Most importantly, unexpected problems are coming up every now and then, which are delaying the supposed "3-day work".

I'm pretty much sure this implementation would save months of developer effort, but I also feel bad delaying the 3 days' work (though we don't seem to be having hard client deadline on us).

How do I approach my team about improving the code quality? I want to make this work, but make sure I've considered the rest of the team.

Answer 1

You really need to ask your team and/or manager.

Your team members have to decide if the improvement is worth the effort to understand and maintain the new library.

As a rule of thumb, if you're the only one who can maintain your code (for whatever reason, good or bad) you're not making things better.

It sounds like you've found a good fix. I hope you can convince your team.

@Brandin suggested you complete the task as assigned first, then push for the new library as a separate project. This makes a lot of sense - it will buy you some credibility and make it easier for others to believe in your suggestions.

As for 'how can an intern convince the team to try something new', I was sure there was another question for that either here or on Programmers.SE (where it would now be off topic) but I haven't found one.

The short answer is to earn some credibility as @Brandin suggested then offer up the suggestion in a way that recognizes the previous work and experience of the team.

Answer 2

Reading the code, I found the current implementation rather flawed

Whenever you look at another code base, it's easy to overlook the simple fact that what you are looking at probably was never actually "supposed" to look the way it does. Probably no one sat down and designed it to have tight coupling and lots of "redundant" repetition (more about this below).

Rather, when the code was first written, likely it was planned and executed along best practice lines, following a simple, clean design. What you are looking at could be the result of multiple changes and patches designed to account for the change in requirements which naturally occur to any enterprise component.

Addressing your specific concerns, tight coupling on it's own isn't necessarily a bad thing. In certain situations you would expect, even prefer, certain components to be tightly coupled. For example, if a component is only ever going to be called by another component, then there is no need to address this coupling as an ongoing concern.

Redundant or repeating code is also not necessarily bad, and in fact, reducing redundancy by promoting re-use of components tends to increase coupling, rather than decrease it. DRY (don't repeat yourself) is just a principal, and can be countered in many places by WET (write everything twice).

I'm not saying that this stuff definitely applies to your situation, and for a new component you don't necessarily want to ape the failures of an old one. However, I would suspect there is a risk you are attempting to improve something which you don't fully understand, and if you do approach your team with it be very careful about expressing your opinions on the current state of the code if you don't fully understand and own the business process or function which the code is designed to support.