Stakeholders are rushing web application updates. Are you sacrificing quality for speed?

Never rush development, high chances that you are missing edge cases if you are doing this in a hurry. This can hit developer like a nightmare someday and develoepr and developer alone will be liable for this. Talk freely about practical deadlines. If in a hurry divide work in smaller tasks and prioritise and deliver things with higher priority early. Never, I said never compromise with quality of code, it might take your job someday.

I actually agree with this. A new feature hastily added can come back to bite you. You may even put yourself at a disadvantage with the competition. If you introduce a new feature in a way that either has bugs or is difficult to later scale because of the poor code integrity, you risk your competition building on your new idea in a less buggy way or in a more scalable way. Taking extra time to ensure quality while minding speed is invaluable. I've suffered from this in my own little corner.

Would be nice to say to never compromise on quality, but as a QA expert, our responsibility is to highlight potential risks, that we see corresponding to certain decisions, and to suggests better alternative. Ultimately clients/business/stakeholders make the decision. If they decide to rush, in that case we need to ensure they understand the risk, highlight the upcoming consequences, and adapt to their plan as best as we can troughout the whole process.

If we want to move fast, we might (have to) break things. Instead of rushing, reduce. Narrow scope to ensure that realistic goals are achieved. Keep expectations low, and principles high. Structure releases to allow for cumulative progress rather than choosing between speed and quality. Break functionality down to what might seem like even too small of pieces. Modularity usually *is* testability.

As a software engineer, I understand the pressure to deliver quickly, but we must balance speed with quality. I suggest we focus on automated testing, implement a CI/CD pipeline, and use feature flags for gradual rollouts. We should prioritize critical updates, enhance our code review process, and clearly communicate risks to stakeholders. These steps can help us increase speed without sacrificing quality.

I'm guessing we're having trouble with UX and rushing things out the door because stakeholders were too far removed from the development process in the first place.

I'll follow this up in the next section, but your processes can also be a kind of instant debt. If you have to fight with your tools and never ship, you will never get feedback. This doesn't mean test in production! As for documentation: If you want to be hip, document your code and get a head start generating external docs automatically. Even better, write the doc string with an assertion and you'll have a start on unit testing as well.

Notice the tradeoffs you may have been reading-between-the-lines from the beginning of this post. Are your changes *actually* small and manageable? Gradual enhancement: that surely isn't being stuck in PR or QA endlessly on things that don't matter, just like testing whether props pass down in React (or something) isn't really testing. Why can't you ship (assuredly) what you have? If part of the ticket is done, ship it. If part of the ticket is done, *ship it*. Then kick the ticket back with a simple modification, which reflects progress. If you only care about the card and not the code or the customer... pretending to be 'agile' is the last of your worries.