From the article: "Formerly known as the CSeries, the 110-130-seat A220 was designed by Canada’s Bombardier (BBDb.TO) and was one of the first to adopt the new Pratt & Whitney technology. Bombardier sold the program to Airbus last year due to heavy losses."
If I recall they sold a very good product for a dollar because of extremely anticompetitive and monopolistic abuse by Airbus and Boeing that would have made Rockefeller blush. If bombardier was an American company I think the DOJ would have come down hard on Airbus and Boeing. But they can't be expected to protect foreign competition.
I don't recall any of the abuse coming from Airbus. Because of all that hubbub with Boeing resulting in US tariffs, the A220 is now manufactured in Alabama by Airbus.
It's worth noting that the problem is with the engine manufacturer's software; the Pratt and Whitney PW1000G family has had issues on the other planes it's on, namely the A320neo and Embraer E-Jet E2.
I work at a company that is currently suffering through very public issues caused by bugs in our code and I feel pretty bad about it. Then I read this article and the one this morning about Twitter's entire quarter essentially being torpedoed due to a buggy platform and it makes me relax a little and realize that bugs in very public facing code are just part of life.
I don’t work with one of my employer’s products, rather a few IT systems used by most of the enterprise. It’s a big support platform with a portal used by almost every customer.
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.
I used to feel bad. I don't anymore. I make my own share of mistakes. I firmly admit that, but it's really easy for others in the business to blame the developers for defects in software. "Well, you made them." Yes, I did, but I am not the one who didn't allow time for us to properly check things, or created the work culture where people are on edge about getting things done. I'm not perfect, but I'm done with other people blaming me and making me feel totally responsible for being in a position where I can't effectively do my job.
My department is velocity driven (agile) meaning we have to complete a certain number of points each week. Quality loses its importance when quantity is the main driver for being employed.
I wonder how two different teams can be so different in culture saying they do the same thing. My team looks at velocity only as an indicator of how much we think we can reasonably take on looking ahead and as a warning sign if things are falling apart.
That's a tough one. Most people either don't understand or refuse to acknowledge that velocity is not a measure of how much you can accomplish. It's not a goal of work. It's a speed limit. The team's velocity signifies that its the maximum amount of work they can reasonably accomplish while adhering to certain quality standards. Organizations like to ignore this, because it makes them feel like they are making people more productive.
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...
16 comments
[ 3.3 ms ] story [ 44.0 ms ] threadHowever, 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...
https://operationsroom.wordpress.com/2012/07/17/boeing-and-a...