Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "productowner"
-
1. Put idea on roadmap
2. Work out simple implementation
3. Productowner-san, please notice me.
4. Other devs pile on cool but complex ideas
5. A 4 hour meeting later, original simple idea is rejected because it's "out of scope" and there is "no consensus about implementation"
6. I already built it during the meeting
7. I sip my coffee while I enjoy the annoyed gasps as coworkers receive PR notifications.
8. FUCKING DARE TO REJECT IT COCK SUCKING SCRUMBAGS.2 -
Facepalm Monday...
My collegue denies to provide breaking changes in our login API in a separate version to the other teams depending on it.
What is the reason for his stubborn rejection?
It's scrum. We haven't planned the effort for realising a versioning concept for our API.
Let's build it in the next sprint as a part of live deployment strategy.
The point he miss is that the ProductOwner wants his API change deployed during the next sprint.
Additionally, it is best practice, having a compatible, deployable product after each sprint, without any risks.
Furthermore, another best practice to provide your API is one URI without a version part holding the current development of the API. And URIs with a version part in it to keep a specific request/response structure and behavior.
What really grind my gears are sayings like 'if the other teams had well programmed their software, modifying our API won't have any effect on them'
C'mon dude. That's far from reality, as anybody knows.
I can't accept, we provide unprofessional API builds, as he is going to do.
So, i have to spend my time and energy to change his mind, together with other software-architects, planning the big thing API-Gateway *sigh*2 -
Two weeks before the release of a major new version of an application I'm working on, the testers finally got round to testing the new functionality (a set of a few features and a new page). They didn't agree with the requirements and got the requirements to change with the product owner.
The product owner now says that these changes "are easy to implement" and "the new requirements are clear" even though the other devs and I all don't understand the change. How would a product owner even know it is easy to implement?
Fun times.1