11

I need guidance about my current situation.
I am perfectionist believing in OOP, preventing memory leak in advance, following clean code, best practices, constantly learning about new libraries to reduce custom implementation & improve efficiency.
So even a single bad variable name can trigger my nerves.

I am currently working in a half billion $ IT service company on a maintenance project of 8 year old Android app of security domain product of 1 of the top enterprise company of the world, which sold it to the many leading companies in the world in Govt service, banking, insurance sectors.

It's code quality is such a bad that I get panic attacks & nightmares daily.

Issues are like
- No apk obfuscation, source's everything is openbook, anybody can just unzip apk & open it in Android Studio to see the source.
- logs everywhere about method name invoked,
- static IV & salt for encryption.
- thousands of line code in God classes.
- Irrelevant method names compared to it's functionality.
- Even single item having list takes 2-3 seconds to load
- Lag in navigation between different features' screens.
- For even single thing like different dimension values for different density whole 100+ lines separate layout files for 6 types of densities are written.
- No modularized packages, every class is in single package & there are around 100+ classes.

Owner of the code, my team lead, is too terrified to change even single thing as he don't have coding maturity & no understanding of memory leak, clean code, OOP, in short typical IT 'service' company mentality.

Client is ill-informed or cost-cutting centric so no code review done by them in 8 years.

Feeling much frustrated as I can see it's like a bomb is waiting to blast anytime when some blackhat cracker will take advantage of this.

Need suggestions about this to tackle the situation.

Comments
  • 8
    Hire an external security company to do an audit and paint the worst case scenario with big lawsuits and money loss.

    Convince customer to do a rewrite.
  • 0
    @heyheni actually there are client side security auditors with big experience but may be knowing Java only & not knowing Android basics or may be don't want to increase their headache as too large & too many changes are needed.

    Highlighted same issues orally in my team but nobody wants to work on tasks which are not given by client.
  • 7
    Difficult situation. Clients usually will not pay for anything like refactoring that doesn't produce tangible value. Security can be different, but that should have been in there from the beginning, so the client won't pay a second time just so that the company does the job right now.

    The only route I see is to convince the management of your company that negligence has cut cost to the point of having ruined the technical product basis - introduce them to the concept of "tech debt".

    They will have to invest a lot of money if they want the product to have a place in the future. Which isn't guaranteed, maybe it's being phased out anyway.

    If they are not willing to invest, and if the product is vital to the company, look for another job. After the first security breach, the company will be bankrupt anyway.

    Btw, the "devrant" tag is only for stuff related to devrant.com itself - not for "developer rant". Since there are only devs here, every rant is supposed to be a developer rant.
  • 2
    @vatsalengg are you familiar with the concept of opportunity cost?
    https://en.wikipedia.org/wiki/...

    It's basically missed profits because of negligence. Use this to your advantage.
  • 2
    @Fast-Nop earlier this maintenance project was with some other company & this product was initially an in-house development of our that client, an IT enterprise company.

    About techdebt that enterprise company itself should understand as source repo is still under their control.

    I am quite surprised as code is never really reviewed with any seriousness in whole 8 years. No excuse can justify this.

    To avoid rework in new features or change requests, I had suggested best practices to my team when I had recently joined this project, but project lead don't want to follow it. He is just interested in visible things like UI only to impress client.

    They don't want to do even memory profiling to find high memory usage or leak which I can already see due to Android anti-patterns used in new implementations also.

    Sorry about devrant tag, didn't know it's for devrant.com only.
  • 6
    Enterprise IT service companies are generally lowest common denominator. If you care about quality, enteprise is the worst place to be.

    You might also improve your life by being a little less theological in your approach. OOP is just one paradigm, clean code is mostly marketing with a little common sense, memorizing lots of library featuresets spreads your time thin and prevents you from going deep. Focus on engineering principles bottom up and the rest will follow.
  • 0
    @heyheni I have tried 2-3 times by sending mails to project lead with highlighting these issues but he ignores.
    Project lead is having very good relations with manager & I am just a month old in this 2-3 years old team. This way also I can't do anything.

    Now I see only one way as making long term improvements list & keep it in backlog somewhere so that by chance in future somebody from client side higher management find out it.
  • 0
    @SortOfTested I am also not in favor of working in service company, but till now in my life I have worked on our client product companies' projects to build a product from scratch, including in this company. This is the 1st incident of this kind in my experience.

    I don't overuse OOP, I use it only where it's logical to do so, helps to reduce efforts, redundancy, gives re-usability benefits etc.

    Clean code name is given to attract people who generally don't apply common sense in coding due to some reasons.

    About libraries, I think we shouldn't re-invent the wheel when it's open-source, free to use in commercial product by proper license, have long history of improvements, fixes, dedicated team to fix library specific bugs etc.

    It's basic principle as 'less is more', less custom code will give you more time to focus on your business logic than common trivial tasks which libraries already do efficiently.
  • 1
    Tackle your perfectionism instead. There is no need to make it all religious
  • 0
    Well dont change anything. Continue your good practices in new development
Add Comment