Should I tell my team / manager that the current mobile application is bad?

Question

Some background information: I recently got my first full-time job as a Junior Mobile Developer (23 years old).

I have been working in this industry for the last 4-5 years either as a freelancer or on a part-time contract. My current company gave me the junior position although they did admit that I should be in a higher position (medior/senior) based on the results from the technical assignment that they gave me.

This company recently entered the mobile market and it only has a few mobile developers. Most of the mobile developers are either old or work at the company for years and recently stepped over to mobile development. A few days ago I had to work together with my team on adding new features to an app that they have been working on for the last 2,5 years.

When I saw the code and the design of this app I was shocked - the code violates nearly all programming rules, it's full with errors and the UI design violates all rules from Apple and Android. I couldn't believe that it took 2,5 years to make this app - that's why I decided to recreate the app in my private time from scratch - this took me 2/3 weeks and it was done.

My question is: Should I mention that the application lacks in UI-design and code quality? If so, to whom? The project manager isn't aware of the code quality and the hidden errors. I don't want to put my team in an awkward position and bash on their work but I also don't want to do their dirty work which they will then claim as their own. I find difficult to mention anything to anyone since i'm new and a junior in this company.

Basically:

• If I tell the manager that the app is lacking it will reflect bad on the team.
• If I tell the team they most likely will take my work or use the knowledge I shared and make it their own.
• If I don't say anything I don't see a way to grow in the company and show my skills. I'll end up doing their work which they will take credit for. This has already happened once.

Answer 1

I think saying something is a good idea but how you say it is going to be just as important as what you say.

As you wrote in your question you don't want to bash your team (which is excellent) and I'm sure you won't go in and just say "the app sucks, look at my version which is awesome and I knocked it up in a couple of weeks" but you really want to avoid taking any approach that could be interpreted as saying that.

You need to bear in mind that there a couple of big potential factors and challenges that could have contributed to the existing app taking as long as it has to develop and functioning and looking the way that it does, many of which you will not have faced in your re-write:

1. Experience - it sounds like you have prior experience with mobile app development and it sounds as though that wasn't the case for the developers who wrote the existing one. I've written may fair share of not-great code over the years that I know if I went back and did them again now I'd knock it out of the park.

2. Stakeholders - You had none, you were working in a vacuum and only answering to yourself whereas the original developers will likely have been working to the requirements and preferences of the people driving the project. That horrible UI you hate? It probably is horrible - but it's horribleness could easily have been insisted on by stakeholder and product owner (you should see some of the utter abominations I've had to produce over the years because the PO or a director liked it that way). Same with functional requirements - you knew a full feature set from the start as you had an existing complete app to work from. The original developement process will most likely have been as much about figuring out what they wanted it to do as much as making it do it.

Basically you need to cut them some slack and give them the benefit of the doubt that they were doing the best they could under more difficult circumstances then you faced and bear that in mind during the conversation.

So how do you approach it?

In a word - humbly, I would set up a 1-1 meeting with your manager and explain that after looking at the existing app during the recent work you felt it would be a useful exercise to have go at recreating it on your own time (make sure you stress this part - you don't want to be seen as neglecting your assigned work) as a way of improving your own mobile app development skills and that you'd like to have your manager take a look to see what they think and get some feedback. If your version is as a big an improvement as you say (and I have no reason to doubt you) then this will speak for itself when they use it and look at the code. If they comment on the UI differences say that this how you would have done it given free reign and that you understand that it isn't necessarily going to be in alignment with how the business might want their app to look and feel. If they comment on the code difference say that you were working in the way that you have been taught but that you are open to any suggestions as to how it could be better.

Please note I'm not suggesting your version is worse than the existing one - you make a pretty good case as to yours being better and I have no reason to doubt you. This humility is essentially a way of avoiding coming across as arrogant - which is not a good look, especially when you don't have the track record in the company yet to back it up.

Answer 2

Don't call them out, which is what you would be doing. Ask questions instead.

"Why is the UI like this? Wouldn't be more standard to do ____?"

"I bet we could get a lot more stable code if we did _____ "

The sad fact though is that you're 23. 4-5 years might seem like a lot to you, but it's really not when you consider some of us have been doing it for over 30. Since you're only 23, your ideas are more likely to be dismissed. That's why I'm suggesting the humble suggestion approach. Phrase questions in a way that forces them to explain it without challenging really or being confrontational.

Answer 3

Should I mention that the application lacks in UI-design and code quality? If so, to whom?

I think that you should address this with your manager. You were hired as as Mobile Developer, so part of your responsibilities is to care, improve, and warn about any mobile project you may have.

You may think this will reflect bad on the team, but the drawbacks of not calling this out this sooner will be worse on the long run. Just be sure to have alternatives and solutions ready when saying what things could be improved (which seems you already have).

that's why I decided to recreate the app in my private time from scratch - this took me 2/3 weeks and it was done.

This may be useful for you here, so you can take the credit you deserve for your work while helping build a better app altogether. Even though what you say where completely true, chances are that for 2,5y there may be some complex aspects that you missed, so be open for corrections and changes as well.

I must say that this was a crazy bold move for you to do, but if you actually did it right then you can surely work this out to your favor. I suggest you meet with your manager in person, where you can present your worries about the current version of the app and the solution and practices you propose.

For this I suggest you phrase your suggestions carefully. Instead of saying "I think using X is bad, and we should be using Y", try phrasing it like:"I see we do X in this part of the code, could you explain the benefits of doing so?" ... this way you are not pointing fingers, you are maintaining a learning attitude, as well as allowing you to effectively make your suggestions despite your "Junior" condition.

You can then mention that you have been working on a project during your own time as a proof-of-concept, and proceed to show your app. If what you describe is true your manager will most surely be impressed and probably take into consideration the changes you propose.

The good thing is that the "drawbacks" are minimized here as you already took the time to research and code those alternatives. Just be sure you make sure they get you did this on your own time (thus not "wasting" company time). Hope you can sort this out to your favor.

Answer 4

It is a conundrum.

Being fair, you may have not fully grasped the whole or smaller important aspects of the code, given the time taken to produce it. Or you could simply be better than the rest of your team. Taking you at your word, you have created a potential solution by re doing it, but you have also highlighted two serious internal problems, outdated, unimaginative or uniformed developers and a manager who didn’t know that for two and a half years....

Your approach here is critical to your longevity with this firm.

I would recommend you hope for the best but plan for the worst. Go through the code at work over the next two weeks for things you may have missed. meanwhile in your off time cover your a$$. Document everything being worked on from your home computers, screen shots, anything and everything, just in case for the legal worst case scenario. Go through your new and improved app and test every aspect that you can, double triple check everything.

Two weeks from now make the final move. Make an appointment to talk with your manager. Show them your app next to the current offering. Wow him. Bedazzle him. Blow him away with your cool new UI design and code stability.

Offer to give him the code completely, free and clear. You will give him full glory for all the changes. In return you will kindly accept the promotion to senior developer with it’s corresponding bump in pay. After which you will prove with your continued hard work, his faith in you. Not only that but if it’s required, you will gladly sign any agreement to that effect.

Check mate

Go big or go home. There is a high chance if you just give it to them, that they will steal it and sack you to simply cover up the huge “problems” you have potentialy revealed. Or they could think you too cocky and sack you. If they do, walk away content that at your age you can out code them. Your next opportunity will always be there if you keep upping your game.

It’s a gamble either way. Best of luck.

T

Answer 5

I'd recommend that you start with the end in mind — what's the outcome you want to see? Reading your question, I'm guessing it looks something like:

• A better UI which more closely adheres to UI guidelines for the mobile platforms involved
• A more well-structured codebase with less cruft and more recognizable architectural patterns
• Recognition of your impact on getting to these

Regardless of whether that's the full list, the real challenge here is change management, aka how to get from the state you, the team, and the app are in now, to the state you want to be in. To do that, you've got to:

• Identify "key stakeholders": who will most benefit by the future you're seeking? Who is going to suffer the most change? Who is going to care the most, regardless of whether they're in those other two groups? These are the folks you need on your side when it's time to propose changes, and when it's time to start implementing them.
• Understand your stakeholders and your business better: you probably know a lot about your space, and mobile development. Learn more about your team, how they came to be who they are and where they are, and your codebase. Is it Java-Oriented Objective C because that's the paradigm they had, or because the first person who built it went fast and no one ever had time to rewrite it? How's test coverage, and can you make it better? Having this understanding will be invaluable when it's time to make a plan for the changes you want, and the process of getting it will build the relationships you'll need to deliver it.
• Create a common understanding and a shared appetite for the change: start talking with those folks, and others, about the future state you're hoping for. It doesn't have to be immediately relative to your app; in fact, it's often better to start in areas that are clearly disconnected from it to avoid building concerns and defensive reactions. For example, you could spend some time on a regular basis deconstructing and discussing some other app that you think is really well done, particularly around aspects you think would be applicable to your own app. It's not important to end those conversations with, "... so we should do that, too." You're exploring together, and you'll jointly come to value the things that are most important.
• Start small, build momentum: Don't propose a two year plan to turn over the entire codebase, nor a "stop the world while we rewrite" project. Instead, look for a series of changes that you can approach to evolve the app towards a better future while continuing feature development. Pick small things that have large positive effects and tackle them first, if you can; they will both help you test your direction as well as give you momentum by delivering successes. Maybe the most important starting points are some small refactorings that make it easier to deliver some important features well; maybe it's the rearchitecture of a chunk of the app to a better footing so it doesn't break as often (because it's easier to test well, right? ;) Whatever it is, make them small and incremental so you're not asking your team and your boss to take on large risk to get to that excellent future you see.

You're going to walk into this situation over and over again in the course of your career. Building strong change management skills — the skills to deliver change in ways that empower the team and the company, and that builds morale and relationships rather than tearing them down — is enormously valuable and will take you farther than nearly any technical skills you can develop.

Good luck!

Answer 6

Technical debt

https://www.techopedia.com/definition/27913/technical-debt

Once a business falls into the technical debt category they can find themselves in a difficult situation. It's a very common problem and it can be made worse by politics, processes and shortterm goals.

Technical debt is unavoidable. The key is to manage it.

• write unit tests
• use code coverage tools to monitor code changes
• use source code linting tools
• track the frequency of bugs (indicator of technical debt)

Unless everyone starts working together to resolve technical debt issues. Nothing you do as a programmer has a hope of fixing the causes. You could rewrite it, redesign it, refactor it or just smash it with a hammer.

Technical debt will quickly crawl it's way back into the source code.

I would go to your manager, and have this kind of conversation with him.

Hi, I've been here only a short amount of time. In that amount of time I've found that adding new features, fixing bugs and following your custom approaches to UI design are taking a lot longer than I feel they should. While I lack the experience to pinpoint exactly why this is the case. It's making me feel uncomfortable. Were you aware that we have technical debt problems here?

He will either know it's there, or he'll look into the problem. The key is to just start a friendly conversation about it, and avoid any accusations of cause and effect. You basically feel it's there, but you don't know where exactly.

Keep bring up the topic. That's about all you can do.

It should be the role of a senior developer to ensure unit tests, code coverage, source code linting and other analytical practises are being followed. All you can do is advocate that you need them.

Encourage people to talk more openly about technical debt. Ask around what each person thinks it is. Try to start conversations about it.

But, always be friendly, listen to others and don't challenge what they say and hopefully overtime you'll come together as a team to battle that debt.