Well, I'm with Uncle Bob.
Tools are evolving fast and making easy to spot problems before they become problems.
But, I can say confidently: I know SO MANY developers that aren't even writing tests today (this is something that makes me sad). Show them a static analyzer and it'll blow they minds.
My point here is: they are ignoring all those tools that help to produce better software! And, IMO, this is exactly what Uncle Bob wants to improve when he says:
1: Raise the level of software discipline and professionalism.
2: Never make excuses for sloppy work.
The tools are there, and they are become better each day, but we need to start using those tools as an important allied in our work, and IMO, this is all about discipline and professionalism.
I agree with your assessment, Diego--if we are talking about non-safety-critical software development.
But Uncle Bob's argument was that the problems with safety-critical software system development is that the programmers working in that area lack professionalism and discipline, which I find hard to believe, given everything I discovered while writing this post.
People doing safety-critical software system development still are people, and still can lack of professionalism and discipline, as every other human being.
In one point Uncle Bob can be wrong: generalizing. Possible the most developers in the field are very professional, but I don't think we can say confident that 100% are using tools to help then improve they code.
I appreciate your comments but I'm having a hard time following your logic.
Suppose you work on a team that is doing a safety-critical avionics project for Boeing at the highest assurance level, maybe a new auto-landing system. Let's say that 99% of your devs are excellent in every way Uncle Bob could mean it but 1% of your devs are terrible/undisciplined/unprofessional.
Assuming a manager somewhere doesn't just outright fire the terrible 1%, we have to imagine a scenario where the terrible devs (regardless of which tools they use) somehow manage to get broken code by your team's internal code reviews, the official QA, testing, and verification required by DO-178C, past Boeing's people, and the extensive testing that will take place to certify the whole aircraft the code will run on.
How likely is it that the terrible devs on your project can get bad code past multiple levels and kinds of QA done conducted by multiple organizations and that bad code causes the system to experience a fault that results in a loss?
No one's saying it's impossible to have defects in safety-critical software. But Leveson, Knight, and others seem to be saying that the kind of scenario I'm describing isn't really the big problem we're facing. The big problem is that we are attempting to build systems that we can't fully understand (which leads to the Leveson quote about the problem being in requirements).
Boing is a nice example. Legally, they have a lot of requirements about they software, and since they take it seriously, the company invest in process to achieve a great level of confidence (not only tools).
Take a look at they process:
This shows a very mature company that have raised his level of discipline and professionalism. They probably invest a lot of money on the development team to help them become better developers and give them a environment that promotes good practices.
But I'll give you another example: I have a friend who works in a bank here in Brazil. Our government have a lot of regulation about the bank system. The people who work in the softwares who help the bank achieve those regulations found a very professional and mature environment to do they work and delivery great software. But those who work in other softwares from this bank doesn't have the same environment. They don't do code reviews, testing and a lot of other good practices. Yet, they work in pieces of software that can make the bank broke (we can say that this is safety-critical software?).
I do think that when Uncle Bob is talking about raising the level of discipline and professionalism, his talking about not only the professional, but the company too (and perhaps this is more about the company that is about the developer).
Companies who produce great software invest in people, promotes good practices (that leads to use good tools) and creates an environment where people can achieve they full potencial. And this is raising the level of discipline and professionalism for me.
Well said, Diego. I'm always happy to come across another developer who's as passionate about software development professionalism as I am.
I don't think bank software would typically fall under the umbrella of safety-critical software. This link shows the typical kind of industries that I think of when I think of safety-critical software: en.wikipedia.org/wiki/Safety-criti...
I would hope banks would be subject to strict regulations that force them to create quality software but this is not my area so I don't know what that would look like.
I sure hope the people writing software for my bank are engaging in vigorous QA practices such as code reviews, unit testing, and so forth and keeping my money safe.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.