191–200 of 228 posts
I think the author completely misses the point of Uncle Bob's article for two reasons. First, in "Tools are not the Answer", it is clearly stated that tools are valuable. Second, Uncle Bob's article is not telling programmers to be better. It is telling programmers to be professional. It is not like telling drivers to drive better. It is like telling drivers to stop texting while driving.
I think Uncle Bob is way off the mark here. In Clean Code he hammered in the idea that unit tests form an automated specification of some software system under development. This was a decent idea at the time. So why on earth would he tell people not to use type-safe languages or tools for defining better, formal specifications? Probably because he has something to sell? We need better tools, processes, and "disciplin…
Earlier quoted context omitted.
> First, do no harm, then use like Light Table, Model Driven Engineering, and TLA+. Looking at some of Uncle Bob's other posts linked from this article, I don't think that's what he's saying. He (Uncle Bob) goes on and on about discipline, but at the same time dismisses anything that might actually force programmers to be disciplined, like type systems that force you to check references for null before dereferencing…
Type systems do not force programmers to be disciplined. Type systems tempt programmers to cheat.
Earlier quoted context omitted.
Fewer errors get deployed to production code because tools help us catch them more often? Yes. Fewer errors get deployed to production code because programmers have a more rigorous discipline when creating software? Also yes. Which part should a teacher like Uncle Bob (I consider him as such) should care more about? People using tools or processes, or having them care about the discipline enough? I'll go with the lat…
You’re creating a false dilemma. It’s entirely possible to be a disciplined programmer and use good tools. And, yes, a teacher should care more about the skills than the tools, but Uncle Bob is actively against the tools, claiming that they impede learning the skills. Which is no more true than claiming that automatic transmissions or anti-spin in modern race cars impedes learning how to race.
Earlier quoted context omitted.
Fewer errors get deployed to production code because tools help us catch them more often? Yes. Fewer errors get deployed to production code because programmers have a more rigorous discipline when creating software? Also yes. Which part should a teacher like Uncle Bob (I consider him as such) should care more about? People using tools or processes, or having them care about the discipline enough? I'll go with the lat…
I complain about quality a lot. I might almost have this superhuman level of discipline on my best days, and only then if business allows me to indulge it. But think about the worst programmer you've ever worked with. In his hands the tool is a much bigger win.
Earlier quoted context omitted.
Fewer errors get deployed to production code because tools help us catch them more often? Yes. Fewer errors get deployed to production code because programmers have a more rigorous discipline when creating software? Also yes. Which part should a teacher like Uncle Bob (I consider him as such) should care more about? People using tools or processes, or having them care about the discipline enough? I'll go with the lat…
You’re creating a false dilemma. It’s entirely possible to be a disciplined programmer and use good tools. And, yes, a teacher should care more about the skills than the tools, but Uncle Bob is actively against the tools, claiming that they impede learning the skills. Which is no more true than claiming that automatic transmissions or anti-spin in modern race cars impedes learning how to race.
Both "Uncle Bob" and the author are selling extremely complicated, cumbersome, expensive ways to develop software -- great for them as consultants if they can pull it off, not necessarily great for their customers. Giant near monopolies such as Microsoft or Google can afford these methods, may even benefit from this sort of super-bureaucratic "gold plating" of software and certainly do benefit from convincing small p…
Perhaps as people who call themselves "engineers" we should move away from the idea that "gets the job done" is good enough? Especially when we have security breaches left right and center.
My problem with Uncle Bob's opinions is that they are pretty common within the industry, even if "discipline" really isn't the issue and all those negative feelings people allude to are warranted. In general, people are made to feel guilty for not being able to use the shitty tools and techniques we are given. Lets take for example ORMs and Hibernate in particular. I can't tell you how many times I've seen horrors re…
Completely agree with this. The post where Martin derides modern, type-safe languages (Kotlin and Swift) [0] was just unbelievable to me. "Ask yourself why we are trying to plug defects with language features. The answer ought to be obvious. We are trying to plug these defects because these defects happen too often. Now, ask yourself why these defects happen too often. If your answer is that our languages don’t preve…
Both "Uncle Bob" and the author are selling extremely complicated, cumbersome, expensive ways to develop software -- great for them as consultants if they can pull it off, not necessarily great for their customers. Giant near monopolies such as Microsoft or Google can afford these methods, may even benefit from this sort of super-bureaucratic "gold plating" of software and certainly do benefit from convincing small p…
Perhaps if the methods are sound (even if expensive) then someone can step up and make tooling or refine them so the methods are more accessible to smaller firms. Uncle Bob's opinion's might be discouraging people from exploring them and finding ways to drive down the cost of adopting these better methods.
To his credit, Hillel is trying to evangelize (in general, not directly through the post linked) a particular tool (TLA+) whose creator (Leslie Lamport) wants to do exactly this. I don't know how big Hillel's employer is, but from what I understand it's nowhere near the biggest engineering firm in number of technical employees. Lamport's current objective with TLA+ is to get people to learn concepts for formal description/specification of systems, and he happens to provide an effective tool for testing those system specs.
Check out his TLA+ tutorial at https://learntla.com.
If you want an example of solving concurrency issues, jump to here: https://learntla.com/concurrency/processes/.
Earlier quoted context omitted.
There is no best tool or technique because there is no silver bullet. And what do you mean by automated testing? What kind of tests? Unit, integration, regression, black box, white box? Automated testing is only one tool, that every system should be using. Manual testing is obviously too tedious (though sometimes required) to do for all test sequences for most systems so of course we need to automate. But what do we…
I meant automated testing(any kind) vs no automated testing. Most of us don't do any kind of automated testing.
I'll agree with you, if you have no automated testing then that should be the first priority for a dev shop. By this I mean, if testing is: follow this instruction sheet and do each step, hopefully we've made enough of these and it's thorough enough. No other tool or method is likely to help you as much as developing automated tests.