Joined devRant on 9/12/2017
Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
I remember my colleague who was DevOps guy (15+ years exp) in our one very good project about kids' edutainment.
He always breaks things & blames others when only he had admin access of the tool.
When client was very much interested in Android app, our that DevOps focusing totally on REST API & ignored Android app related DevOps tasks.
Our Android CI/CD was not complete till project ended. Due to his stubborn nature we couldn't take benifit of automation testing.
You can't tell him how to do any task, if you tell then it will be taken by him as an insult to his intelligence.
He would waste his 2 business weeks to find a way to do that task, then he would do some frugal trick half heartedly then he will leave it. Still he wouldn't accept your help due to his ego & he would work on tasks which he likes even though they are of low priority.
He was hellbent on cost cutting so he reduced caching availability to save extra billing, now we couldn't had enough speed for even 10 users to show recommendation feed by API.
Due to this our client couldn't show demo to angel investors properly & didn't get funding.
I don't how with such a bad attitude, he could survive so long.
He had plenty of training certificates (Salesforce etc.) with very little practical knowledge.
God save people of his current & future projects.2
Some magic happened about situation talked in earlier rant at below link.
Now magically even before I inform about this situation directly to the client, now after 8 years they used some proprietary static code analyzer on latest app source & found out around 200+ security issues which covers most pain points I told in the above rant.
I also found out that there is a list of 100+ vulnerabilities documented in client doc repo, which were pending since around 5-6 years.
Now I have to work along my junior to fix these both kind of issues.
Suddenly dull maintenance project became much challenging & interesting. :-)
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.10
Recently joined new Android app (product) based project & got source code of existing prod app version.
Product source code must be easy to understand so that it could be supported for long term. In contrast to that, existing source structure is much difficult to understand.
Package structure is flat only 3 packages ui, service, utils. No module based grouped classes.
No memory release is done. So on each screen launch new memory leaks keep going on & on.
Too much duplication of code. Some lazy developer in the past had not even made wrappers to avoid direct usage of core classes like Shared Preference etc. So at each place same 4-5 lines were written.
Too much if-else ladders (4-5 blocks) & unnecessary repetitions of outer if condition in inner if condition. It looks like the owner of this nested if block implementation has trust issues, like that person thought computer 'forgets' about outer if when inside inner if.
Too much misuse of broadcast receiver to track activities' state in the era of activity, apપ life cycle related Android library.
Sometimes I think why people waste soooo... much efforts in the wrong direction & why can't just use library?!!
These things are found without even deep diving into the code, I don't know how much horrific things may come out of the closet.
This same app is being used by many companies in many different fields like banking, finance, insurance, govt. agencies etc.
Sometimes I surprise how this source passed review & reached the production.1
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” - Martin Fowler
Source : @codewisdom, twitter5
We had 1 Android app to be developed for charity org for data collection for ground water level increase competition among villages.
Initial scope was very small & feasible. Around 10 forms with 3-4 fields in each to be developed in 2 months (1 for dev, 1 for testing). There was a prod version which had similar forms with no validations etc.
We had received prod source, which was total junk. No KT was given.
In existing source, spelling mistakes were there in the era of spell/grammar checking tools.
There were rural names of classes, variables in regional language in English letters & that regional language is somewhat known to some developers but even they don't know those rural names' meanings. This costed us at great length in visualizing data flow between entities. Even Google translate wasn't reliable for this language due to low Internet penetration in that language region.
OOP wasn't followed, so at 10 places exact same code exists. If error or bug needed to be fixed it had to be fixed at all those 10 places.
No foreign key relationships was there in database while actually there were logical relations among different entites.
No created, updated timestamps in records at app side to have audit trail.
Small part of that existing source was quite good with Fragments, MVP etc. while other part was ancient Activities with business logic.
We have to support Android 4.0 to 9.0 of many screen sizes & resolutions without any target devices issued to us by the client.
Then Corona lockdown happened & during that suddenly client side professionals became over efficient.
Client started adding requirements like very complex validation which has inter-entity dependencies. Then they started filing bugs from prod version on us.
Let's come to the developers' expertise,
2 developers with 8+ years of experience & they're not knowing how to resolve conflicts in git merge which were created by them only due to not following git best practice for coding like only appending new implementation in existing classes for easy auto merge etc.
They are thinking like handling click events is called development.
They don't want to think about OOP, well structured code. They don't want to re-use code mostly & when they copy paste, they think it's called re-use.
They wanted to follow old school Java development in memory scarce Android app life cycle in end user phone. They don't understand memory leaks, even though it's pin pointed by memory leak detection tools (Leak canary etc.).
Now 3.5 months are over, that competition was called off for this year due to Corona & development is still ongoing.
We are nowhere close to completion even for initial internal QA round.
On top of this, nothing is billable so it's like financial suicide.
Remember whatever said here is only 10% of what is faced.
- An Engineering lead in a half billion dollar company.7