DEV Community

Discussion on: Is Uncle Bob serious?

corycollier profile image
Cory Collier


First of all, I appreciate this piece very much. I really like the references you have here. I don't see many people quoting that Fast Company article, but it's been a mainstay of professionalism arguments I've had for a long time.

I didn't take from Uncle Bob's article that professionalism was lacking from developers. I do agree that better tools might help with improving code quality.

My experience has been, and continues to be, market forces tend to drive code quality down. Most developers that I know, given the time, would make code that is very high quality. The challenge there, is that time costs money, and those who are driving financial decisions want to spend as little money as possible for their product.

On something like an automated car, errors could kill people. Death of people costs a lot of money. For that reason, more time is allotted to ensure the car doesn't hurt people.

For something like a marketing website, errors could simply cause the website to not work. This isn't likely to be a very expensive problem, so less time is put into craftsmanship.

I agree with you - the problem isn't professionalism. The problem is investment.

bosepchuk profile image
Blaine Osepchuk Author

Thanks, Cory. I couldn't agree more.

Management often thinks the cheapest software has few QA controls but that's a fallacy (construction is cheaper but they pay a (often huge) premium for testing, debugging, and maintenance).

Software with no QA controls is at high risk of never being released. And it will almost certainly be full of bugs if it is released. At the other end of the spectrum is safety-critical software where they spend extreme amounts of money trying to ensure the defect rate is extremely low. And the maximum ROI for an average project uses a moderate number of QA controls. They catch lots of the defects at a fairly low cost per defect discovered.

Most of the projects I've seen and software I've used almost certainly could have been developed more cheaply if they moved a little to the right (or more than a little) on the spectrum and improved their quality.

mrbandit profile image

Boeing failed with the 738 MAX because management wanted to save some money. It cost them way more than they saved. They ignored the engineers.

I was just on a DAL A DO-178C project. An enormous effort went into the process. Everybody on the team were highly skilled and experienced. The company put in sufficient resources.

Thing is, if someone is not up to the required level on a project, it becomes extremely obvious very quickly. If someone is an intern, or a new hire, that is fine because the team recognizes the situation and handles it accordingly. We all started somewhere. But I have been on a couple of teams where it was was painfully obvious someone who was supposed to be at a particular level, but they were not. It then becomes a management problem.

mrbandit profile image

Addendum to below.

[quote] I have been a pilot for 30 years, a software developer for more than 40. I have written extensively about both aviation and software engineering. Now it’s time for me to write about both together.

The flight management computer is a computer. What that means is that it’s not full of aluminum bits, cables, fuel lines, or all the other accoutrements of aviation. It’s full of lines of code. And that’s where things get dangerous.

Those lines of code were no doubt created by people at the direction of managers. Neither such coders nor their managers are as in touch with the particular culture and mores of the aviation world as much as the people who are down on the factory floor, riveting wings on, designing control yokes, and fitting landing gears. Those people have decades of institutional memory about what has worked in the past and what has not worked. Software people do not.

In the 737 Max, only one of the flight management computers is active at a time—either the pilot’s computer or the copilot’s computer. And the active computer takes inputs only from the sensors on its own side of the aircraft. [/quote]

This is a violation of safety-critical systems: you never have a single point of failure. This was a management failure. They dictated there could not be any hardware changes to the aircraft, and there would be no additional training for the pilots.

[quote] It is astounding that no one who wrote the MCAS software for the 737 Max seems even to have raised the possibility of using multiple inputs, including the opposite angle-of-attack sensor, in the computer’s determination of an impending stall. As a lifetime member of the software development fraternity, I don’t know what toxic combination of inexperience, hubris, or lack of cultural understanding led to this mistake.

But I do know that it’s indicative of a much deeper problem. The people who wrote the code for the original MCAS system were obviously terribly far out of their league and did not know it. How can they implement a software fix, much less give us any comfort that the rest of the flight management software is reliable? [/quote]

I'm not sure this is completely true. What is known is management put severe restrictions on the redesign such that failure was inevitable.