Why is it so in mobile development that 90% of projects does not have proper architecture, and when there is one, devs complain about it. I don’t see it being a case for other technologies of development, only mobile. In mobile the project always has spaghetti code, barely any abstraction it is developed just to be finished as quickly as possible and that’s it. And when there is clean architecture introduced, everyone complains. Why is it just a case in mobile development?
Just disclaimer: It is not like the architecture in project is completely new invention, it uses well known principles and approaches
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.
@amotoohno @Kubenqpl
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).