Software Link Suspected in Airbus Engine Blowouts
reuters.com
reuters.com
However, I feel pretty bad when I have to do a hotfix after a deployment. My boss told me this is just a part of developing software and partly due to the lack of support with have during testing. Coupled with a huge lack of defined processes and documentation by the end users.
I’m looking to transition in the next year to working on a revenue generating product that’s not off the shelf. I hope my worries don’t increase but they might for a time.
The question I ask when confronted with situations like this is, "Do you want to lessen the quality of the code base for increased productivity?" This honestly makes people a little upset, because they know the answer they want to say vs. the answer they should say. Once someone says no to this question, they open themselves up to negotiating over the amount of work to accomplish within a given period of time.
Spot on. Sounds like in the OP's case, people are putting a weight on the current velocity numbers and not looking at when features will be ready. Usually means the stories are too big.
Velocity over time is what you use to predict when future features will arrive. Yoyo velocity likely means the stories are too big or too small. If velocity drops and those features just move down the road. It should be clear as to why velocity drops (someone goes on vacation) or the story isn't broken down enough and takes too long.
Usually, in a velocity driven workflow, you don't need to lessen quality of code because developers point their stories and they should factor in testing into those points. If the stories are too big, break them into smaller stories so there is more accepted work each week. Like what we learned in math class... break a bigger problem into smaller problems...