Spider

Responding as a java/kotlin maintainer of one single large system with frequent requirement changes. what i call “high entropy” programs. Other developers have different priorities and may answer differently based on what kind of system they work in, and their answers are also valid, but you do need to care about what kind of systems they work on when you decide whether or not to follow their advice.

In my experience, if the builder of the original system didn’t care about maintainability, then it’s probably faster to rewrite it.

Of course, then you’d have to be able to tell what maintainable code looks like, which is the tricky part, but includes things like,

• Interfaces
• Dependency injection
• Avoidance of static or const functions
• Avoidance of “indirect recursion” or what I call spaghetti jank that makes class internals really hard to understand.
• Class names indicate design patterns being used. Such as “Facade”. This indicates that the original builder was doing some top-down software design in an effort to write maintainable code.
• Data has one, and only one, source of truth. A lot of refactoring pain comes from trying to align multiple sources of truth, since disgreements cause mayhem to the program state.

Bad signs:

• Oops, all concrete classes.
• Inheritance. You get one Base Class, and only one, before you should give the code the death glare. Its extremely difficult for a programmer to be able to tell a true “is a” relationship from a false one. For starters you have to have rock solid class definitions to start with. If the presence of Inheritance smells like the original builder was only using it to save time building the feature, burn it with fire! Its anti-maintainable.
• Too much organizing - you have to open 20 files to find out what one algorithm does. That’s a sign that the original builder didn’t know the difference between organizing for organizing sake and keeping code together that changes together.
• Too little organizing - the original builder shoved eveything into one God class so they could use a bunch of global variables. You’d probably have a hard time replacing a component so big. Also, it probably won’t let you replace parts of itself - this style forces you to burn down the whole thing to make a change.
• Multiple sources of truth for data: classes that keep their own copies of data as member variables are a prime example of this kind of mistake.

Most software in general has hard to detect issues after several weeks of uptime. Its something that’s fundamentally hard to test and fix. Its a big reason why “did you turn it off and on again” is such universal advice.

The three-page, handwritten document found on him suggested a motive, according to investigators. The pages expressed “ill will” towards corporate America, they said.

Why does he have a random handwritten note “found” on him? What was he planning on doing with it?

Android app dev here, i cant tell you what governments are capable of, but i can describe for you some of the complicating factors preventing them from doing this.

For one, to prevent impersonation, apps are cryptographically signed by the developer using a private key they never share with anyone (like a password), and the public key is sent to Google Play and the App Store so that they can verify the identity of the uploader. This prevents app store listings from being hijacked by rivals, competetors, hackers, pirates, foreign governments, and yes, their own government. So, any goverment cant just walk up and push a rogue update to the store.

For two, deploying app updates isn’t my job, it’s Google’s and Apple’s. In my opinion if the government wanted to hijack the supply chain, going directly to Apple or Google would be the way to do it. The narrowest group of people I can push updates to are the people who opted into alpha or beta versions. To target an individual, youd have to do it through Google or Apple.

For three, my boss barely gives me enough time and resources to meet the company’s own goals, let alone letting me clean up tech debt. The idea of a government that twists my boss’s arm to force me to work for the government instead of the shareholders is kinda funny and nonsensical. I live in the USA, where shareholders are king. I bet that even if we went full toltalitarian this would never happen because of rich people backlash. So i dont think the hacking coming from inside a company would happen. Then again, i perhaps dont work for a juicy enough place to see how a government could solve this problem, *or maybe they would be stupid enough to incur the political expense anyway.

And last, money money money. Programmers are not cheap. Designing and dedicating and selecting targets for an attack isnt cheap. Hacking into a company to steal their private key isnt cheap, and could also be expensive in a political sense if the wrong people get pissed off aboit it… If paranoia is what drives your question, then ask yourself, are you a high profile politician? A billionaire? A high profile leader of a movement like Martin Luther King Jr? Someone actually worth spending several millions of dollars on to spy on? If you’re a simple petty theif or protestor than i wouldn’t bother worrying about this.

*If you’re worred about your personal data getting taken and spied on., your bigger worry is the browser you use and what data gets stored on servers for services you use. Those are waaaaaaaay less expensive to get into.

Tl;dr

So basically, id only worry about relying on apps owned by the government. Or the services you use that take your data to sell it to advertisers, because theyll give it to the government directly as well.

It’s one of those pads you put on top to keep dirt from getting in between the keys

Stack Overflow isn’t a tutor site. It’s a wiki. Its usefulness would plummet if duplicate questions are allowed, since that would scatter all the answers.

A lot of the time its impatient management who want the fastest solution right now, demanding their jenga tower built from hollowing out the middle and never allowing time to fill in the gaps with any new blocks.

But i’ve also seen just plain inexperience from devs who have never seen a project become technically bankrupt. Some people just carry the expectations for a short lived app into a constantly iterated long lived app, not realizing that is the way to crunch and missed deadlines.

Compounding the inexperience issue is the use of bad architecture. Architecture is a bigger picture thing, not something to bang together a bunch of use cases and a bunch of factories. The purpose of architecture is to keep development easy and smooth for now and the future. If it doesnt feel nice to work in, it’s not doing its job. If devs keep trying to cheat it, its time to add convienience tools to encourage them to do it right.

Clean Architecture for example is very nice, it really shines in projects intended to be iterated continuously on for over 5 years and many more. It mitigates the pain of replacing and upgrading old obsolete stuff. Using it for one marketing campaign app that’s going to live for only 3 months is overkill though. For very short projects, you can see how its the wrong tool for the job.

Selecting the right architecture involves understanding the patterns used and knowing what problems those patterns were meant to solve. Thats the way to know if those problems are relevant to your project.