this post was submitted on 28 Sep 2024
208 points (96.8% liked)
Asklemmy
44160 readers
1482 users here now
A loosely moderated place to ask open-ended questions
If your post meets the following criteria, it's welcome here!
- Open-ended question
- Not offensive: at this point, we do not have the bandwidth to moderate overtly political discussions. Assume best intent and be excellent to each other.
- Not regarding using or support for Lemmy: context, see the list of support communities and tools for finding communities below
- Not ad nauseam inducing: please make sure it is a question that would be new to most members
- An actual topic of discussion
Looking for support?
Looking for a community?
- Lemmyverse: community search
- sub.rehab: maps old subreddits to fediverse options, marks official as such
- !lemmy411@lemmy.ca: a community for finding communities
~Icon~ ~by~ ~@Double_A@discuss.tchncs.de~
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Speaking as a software engineer, it's usually a combination of things.
The root of all evil is that yes, fixing that thing doesn't just take one hour, as it should, but rather a few days. This is mostly preventable by having sufficient automated tests, high code quality and frequent releases, but it's a lot of work to keep up with. And you really need management to not pressure early feature delivery, because then devs will skip doing necessary work to keep up this high feature-delivery velocity.
Well, and as soon as such a small fix has a chance of taking more than a day or so, then you kind of need to talk to management, whether this should be done.
Which means probably another day or so of just talking about it, and a good chance of them saying we'll do it after we've delivered this extremely important feature, which usually means 'never', because there is always another extremely important feature.
This. Worked at a consulting firm doing e-commerce for a client. The client always pushed making changes on banners or promotional texts rather than fixing bugs.
There was an issue with the address validator in the checkout (why and how is irrelevant) and it was raised by the QAs, but we were told to fix it in the future, they didn’t see it as a priority, they preferred a checkout that worked most of the time an focus on adding a promo banner.
Now I work in a better place, working on product with stakeholders who don’t prioritise new things over fixing stuff, but we still need to fight to have time allocated for technical improvements that the benefits are not directly evident in the final product.