I never said not refactoring was a cause. In context, this was concerning being a software craftsman. I did say:
What did this lack of quality and craftsmanship lead to?
Sure - there are many issues and causes we could look at in this specific case, which actually further my point about taking time to build quality systems (whether software or otherwise).
As far as the engine issue, I read somewhere that the decision to go with the larger engine and not change anything else was in efforts to get this thing done faster in order to match a competitor. For software developers out there, that should sound awfully familiar...
But as a segue, I think the point remains that as software developers we should seek to be craftsmen and value building quality systems.
I have no issues with developers from outsourced countries - but if they have a lack of experience in that particular industry for such a critical system and the company outsourcing (Boeing) is getting rid of its experienced senior devs in efforts to "cut costs", then that perceived trade-off of "less quality = fewer costs" is not true.
Quoting the article:
The coders from HCL were typically designing to specifications set by Boeing. Still, “it was controversial because it was far less efficient than Boeing engineers just writing the code,” Rabin said. Frequently, he recalled, “it took many rounds going back and forth because the code was not done correctly.”
Did that cause the crash? Dunno.
However, seeking to squeeze out costs and ignore quality in these kinds of critical and/or complex software systems do matter and have long term consequences that end up affecting costs negatively when bugs and unexpected behaviour do finally occur.
One of the ways developers can make sure they are doing their part is to address code quality and take ownership of it.
Previously at Uber, Skyscanner, Skype/Microsoft. I love to help people grow and share what I learned. I write longer articles on software engineering at blog.pragmaticengineer.com.
I never said not refactoring was a cause. In context, this was concerning being a software craftsman. I did say:
Sure - there are many issues and causes we could look at in this specific case, which actually further my point about taking time to build quality systems (whether software or otherwise).
As far as the engine issue, I read somewhere that the decision to go with the larger engine and not change anything else was in efforts to get this thing done faster in order to match a competitor. For software developers out there, that should sound awfully familiar...
But as a segue, I think the point remains that as software developers we should seek to be craftsmen and value building quality systems.
I have no issues with developers from outsourced countries - but if they have a lack of experience in that particular industry for such a critical system and the company outsourcing (Boeing) is getting rid of its experienced senior devs in efforts to "cut costs", then that perceived trade-off of "less quality = fewer costs" is not true.
Quoting the article:
Did that cause the crash? Dunno.
However, seeking to squeeze out costs and ignore quality in these kinds of critical and/or complex software systems do matter and have long term consequences that end up affecting costs negatively when bugs and unexpected behaviour do finally occur.
One of the ways developers can make sure they are doing their part is to address code quality and take ownership of it.
One of the tools to do that is refactoring.
Hopefully, that's clearer 😊.
I see - thanks for the clarification! And good luck with the rest of the book.