41–50 of 228 posts
"Don't test the UI" is not equivalent to "No end-to-end testing." The XP people, for example, prefer to make UI a thin shell over a programmable interface that can be easily tested. Then, visually confirming the UI operates the interface is enough. I admit I don't read much Bob Martin, but does he say you shouldn't use automated functional testing, e.g., Fit or Cucumber?
I work on a tool for mutation testing for C/C++[1] for a few years now. During this time I was thinking about tests, tools, people, etc. a lot. Here is the summary of my musings:
Quality of software depends on several factors such as hardware, operating system, programming language and tooling used to build the software in the first place, etc. For decades we try to improve each of those aspects. But, the most significant and most harmful factor is the human. Naturally, we cannot improve developers, but we can decrease the destructive influence of a human being by using better tooling.
Earlier quoted context omitted.
There's definitely two types of very well known speakers. People who have worked on some really notable project. Linus Torvalds, David Heinemeier Hansson, Joel Spolsky and so on. I know these people are worth listening to because I can see that their code is a success. Then there are people who I have no idea what they have ever written at all. Robert Martin, Martin Fowler and so on. I don't know if I should listen t…
> People who have worked on some really notable project. Linus Torvalds, David Heinemeier Hansson, Joel Spolsky and so on. I know these people are worth listening to because I can see that their code is a success. I agree with your examples, Linus Torvalds in particular. However, I would not consider Mark Zuckerberg, Steve Jobs or Bill Gates worth listening to on a technical level just because their products are a su…
Earlier quoted context omitted.
I never understand why Martin gets the kind of attention he does. As far as I can tell, the only significant achievement he's done for the technical community is the Agile manifesto. Outside of that, he's a typical consultant in that he's got books, training courses, etc. However, I have yet to find a significant publicly known project he's been involved in where he's had to put his principle into practice.
There's definitely two types of very well known speakers. People who have worked on some really notable project. Linus Torvalds, David Heinemeier Hansson, Joel Spolsky and so on. I know these people are worth listening to because I can see that their code is a success. Then there are people who I have no idea what they have ever written at all. Robert Martin, Martin Fowler and so on. I don't know if I should listen t…
Also, re: open source, he does sometimes write about particular open source projects that have successfully made use of the tools or technologies he advocates. Or simply about the open source projects themselves.
I happen to enjoy a lot of Fowler's blog writing. In particular, I've enjoyed reading his posts on the LMAX architecture. Fascinating stuff.
Here is the post this post is in response to: http://blog.cleancoder.com/uncle-bob/2017/10/04/CodeIsNotThe... I don’t interpret the original piece as saying any of these tools and techniques are not useful. I interpret it as saying average developer mindset needs to shape up. I tend to agree. I work with guys who believe in formal reasoning tools (we collaborated with Amazon’s ARG for example[1]), and use all these t…
I don't see why these exclude each other? You can easily have both, through e.g. powerful type systems (a la Haskell) and still use continuous deployment.
> I interpret it as saying average developer mindset needs to shape up.
I think you're giving Uncle Bob too much leeway. If you go through his other posts it should be a bit more clear, but he is very much focused on the programmer being at fault. Heck, in one (as the other commenter pointed out) of his posts he even says that it's never the languages fault (which is obviously wrong, you can eliminate wrong behaviour with good language design).
Another example is http://blog.cleancoder.com/uncle-bob/2017/01/13/TypesAndTest... where he states,
So, no, type systems do not decrease the testing load. Not even the tiniest bit. But they can prevent some errors that unit tests might not see. (e.g. Double vs. Int)
Here is the post this post is in response to: http://blog.cleancoder.com/uncle-bob/2017/10/04/CodeIsNotThe... I don’t interpret the original piece as saying any of these tools and techniques are not useful. I interpret it as saying average developer mindset needs to shape up. I tend to agree. I work with guys who believe in formal reasoning tools (we collaborated with Amazon’s ARG for example[1]), and use all these t…
> 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…
"I don't have to reason about whether this can be null, the type system takes care of that for me." "I don't have to worry about leaking memory, valgrind will let me know."
"I don't have to pay attention to the road, Tesla's autopilot takes care of it for me."
All the tools do is enforce a loop of compile -> make compiler happy -> compile.
The problem is that the more tools you add, the more mistakes you make in the tools. This is the same debate we had previously about formal methods. They don't eliminate errors, they just move them to the testing systems and where there are several the gaps between them. Communication becomes more difficult between the people involved and you rapidly start looking for the Chief Programmer Solomon who knows everything…
Agreed, each tool - process, framework, ritual, management layer, etc - adds more complexity to juggle, which hides the original problem and/or source code that does the actual work. It's why I like the direction the Go language and its proponents point towards, less tooling, simpler language with sane defaults and a complete standard library, and a mindset to go with it (things like "Nope you don't need a web applic…
I do like Go's sane defaults and awesome standard library, although I find it wanting as a language (Rust, which ships w/Cargo, also has sane defaults and is more what I look for in a programming language).
Here is the post this post is in response to: http://blog.cleancoder.com/uncle-bob/2017/10/04/CodeIsNotThe... I don’t interpret the original piece as saying any of these tools and techniques are not useful. I interpret it as saying average developer mindset needs to shape up. I tend to agree. I work with guys who believe in formal reasoning tools (we collaborated with Amazon’s ARG for example[1]), and use all these t…
You haven't been reading much of Uncle Bob's articles or tweets then, because that's exactly what he's saying and there's no point in second guessing.