All things programming and coding related. Subcommunity of Technology.
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
Hard to tell without knowing some details.
Maybe they are incompetent or lazy. Maybe they don't expect the project to last that long. Maybe they are seniors that know your suggested architecture doesn't actually add to maintainability but increases connascences.
How would we know, OP.
Also to add that "well known principles and approaches" doesn't always equal good, readable, maintainable code; especially when it comes to a lot of OOP principles. Abstracting everything into a Factory/Decorator/whatever pattern you might think is the best approach after having only worked with OOP principles your whole career is almost always not what's actually the best way to structure things. In fact the code OP is complaining about may not even be that bad, it might just look so to someone who has no familiarity with any programming practices (like FP) that are outside their bubble.
I too have played the disappointed and befuddled architecture evangelist. The counter-argument that inevitably ended these conversations was: “This is a business. We make money by getting stuff out the door. Demonstrate how the time it would take to rework this code base would correspond to an increase in profits, then we can talk about how your time and people budget is impossible to justify.”
“Pretty behind the scenes” doesn’t make any difference when you’re focused on getting people to build you a moneymaking machine as fast and cheap as possible.
The way I look at this, it's all about incentive.
If the product you're working on is a SaaS product, and the way you design your architecture aren't allowing you to be agile and flexible in order to respond to changing business requirements quickly, you'll lose clients.
OTOH, if you're an outsourced dev working on an internal org's application. Your likely reaction would be: "Who cares? I'm still being paid."
It's all about incentive.
But the fact is the clients I work with usually have bigger budgets and expects quality and maintanable project. Where I work, it is expected to have professionals, not the everyday developer just taught himself to create flutter app and does everything in one huge class. Also the principles I follow are not there just to make it pretty. It makes it easier to avoid bugs and adapt to new requirements. The architecture is not just to make myself feel better, it has real influence on the project. And I don't see such discussions when the backend is developed, it is just a standard to follow some practices
You should be able to point out multiple concrete issues with arcane code, like ramp-up difficulty for new people, knowledge being concentrated in the heads of developers and is lost when they leave, maintenance costs etc.
But tbh if the code is fast and scales well it's typically not an architectural issue if it's ugly and unmaintainable.
If they don't care about that it's their prerogative. There's usually a decision maker assuming technical debt and technical risk. Just make sure you have proof of pointing it out (email is usually best, most companies purge their chats periodically nowadays).
it is developed just to be finished as quickly as possible and that's it
You answered your own question. You might see it more with mobile apps, because it's a totally different ecosystem, with often very short product lifespans. Get it shipped and make money before the wind shifts.
"it is developed just to be finished as quickly as possible and that’s it" You answered your own question.
In my experience, there are projects and workplaces where readable, maintainable code is expected and encouraged. Even in mobile development. You'll find a place that appreciates your approach to coding, over time.
Others has answered the specific cases where TTM is paramount.
When time is less of an issue, in my experience it's in no particular order a mix of:
All in all, instead of short term profit, it's a lack of not-so-long term vision and engagement from everyone involved. They just don't care.
Yeah, I'm the one in charge of fixing the mess, why you ask?
Just needed to face my frustration with opinion of others. I am confident about my habits of keeping code clean as if I do the mess and then I need to do some quick changes it saves a lot of time and frustration. However I am noticing the most of such behaviours (complaining about keeping the code clean) in mobile projects, it looks like this is the field where there is the most SO copy-pasters. I wonder why, mobile is not that popular technology choice, and usually the most popular choices have tendency to attract unskilled devs or people who just want to earn much on coding
I’m always wary when someone talks loudly about architecture.
I’m not saying it’s not important, by all means, but in my 10 years as a professional developer I’ve found that the people who are most devoted to preaching architecture don’t contribute to good architecture.
I’ve only met a few persons that fit that bill, so obviously nothing statistical, but the experience has left me wary when people start to become loud about it.
I’m not saying this is you, but if everyone is pushing back it might just be that you are part of the problem, not the solution.
Architecture can be many things.
However, there are individuals who believe that the only way is that one way they read about in a book once, or even worse, they’ve read it multiple times and it’s their Bible. Maybe they’ve read multiple books by the same author and has basically adopted someone else’s viewpoints without any critical thinking.
Exposing yourself to different architectural strategies, viewpoints on architecture from multiple people.
And remember that all architecture serves a point. It is the job of the architect, and the team, to build an architecture that solves the needs of the project.
“Clean code”, whatever that is interpreted as, is probably not one of them.
“Good test-ability”, modularity, multi-platform, performance, package-size, internationalization, accessibility, etc. might on the other hand be needs and goals that can be used to guide the project architecture.
Uncle Bob’s layer cake probably isn’t.
If you want better takes than mine on criticisms of Uncle Bob’s Clean Code I suggest to Google it. It might cause you to re-think some things as well.
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.
Profit motives. When things are done as cheaply as possible to maximize profit, you have to cut elegance and proper architecture. Its not just mobile development