43
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 21 Jul 2023
43 points (100.0% liked)
Programming
13360 readers
1 users here now
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.
founded 1 year ago
MODERATORS
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).